Keycloak is being extended to produce verifiable credentials See Discussions on OID4VC.

There are many scenarios where the holder of a verifiable credential want to:

1. consume a keycloak service,
2. consume a service that does not support the presentation of a verifiable credential,

Further, some Clients will be accessing resource servers that are not able to consume verifiable presentations.

In most of these cases, having keycloak exchange a vp_token against an equivalent access token will service the purpose.

We might have many way of approaching this topic:

1. Proceed with a new grant type which allows keycloak to exchange a vp_token against an access token
2. Proceed with the token exchange grant type, and extend the token exchange endpoint to provide this capability.

Following are tasks we will be going after:

1. Validation of vp_token, for each format supported, keycloak will be validating the vp_token prior to issuing the access token.
2. As VCs can be key bound to holder, keycloak can produce a key bound access token in exchange of a vp_token that presents a valid key binding jwt (see DPoP)
3. In case of any selective disclosure, the returned token will only contain vp disclosed claims.

See:

• OpenID for Verifiable Presentations - draft 20
• Selective Disclosure for JWTs (SD-JWT)