Proposal: Define a post-OID4VP authentication and authorization integration pattern

[Vanderkast]

This issue proposes adding explicit guidance to OID4VP on how it is intended to integrate OID4VP into a system authentication and authorization.

Problem definition

Currently, OID4VP defines how a Verifier requests and receives a verifiable presentation (vp_token) from a Wallet. That is a great mechanism for End-User authentication and consent acquisition. However, the specification does not define or describe how the result of a successful VP verification should give client an access to multiple APIs or services within a larger system.

In practice, vp_token is not suitable to be used directly as authorization material:

• it is bound to a single presentation exchange;
• it may be large, privacy-sensitive, and short-lived;
• reusing or forwarding it to backend APIs conflicts with common OAuth2/OpenID Connect security and deployment patterns.

Proposal

1. Add a security consideration not to use vp_token as an authorization material (access_token).
2. Add an appendix (or plural) to outline a OID4VP-based authentication process:
   1. Post-verification token issuance
      1. After successful VP verification, the Verifier MAY issue an internal access token, session or OAuth2-style token representing the authenticated subject and derived authorization context.
      2. This option might be considered when existing authorization provider does not support OID4VP.
   2. Integration with OAuth 2.0 / OpenID Connect
      1. OID4VP MAY be used as an authentication/authorization step that precedes or replaces traditional user authentication in OAuth2/OIDC flows.
      2. The output of OID4VP verification can serve as input to an authorization server for access token issuance.

Additional context

1. The proposed implementation consideration may be defined in "Response mode direct_post" (ref) fashion.
2. "End-User Authentication using Credentials" (ref) worth a reference in the proposed implementation consideration.
3. Probably, OID4VCI Interactive Authorization Endpoint (ref) is sufficient for such use cases.

[jogu]

Discussed on today's WG call:

• Joseph will add a description of how this could work later
• We should add a security consideration like Valentin suggests
• Open Question: Should we describe the typical relying party -> AS -> requests VP -> AS -> returns access token to RP model in the spec?

[jogu]

So some thoughts from me personally to write down what I tried to express on the call today:

I think in this case we should probably use the term "relying party" rather than "verifier".

One way to do this:

1. The relying party (i.e. the website the user is on) could redirect the user to an authorization server
2. The authorization server could then use openid4vp (via redirects or DC API) to request a credential
3. The wallet is invoked as per normal and returns a credential to the AS
4. The authorization server validates the returned presentation
5. authorization server redirects back to the relying party with an authorization code
6. relying party exchanges authorization code for an access token and carries on

Note that there are significant concerns about the overuse of VCs (e.g. https://www.centerforcybersecuritypolicy.org/insights-and-research/a-new-approach-to-address-concerns-about-overuse-of-digital-ids ) so the above might only be expected in a sign up flow (if a credential is for some reason needed for signup) and after that the user should be issued with a passkey to use for authentication in the future.

(alternative link about overuse as people didn't like the above one: https://www.w3.org/2001/tag/doc/prevent-credential-abuse/#overuse )

[timcappalli]

These patterns are really important to document, but I actually think it should be a different specification (or document).

[fkj]

I would prefer to put the patters in e.g. an OIDF white paper. I think the OIDF Ecosystem CG would be a natural place to do that kind of work.