TL;DR

• New release - Demo Web and Mobile Wallets, Batch Issuance, and more
• New eIDAS 2 industry guides – Guides for 10 industries, from public sector and financial services to telecom, healthcare and online platforms.
• Events – WeBuild Pilot payments demo with Authologic, Visa and Mastercard at GDC

Community Stack (1.1.1)

Below are the highlights available through 1.1.1 of the identity lib. Check out the full change log for v1.1.1 here. Note, also the 1.1.0 version was published this week. Want to learn more about the identity lib in general? Check out our intro video.

1.1.1

Features

Demo Web Wallet

Receive and present credentials via our new demo web wallet built on the wallet2 API.

Try it out

Demo Mobile Wallet for Android & iOS

Test the full credential lifecycle on a mobile device with our new open-source reference wallet apps for Android and iOS, including in-person mDL sharing via NFC or Bluetooth. The apps are build on our upcoming Wallet SDK, which is still in development.

Learn more

OpenID4VP request authentication in Wallet2

Wallets now check who is asking before they show or share anything. Signed requests are verified against certificates you trust, and registered clients are matched against the metadata you stored.

Learn more

Batch Issuance on Issuer2

Put several credentials into one offer, or let a wallet request multiple proof-bound copies of a credential in a single call. Existing single-credential offers work exactly as before.

Learn more

Control the Validity of Issued mDocs

Set when an mDoc becomes valid, when it expires, and when wallets should expect a refresh, once on the profile or per offer. Values can be fixed timestamps or timestamp data functions, resolved when the wallet claims the credential.

Learn more

Trust Issuers Registered by Public Key, and EUDI Certificate Profiles

ETSI trust lists can now match issuers that have a public key but no certificate, typical for did:web. The X.509 library also gained EUDI profiles for PID Provider, Wallet Provider and Wallet Relying Party certificates.

Safer Verifier2 Memory Use

Verifier2 now bounds its in-memory sessions (2,000 sessions and 256 MiB by default, configurable), stores large byte values compactly, and reports an unreachable dependency as a temporary 503 instead of a client error.

Namespace Mapping and Date Functions for mDocs

mapping now reaches the claims inside mDoc namespaces, including ISO full-date claims via the new , and functions. A mapping key that doesn't match an existing namespace is rejected with a clear error.

Fixes and Improvements

• Stricter x509_hash client IDs. The request's certificate chain is validated, the signature is checked against the leaf certificate, and the leaf's hash must equal the hash in the client ID. Otherwise the request is rejected. #2193
• Verifier2: Omitting clientId keeps working. An unsigned Verifier2 session without a clientId still binds to redirect_uri:<response_uri>, and the config loads correctly. #2170
• Client-bound OpenID4VCI proofs include iss, set to the OAuth client_id. Anonymous pre-authorized proofs omit it, and Issuer2 checks it only when present. #2246
• Issued mdocs stay bound to the holder key that created the device signature. Isolated issuance must pass that key id; presentation no longer falls back to a wallet-default key. #2154
• Policy-result event fires once. credential_policy_results_available is emitted from a single place per verification session. #2153
• Verifier2 and wallet presentation do one DCQL selection per presentation, and crypto2 key restore caches the private/public consistency proof #2209
• Portrait capture dates are full timestamps in newly issued mDocs. Date-only input is still accepted. #2192
• One status-list codec for all formats. Token Status List, Bitstring Status List, StatusList2021 and RevocationList2020 share one library, and the verification policies use it. #2248
• Issuer2 and Verifier2 can register a subset of protocol routes. Unregistered groups are absent from the routing tree and return 404. Full deployments keep the full route set #2158
• Portal2 keeps signing keys server-side. Signed PID presets read their keys from NUXT_PID_* environment variables, unsigned basic-pid is unchanged, and the Helm deployment can supply the secret. #2186 · #2219
• Portal2 issuance shows a credential card grid. The bundled Issuer2 sample catalog now carries card display metadata. #2252
• Certificate issuance can copy the CSR subject DN as a binary distinguished name, validates basic constraints, and has a Java-facing helper for certificate and Crypto2 key creation

Enterprise Stack (1.1.1)

Below are the new feature highlights available through 1.1.1 of the Enterprise Stack. Check out the full change log for 1.1.1 here. Note, also the 1.1.0 version was published this week. Want to learn more about the enterprise stack in general? Check out our intro video.

1.1.1

Features

OpenID4VP request authentication in Wallet2

Wallet2 now checks who is asking before it shows or shares anything. Signed OpenID4VP requests must match certificates specified, relying parties from a linked Trust Registry, or clients you registered. Otherwise they're refused.

Learn more

Issuer2 Batch Issuance

Put several credentials in one offer, or let a wallet request multiple proof-bound copies of the same credential in one go. Existing single-credential offers keep working unchanged.

Learn more

Control mDoc Validity with msoData

Decide when an issued mDoc becomes valid, when it expires, and when wallets should expect a refresh. Set it once on the profile, or override it per offer. Values can be fixed timestamps or timestamp data functions, resolved when the wallet claims the credential.

Learn more

Default Requests for Services

Store the settings that never change on the service itself, such as verifier flow type, signing and keys. Then send only what differs per call. Works on Verifier2, Wallet2, the X.509 service, DID service, VICAL, Client Attestation and Trust Registry.

Learn more

EUDI Certificate Profiles in the X.509 Service

Issue PID Provider, Wallet Provider and Wallet Relying Party Access certificates, and create or replace any certificate at a known ID. A draft Wallet Relying Party Registration profile is included.

Learn more

One-Call X.509 Issuer Onboarding

Bootstrap a complete X.509 issuer in a single init request: KMS keys, X.509 service and store, an IACA (or your existing one) and a document signer.

Trust Issuers That Only Have a Public Key

Issuers registered on an ETSI trust list by key alone, typical for did:web, can now be trusted. Verifier2 resolves their key and matches it against the list automatically, and you can also query it directly.

Learn more

Read a Credential's Status

Look up the current status of an issued credential by its issuance session or its status-list index.

Learn more

Sign with Stored Certificates

Verifier2 and credential-status signing can now use certificates from an X.509 Store, so you don't paste chains into configs.

Learn more

Clearer Licensing Limits

Monthly usage limits now say so in the error, so you can tell them from hourly caps. Offline licenses step down gradually as usage grows, and an installation can recover from an expired license using its seed.

Safer Defaults for Dev Mode and Superadmin Setup

Dev-mode routes now need a secret token, and superadmin bootstrap tokens work only in dev mode unless you mark them for production.

Learn more

Fixes an 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.

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.

eIDAS 2 Industry Guides

We published dedicated guides on what eIDAS 2 and the EUDI Wallet mean for different industries, which deadlines apply, and how to become compliant.

• Public Sector – Mandatory wallet acceptance and issuing official documents as digital credentials.
• Financial Services – Wallet acceptance, wallet-based SCA under PSD2 with TS12, reusable KYC, and the 2027 deadline.
• Insurance – Customer due diligence, wallet-based onboarding, underwriting from verified credentials, and proof of cover.
• Healthcare – Identifying patients and clinicians, the European Health Data Space, cross-border care and the digital EHIC.
• Education – Wallet acceptance for institutions, issuing diplomas and micro-credentials into wallets, and the link to Europass and European Digital Credentials.
• Telecommunications – Customer onboarding and SIM registration, cross-border sign-up, and SIM-swap and porting protection.
• Transport & Mobility – The EU digital driving licence in the EUDI Wallet, verifying licences and entitlements in seconds, and digital travel credentials.
• Energy & Utilities – Faster customer onboarding, proving eligibility for support, and issuing proof of supply.
• Postal & Delivery Services – Online identification, verifying recipients at collection and handover, and age-restricted deliveries.
• Very Large Online Platforms – What the wallet acceptance obligation requires, verified accounts for people and businesses, age assurance and trader verification.

The full picture is available in our eIDAS 2 hub.

WeBuild Pilot Payments Demo at GDC

As part of the GDC conference, we worked together with Authologic, Visa and Mastercard to demonstrate upcoming WeBuild Pilot use cases for payments, with walt.id acting as a Wallet Provider.

The demo showcases:

• DPC & mDL issuance
• Payment authentications & age check

using the cross-device flow (mobile phone & desktop) and the Digital Credentials API.

See the demo on LinkedIn

PS: If you enjoy working with our tools, make sure to leave us a ⭐ on GitHub