v0.1.0-rc.1

Keycloak OID4VP 0.1.0-rc.1

First release candidate under su-engineering. This prerelease is intended for integration testing; it does not establish a long-term support policy or claim HAIP/OpenID conformance.

Included

• Wallet login using OpenID4VP, with SD-JWT VC and mDoc presentations in same-device and cross-device flows.
• Opt-in did:webvh v1.0 issuer resolution with verified history, witnesses and current assertion keys, alongside existing did:web and X.509 verification.
• Multiple credentials per login, required/alternative DCQL combinations, repeated presentations, and server-side claim/value checks against the saved request.
• Full DCQL JSON configuration, identity credential selection and query-specific claim mappers in Keycloak's Admin Console.
• A generic realm import with direct wallet entry, plus su-engineering and openkyc login themes.

Downloads and validation

Choose the JAR matching your Keycloak version: 26.5.4 or 26.5.5, using Java 21. The release workflow runs unit, cryptographic, packaging and Docker/browser integration tests separately for each target before publishing its JAR. SHA256SUMS covers both downloadable JARs.

Rename the selected file to keycloak-extension-oid4vp.jar, replace the previous provider JAR under Keycloak's providers/ directory, then run kc.sh build. Install only one copy of this provider. Review the installation guide.

Upgrade notes

• Change the former oid4vp login theme selection to openkyc; provider aliases and IDs remain unchanged.
• Restart in-flight logins after upgrading. Older request contexts lack the full DCQL snapshot required by this version.
• DCQL constraints are now enforced on responses. Use presentation arrays in JSON vp_token entries and configure an identity query plus query-specific mappers for multi-credential logins.
• Scalar mappings that match several credentials reject ambiguity; multi-valued session-note arrays use JSON.
• did:webvh is opt-in. Add it to Allowed DID Methods and configure issuer trust explicitly.

Read the migration guide before updating an existing realm.

Known limits

Automated wallet tests use synthetic issuers. Acceptance testing with your deployed issuer and wallet is still required before promotion. Legacy did:web key authorization and path/port handling, persistent WebVH anti-rollback checkpoints, and cross-credential subject relationships remain outside this release's guarantees. mDoc requires one document per DeviceResponse, and login requires holder binding for every credential. See the readiness plan.

Very fast wallet callbacks can race request-context persistence and receive session_expired. The integration test helper retries once in that case; deployments should include this timing scenario in wallet acceptance testing.