OpenID4VP and SIOPv2

[reinkrul]

OpenID4VP provides a way for VC verifiers to request a one or more credentials, in the form of a presentation, from a wallet. For Nuts, this is applicable in data exchanges where a user is required to be present (since it's a flow for when a browser is involved). E.g., when the receiving care organization wants to read medical data at the sender organization's systems. The flow is used during an OAuth2 Authorization Code flow (to get an access token) to authenticate the end-user on the requester's side. The wallet yields 2 response tokens:

• vp_token containing proof of the requester's care organization (at first, NutsOrganizationCredential, ideally a trusted-third party issuer)
• id_token containing proof about the end-user's identity (name, role)

id_token

This token is negotiated through the SIOPv2 protocol.

vp_token

This token is negotiated through OpenID4VP using a DIF Presentation Exchange. In the Nuts use cases it will (probably) be a scope, mapped to a presentation definition, yielding a NutsOrganizationCredential.

Work items

Core protocol

• Support direct_post mode for sending the authorization response from wallet to verifier, instead of having it as parameters on the redirect back to the verifier.
• Replace hardcoded metadata URLs with the ones specified by #2443)
• Validate redirect URI sent by verifier
• Implement id_token (needs design work)
• Implement /token path
• Match Presentation Definition with credentials in wallet, instead of just loading credentials from VCR store (requires #2389)

UI

• Do some styling of the HTML templates for the "WOW!" factor
• i18n HTML templates (we should at least support Dutch) Openid4vp i18n #2449

Other nice to have's (not required for eOverdracht, compatibility with third parties or systems)

• Support VPs in JWT format (consuming and producing), for compatibility with non-Nuts nodes (VCR: JWT support for credentials and presentations #2520)
• Support presentation_definition and presentation_definition_uri, so the presentation definition can be specified there (by the verifier) instead of mapping it from scope.

[woutslakhorst]

Support presentation_definition and presentation_definition_uri, so the presentation definition can be specified there (by the verifier) instead of mapping it from scope.

The RP will use scopes and not a definition, so there always be a mapping?

[reinkrul]

In case of Nuts use case, being it part of an access token flow to request access to an API (FHIR resource), but I can imagine other use cases where presentation definitions could be used; e.g., issuance of credential by a third party which requires authentication of the holder with a VC (care organization credential or use case-credential).

But we can postpone support for that one for now. I'll reorder the list for priority.