--- title: "1.1.x" description: "- 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…" stack: "Enterprise Stack (commercial) — version 1.1.1" stack_version: "1.1.1" stack_comparison: https://docs.walt.id/community-vs-enterprise.md canonical_url: https://docs.walt.id/enterprise-stack/release-notes/releases/1.1.x generated: 2026-10-01 --- # 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 ``, ``, and `` emit ISO full dates. `` 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`.