EUDI Wallet Relying Party with Keycloak: Where OpenID4VP Support Actually Stands

Last updated: September 2026

Keycloak cannot act as an EUDI wallet relying party in any released version. An OpenID4VP identity provider exists in the upstream main branch, gated behind the experimental feature oid4vc-vp, with same-device and cross-device flows, SD-JWT VC support and a DCQL query field. It is absent from 26.6.0, 26.7.0 and 26.7.3, the current release as of 31 August 2026. What Keycloak does ship today is the other half of the story, OID4VCI credential issuance, itself still experimental. If you need to accept wallet presentations now, your options are a community extension, a verifier in front of Keycloak, or waiting for a release that has not been scheduled.

Most of what is written about EUDI and Keycloak treats issuing credentials and accepting them as one topic. They are different protocols, different code paths, and right now they sit at very different levels of maturity.

Can Keycloak act as an EUDI wallet relying party today?

Not in a version you can download. We checked the upstream source tree at three release tags: services/src/main/java/org/keycloak/broker/oid4vp/OID4VPIdentityProvider.java is absent from 26.6.0, 26.7.0 and 26.7.3, and present on main. The 26.7.0 release notes cover verifiable credential work at length, and every line of it is about issuance.

Two details matter if you go looking yourself. First, on main the provider is gated behind an experimental feature flag, oid4vc-vp, declared in Profile.java as “Support for the OID4VP protocol as part of OID4VC.” Building main without enabling it will not show you the provider. Second, that flag does not exist in 26.7.3 at all, which is the cleanest confirmation that the capability is not quietly present and switched off in the release.

Verification note: this is a reproducible check rather than an opinion. Request the file path above at a release tag and at main, and compare the OID4VC_* entries in Profile.java between the two. It takes about a minute and it settles the question more reliably than a blog post that says “Keycloak supports OpenID4VP” without naming a version.

A future release will presumably carry it. Which one is not knowable today: the draft 26.8 release notes on main do not mention OID4VP anywhere, so anyone planning against a specific version is guessing.

What does the December 2026 deadline actually require?

Member States must make at least one European Digital Identity Wallet available by 24 December 2026, under Regulation (EU) 2024/1183, the regulation commonly called eIDAS 2.0. Article 5a sets the obligation at twenty-four months after the relevant implementing acts enter into force. Those acts, Commission Implementing Regulations (EU) 2024/2977 through 2024/2982, were adopted on 28 November 2024, published in the Official Journal on 4 December 2024, and entered into force twenty days later on 24 December 2024. That entry-into-force date, not the adoption date, is what fixes the deadline.

The part that matters for a private-sector platform team is the second date. Under Article 5f, the obligation on the regulated private sector to accept wallet presentations follows thirty-six months from the same entry into force, on 24 December 2027. December 2026 is when wallets exist in citizens’ hands. December 2027 is when a bank, a telco or another entity in a regulated category has to take one.

That gap is your implementation window, and it is a year rather than three months. A team treating December 2026 as its acceptance deadline has misread which obligation falls when.

The governance work is the part that does not wait. A relying party under the regulation is a registered entity, declaring which attributes it requests and for what purpose, and that registration happens with a national registrar rather than in your IdP configuration. Confirm the specifics with the registrar in your Member State, because national implementations differ and the technical integration is often the smaller share of the work.

Is OID4VCI the same thing as OpenID4VP?

No, and the distinction decides which Keycloak features are relevant to you. OID4VCI is credential issuance: a user obtains a credential from an issuer and stores it in a wallet. OpenID4VP is credential presentation: a relying party asks a wallet to present a credential and verifies it. An EUDI relying party needs the second one, and Keycloak ships the first one.

Keycloak 26.7.0 brought substantial OID4VCI work, all of it still under an experimental feature flag:

• Full admin console configuration, no longer admin REST API only
• Conformance with the OpenID4VC High Assurance Interoperability Profile (HAIP)
• A new experimental feature client-auth-abca for attestation-based client authentication
• Pre-authorized code grant moved behind its own experimental feature, oid4vc-vci-preauth-code
• Per-user credential management, including issuance started from the account console
• A configurable credential refresh interval, vc.refresh_interval_in_seconds, defaulting to seven days or the credential lifetime, whichever is smaller

That is a healthy issuance story, and it does nothing for a relying party.

What does the upstream OpenID4VP identity provider do?

It models the wallet as an identity provider, which fits the rest of Keycloak better than it might first appear. Reading the code on main, the provider authenticates a user via a wallet presentation of a single SD-JWT VC, and supports both flows the specification defines. For a wallet on the same device it renders an openid4vp:// link. For a wallet on a different device it renders a QR code carrying the same parameters.

The pieces visible in the source:

• A configurable wallet URL scheme, defaulting to openid4vp://
• A DCQL query field, the Digital Credentials Query Language used to state which credential and claims the verifier wants
• X.509 trust material handling, with direct_post and direct_post.jwt response modes
• An “OpenID4VP (Wallet Login)” entry in the admin console identity provider list
• Conformance tests that drive the OpenID Foundation conformance suite’s wallet against a Keycloak verifier

Modelling the wallet as an IdP means the rest of your realm keeps working unchanged. Verified attributes arrive through the same identity provider brokering path you already use for any federated provider, and land in users, organizations and token claims through ordinary mappers.

One caveat visible in the code: the flows are documented around a single SD-JWT VC. A presentation combining several credentials from different issuers is a more complicated case. The mdoc format that the EUDI architecture also uses has its own experimental flag, oid4vc-mdoc, which the source notes depends on either the issuance or the presentation feature being active.

What are your options before the release lands?

Three, and only the first two are available this quarter.

Use a community extension. The most active is ADORSYS-GIS/keycloak-oid4vp-plugin, which adds OpenID4VP authentication to Keycloak, tests against current 26.7 releases, and has been developed alongside the upstream discussion thread on Keycloak as a wallet verifier. Others exist, including work tested in the German SPRIND sandbox. The trade is the usual one for extensions: you take on a dependency that has to track Keycloak’s own release cadence, and its maturity is not the upstream project’s maturity.

Put a dedicated verifier in front of Keycloak and broker it. The verifier speaks OpenID4VP to the wallet, validates the presentation, and hands Keycloak an authentication result over a protocol Keycloak already supports. This is the same shape the upstream provider implements internally, which is what makes it a good interim position.

Wait for the upstream provider to ship. Reasonable only if your own deadline is past 2027, given that no release has been named.

If you take the second route, the sequence worth designing now:

1. Keep verification outside the authorization server. The verifier performs the wallet exchange, checks the signature chain, checks revocation, and checks the credential against your attribute policy.
2. Hand the result to Keycloak as a brokered identity. An OIDC identity provider pointed at your verifier is the least surprising option, and it is the path the native provider will eventually replace without changing what sits downstream.
3. Map attributes deliberately, once. Decide now which wallet attributes become user attributes, which become organization membership, and which become token claims.
4. Log the presentation, not the credential. Keep the audit evidence that a valid presentation occurred, and avoid storing attribute values you did not need, because purpose limitation is central to the regulation.

Step 3 is the one with the highest payoff. If your attribute mapping lives in Keycloak rather than inside the interim verifier, swapping the verifier for the native OID4VP provider later becomes a configuration change instead of a migration.

Data-minimisation obligations here are closely comparable to the ones we covered for Quebec’s Law 25 and PIPEDA, also available in French, and to the audit expectations in HIPAA-compliant managed Keycloak.

What should an EU-facing platform do about residency?

Decide where the realm runs before deciding how the wallet talks to it, because the residency answer constrains the architecture rather than the other way around. A wallet presentation carries identity attributes of EU residents, and the verification step processes them even when you discard them immediately afterward.

In practice that means an EU-resident cluster for the realm and the verifier both, since a verifier deployed outside the region reintroduces the transfer question you moved the realm to avoid. It also means the audit trail lives in the same region. We covered the general shape of that decision in cloud identity management.

Where managed Keycloak fits

Skycloak is identity management as a service built on upstream Keycloak, which means our answer on OID4VP is the same as upstream’s: it is not in a release yet. What we can carry is the tracking and the upgrade path, so that when the provider does ship in a release, the realm it needs to land in is already on a current version with the attribute mapping in place.

The alternative is watching a main branch yourself and discovering on upgrade day that your interim verifier and the native provider disagree about claim names. The general arithmetic on that trade is in is self-hosting Keycloak worth it in 2026, and the vendor comparison is in managed Keycloak providers compared.

FAQ

Does Keycloak support OpenID4VP?
Not in a released version. An OID4VP identity provider exists in the upstream main branch behind the experimental feature oid4vc-vp, with same-device and cross-device flows, SD-JWT VC support and DCQL queries. It is absent from 26.6.0, 26.7.0 and 26.7.3, and the draft 26.8 release notes do not mention it.

What is the difference between OID4VCI and OpenID4VP?
OID4VCI issues credentials into a wallet. OpenID4VP presents credentials from a wallet to a verifier. A relying party accepting EUDI wallet presentations needs OpenID4VP. Keycloak ships OID4VCI today as an experimental feature, and that does not help a relying party.

When must my service accept EUDI wallets?
Member States must make wallets available by 24 December 2026 under Regulation (EU) 2024/1183. The obligation on the regulated private sector to accept them follows under Article 5f on 24 December 2027, thirty-six months after the implementing acts entered into force. The availability date and the acceptance date are frequently confused.

Can I add OpenID4VP to Keycloak with an extension?
Yes. Community extensions exist, the most active being the ADORSYS-GIS OpenID4VP plugin, which tests against current 26.7 releases. An extension means taking on a dependency that has to track Keycloak’s release cadence, so treat its maturity separately from the upstream project’s.

Is relying-party registration a Keycloak configuration task?
No. Registration as a relying party, including declaring which attributes you request and why, happens with a national registrar under the regulation rather than in your identity platform. National implementations differ, so confirm the process with the registrar in your Member State early.

Sources

• European Union, Regulation (EU) 2024/1183 (eIDAS 2.0), Articles 5a and 5f, on the European Digital Identity Framework, https://eur-lex.europa.eu/eli/reg/2024/1183/oj
• European Union, Commission Implementing Regulation (EU) 2024/2977 of 28 November 2024, published 4 December 2024, in force 24 December 2024, https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32024R2977
• Keycloak, OID4VPIdentityProvider on the main branch, verified absent at tags 26.6.0, 26.7.0 and 26.7.3 on 2026-09-13, https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/broker/oid4vp/OID4VPIdentityProvider.java
• Keycloak, Profile.java on the main branch, OID4VC_VP experimental feature declaration, retrieved 2026-09-13, https://github.com/keycloak/keycloak/blob/main/common/src/main/java/org/keycloak/common/Profile.java
• Keycloak, release 26.7.0 notes, “Progress on Verifiable Credentials (OID4VCI) (experimental),” retrieved 2026-09-13, https://github.com/keycloak/keycloak/blob/main/docs/documentation/release_notes/topics/26_7_0.adoc
• Keycloak, discussion 47346, “Keycloak as Wallet-Verifier (OpenID 4 Verifiable Presentations),” https://github.com/keycloak/keycloak/discussions/47346
• ADORSYS-GIS, keycloak-oid4vp-plugin, retrieved 2026-09-13, https://github.com/ADORSYS-GIS/keycloak-oid4vp-plugin
• OpenID Foundation, “OpenID for Verifiable Credential Issuance 1.0,” https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html