1.1.x

1.1.1

Fixes and improvements

  • Closed a role upsert privilege gap. Creating or updating a role with PUT now runs the same permission checks as role create and add-permission, so a caller cannot grant rights they do not hold or target another organization's tree.
  • Restored Issuer2 Open Badge v3 schema validation by accepting 1EdTechJsonSchemaValidator2019, matching Issuer v1.
  • Stopped Swagger UI from crashing when expanding the service-create request schema. The documented body is a generic JSON object, matching the runtime type.
  • Patched Enterprise UI fast-uri 3.1.8 for CVE-2026-86472 (inconsistent host case normalization).

1.1.0

Highlights

  • Enforced authenticated OpenID4VP Request Objects on Wallet2. Signed requests with a signable client ID are checked against pinned certificates, a linked Trust Registry, or stored client metadata. Unsigned redirect_uri requests fetched via request_uri stay accepted.
  • Added OpenID4VCI 1.0 batch issuance on Issuer2. One offer can hold several credential selections, and a wallet can request multiple proof-bound copies of a selected credential. Existing single-profile offer calls keep their previous request and receipt shape.
  • Extended X.509 across verifier signing, credential-status signing, certificate issuance, and issuer setup. Verifier2 and Credential Status can sign from an x509-store. Certificate issuance is one stored model. services/init can build an IACA and document-signer chain. EUDI PID Provider, Wallet Provider, and Wallet Relying Party profiles are available on the X.509 service.
  • Resolved public-key and DID issuers on ETSI trust lists. A trust-list entity registered with a public key and no certificate can be matched during verification, including from a Trust Registry linked to Verifier2.
  • Folded credential status into the Enterprise API, added a status read by issuance session or list index, and applied one shared status-list codec for Token Status List, Bitstring Status List, StatusList2021, and RevocationList2020.
  • Hardened operations: dev-mode routes require an access token, superadmin bootstrap tokens fail closed, pagination.conf and dev-mode.conf are actually loaded, events filters match the stored event shape, and OpenTelemetry plus Prometheus export is configurable.

Features

OpenID4VP request authentication

  • Wallet2 authenticates the final Authorization Request before match and present.
  • Signed requests with x509_san_dns, x509_hash, a DID, verifier_attestation, or pre-registered succeed when trust material matches. They fail closed when it does not.
  • A linked Trust Registry can supply relying-party certificates as JAR trust anchors, combined with optional PEM pins.
  • Unsigned JSON fetched with request_uri and a redirect_uri client ID stays accepted. Unsigned pre-registered clients are accepted when stored metadata includes redirect_uris that match the request destination.
  • There is no operator switch that turns this check off.

Issuer2 batch issuance

  • POST /v2/{target}/issuer-service-api/credentials/offers still accepts a profile-targeted body and returns the original flat receipt, including profileId and profileVersion.
  • A body aimed at the issuer service may send credentials: [{ profileId, runtimeOverrides? }]. That receipt is the shared offer metadata and does not repeat a per-credential inventory.
  • Issuer metadata advertises batch_credential_issuance.batch_size when batch issuance is configured.
  • A credential request with proofs.jwt returns one credential per verified proof, in order. credential_identifier separates datasets that share a configuration.
  • One original selection keeps the previous session and event JSON. Several selections use issuanceRequests and issuanceResults. Stored sessions from 1.0.0 remain readable.

mDoc issuance

  • Issuer2 profiles, offer runtimeOverrides, and issuance sessions accept optional msoData (validFrom, validUntil, expectedUpdate) for mso_mdoc credentials. Each value is a static timestamp or a timestamp data function, resolved when the credential is claimed.
  • Omitting msoData keeps the previous MSO window: validFrom is the signed time, validUntil is 365 days after claim, and expectedUpdate is omitted.
  • msoData on a non-mDoc profile or offer is rejected. W3C mapping dates and mdoc namespace issue_date / expiry_date do not set the MSO window.
  • mDoc mapping is applied to namespace objects that already exist on the payload. Arrays replace, templates inside array items evaluate, and <date>, <date-in>, and <date-before> emit ISO full dates. <timestamp> stays for MSO windows.
  • Issuer v1 applies the same namespace mapping. Issuer v1 does not accept msoData; its MSO window stays signed-at-claim and 365 days unless the credential request supplies validUntil.

X.509, verifier signing, and issuer setup

  • Verifier2 service and session create accept x5cReferences pointing at x509-store certificates. Inline x5c remains the certificate chain itself. Resolution order is session references, session x5c, service references, then service x5c.
  • Credential Status configuration accepts key or keyReference, and x5c or x5cReferences. Stored kid and x5Chain values still sign.
  • Certificate issuance persists one record (profile, issuer and subject DN, validity, key and certificate references). POST /certificates creates. PUT /certificates/{id} creates or updates. The previous generic, IACA, and document-signer routes delegate to that service.
  • Attached X.509 stores can receive a new certificate under configurable create, upsert, and success strategies. Existing stored certificates are migrated to the richer record shape.
  • POST /v1/{target}/resource-api/services/init can onboard an X.509 issuer: KMS keys, X.509 service and store, IACA, and document signer, or it can start from an existing IACA.
  • The X.509 service can issue ETSI TS 119 412-6 PID Provider and Wallet Provider certificates, and Wallet Relying Party certificates (WRPAC, with draft WRPRC).
  • X.509 helpers copy a CSR subject DN into the issued certificate, check basic constraints, and expose a Java-friendly creation API.

Trust Registry

  • POST .../trust-registry-api/resolve/public-key resolves a JWK thumbprint against identities loaded from an ETSI trust list.
  • Verifier2 sessions that use a linked Trust Registry resolve a JWT or SD-JWT issuer with no x5c by that thumbprint. An inline jwk header is not treated as trust evidence.

Credential status

  • Status list encode and decode for IETF Token Status List, W3C Bitstring Status List, StatusList2021, and RevocationList2020 go through one shared codec. Verification policies use that codec.
  • GET /v1/{target}/credential-status-service-api/status-credential/status returns the current index status. Pass exactly one of session or index.
  • Session reads require credential-status.get and ES_ISSUER_GET_SESSION, and the session must belong to that status list. Index reads require credential-status.get on the status configuration.
  • The separate credential-status process is no longer shipped. The same status APIs run inside the Enterprise API.

Wallet2 and presentations

  • Issued mdocs stay bound to the holder key that signed the key binding. Enterprise stores that binding as an optional field; existing wallet resources stay readable.
  • OpenID4VCI proofs for authorization-code and other client-bound grants include iss set to the token-request client_id. Anonymous pre-authorized proofs still omit iss. Issuer2 accepts a missing iss and checks it when it is present.
  • Isolated Wallet2 sign-proof accepts an optional clientId for the same claim.
  • credential_policy_results_available is emitted once per verification session.
  • Newly issued portrait capture dates are full timestamps. Date-only JSON input and stored profiles stay valid.

Service defaults and wallet init

  • Each service operation can store a partial default request. The live call deep-merges on top of that default, so a verifier can keep flow_type, signing, and keys on the service and send the DCQL query per session.
  • POST /v1/{target}/resource-api/services/init persists wallet.config (including static DID and key settings) and rejects a config that does not decode.

Licensing

  • A monthly issuance, verification, or wallet-creation cap returns HTTP 429 with month-scoped text. Hourly caps still say to retry next hour.
  • A configured license seed can recover an installation whose stored license state cannot be read. A failed activation releases its lease so another node can take it over.
  • Usage reports can be checked end to end against the license server. Metering uses the checkpoint engine by default, and a mid-period engine switch still bills every operation.

Auth, events, and configuration

  • POST /v1/superadmin/create-by-token accepts a token with devModeOnly omitted or true only while dev-mode is enabled. Set devModeOnly to false for a production bootstrap token. The route is limited to 5 requests per minute per client address.
  • With dev-mode enabled, /v1/dev/* requires the accessToken from dev-mode-access.conf. The placeholder value replace-with-a-per-deployment-secret prevents startup.
  • Enabling dev-mode loads dev-mode.conf. The shipped file sets enableDidWebResolverHttps to false.
  • List endpoints read pagination.conf. The shipped defaults stay 100 and 1000.
  • POST /v1/events/query compares fromTimestamp and toTimestamp as epoch milliseconds, matches status.type and action.type, and matches callId exactly. groupBy returns 400.
  • OpenTelemetry and Prometheus export can be configured for the API process.

Verifier capacity and stored payloads

  • In-memory Verifier2 sessions default to 2000 sessions and 256 MiB. A presentation that does not fit the budget is refused. A database-backed session store is bounded by the database instead.
  • Bulky disclosed element values and credential-policy payloads stored on a session are truncated to descriptors. Small claims are kept.
  • Byte-array claims in stored session and credential data are a single base64url string. Readers still accept the previous JSON array of bytes.
  • A verifier dependency that is down returns 503. That failure is not reported as invalid_request.
  • Issuer2 token rate limits are bucketed by grant code, so one wallet's failures do not block another wallet's token request.
  • Credential-store writes bound the decoded copy kept beside a stored credential, which keeps a portrait from dominating the stored document.

Fixes and improvements

  • Verifier2 logs the verification session id on session updates.
  • Webhook coverage locks issuer2 event order for the v1 and v2 issuance and presentation paths.
  • Document Signer certificate creation rejects an out-of-window validity period and a subject DN that does not match the IACA.
  • PUT of a certificate through the X.509 service succeeds when no store is attached only on the paths that still allow a local write. A composite store with nothing attached returns 405.
  • EUDI examples, Annex C verifier setup, and pinned certificate validity in tests were aligned with the current X.509 and signed-request rules.
  • Trivy HIGH fast-uri findings in the Enterprise UI dependency tree are patched.
  • ZAP baseline scanning runs on pull requests. The daily scan fails on High or Medium findings that are not in the rules file.
  • CLI integration tests run on pull requests that change the API.
  • Security scan workflows run on the shared runner pool again, and the devalue advisory in the UI tree is updated.
  • Sonar findings were cleared, including example logo URIs served over HTTPS.
  • Load-test runs can place worker nodes on spot capacity, size MongoDB from the node type, and generate load from inside the cluster. The API process exits non-zero when startup fails. PostgreSQL engine capabilities match what that profile can actually do.

Breaking changes

These are request, response, or deployment changes that affect running integrations. Mobile SDK types and internal library constructors are not listed here.

Wallet2 request authentication

Wallet2 rejects an Authorization Request that 1.0.0 would have presented.

  • A signed request with x509_san_dns, x509_hash, a DID, verifier_attestation, or pre-registered fails closed unless trust material matches (PEM pins, a linked Trust Registry, or stored JWKS for pre-registered).
  • An unsigned pre-registered request without stored redirect_uris that match the destination fails with invalid_client.
  • Unsigned redirect_uri requests fetched via request_uri are unchanged.
  • No presentation route was removed. There is no configuration flag to skip the check.

X.509 certificate API

  • PUT /v1/{target}/x509-service-api/certificates requires the ES_X509_SERVICE_UPSERT_CERTIFICATE permission.
  • Certificate creation (generic certificates and ISO document signers) returns 400 when the validity window is inconsistent or a document-signer subject DN does not match its IACA.
  • PUT against a composite certificate store that has no store attached returns 405 Method Not Allowed.

Superadmin bootstrap

  • A registration token with devModeOnly omitted or set to true works only while dev-mode is enabled. Production tokens must set devModeOnly to false.
  • POST /v1/superadmin/create-by-token may return 429 after 5 requests per minute from one client address.

Dev mode

  • A deployment with dev-mode enabled and no accessToken in dev-mode-access.conf refuses /v1/dev/* with 503 until the token is set.
  • accessToken set to replace-with-a-per-deployment-secret prevents the process from starting.
  • With dev-mode enabled, the shipped dev-mode.conf is loaded, including enableDidWebResolverHttps = false.
Last updated on September 30, 2026
1.0.xReleases