Repository navigation
[OID4VCI] Feedback how Keycloak will be used for credential issuance #48764
Replies: 2 comments
|
I agree, the decision on whether Keycloak can be deployed by these government organizations will largely depend on whether it meets their specific requirements. The Keycloak Verifier will only be deployed when it is part of an official KC release and not "experimental". Likewise for the Issuer - that the ABCA spec i 8000 s not final doesn't matter, it is still part of HAIP, which defines what must be supported. As mentioned in SIG meetings already, IMHO conformance is key. Both, in terms of what the OpenID Foundation defines in its tests and what government (e.g. EU) defines in their architecture requirements. For example, the Keycloak Issuer needs to be able to register a given credential with an external revocation service it does not need to become a revocation service (perhaps even limited to its own issued credentials). I'd vote for Keycloak becoming HAIP conformant for both Issuer + Verifier a.s.a.p. and for OID4VCI becoming "preview" as soon as it does. Other big topics like external credential data provider and integration with revocation services can be driven by SIG members, as they seem to know best what is actually needed by large organizations. |
|
I completely agree. A mapping of this standard and functionality strengthens essential digital sovereignty aspects with regard to the software supply chain and use in the EU. One of the main reasons why we opted for open source and Keycloak in public sector projects. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There are a lot of discussions about the (initial) scope of OpenID4VCI in Keycloak right now (for example in the OAuth-SIG). So i wanted to provide the perspective of how a big government customer intends to use Keycloak for issuance.
There are also discussions between different authorities, so i think that might be a more common pattern. The baseline is, that a lot of (most?) credentials will be based on data outside of keycloak because they attest some kind of business state that is not stored inside Identity Management. Keycloak will therefore be mostly be used for the issuance protocol layer, while data and revocation information is stored elsewhere.
There is also a discussion if Token Status List shall be supported initially. From my perspective, Keycloak will not be usable without some support for it, because real-world credentials need to be revocable and revocation information will be based on business events and not on some Keycloak-internal configuration like lifespans.
Providing a way to include some external status list information in the credential might be sufficient here. Keycloak itself doesn't have to implement the specification itself.
The following architecture sketch illustrates the intended usage of Keycloak in this scenario:
Furthermore, Credential Issuance will be mainly used in the EUDI-Wallet ecosystem. So implementing the bare minimum of OpenID4VCI will not be enough to be usable in the real world. The EUDI Architecture Reference Framework (ARF) mandates HAIP for example, which in turn depends on the not-yet-finalized Attestation-based Client Authentication specification. So despite it being not finalized yet, it will be necessary to issue credentials to real wallets in 2027.
I think Keycloak has a big opportunity here to be widely used in the emerging EUDI-ecosystem, because a lot of potential customers already use it for authentication and authorization.
I hope that this more customer-centric view helps you in your scope-decisions.
All reactions