[Presentation] OpenID 4VP and HAIP updates

[peppelinux]

Within the LSP Potential there is an ongoing conversation about the impacts of moving forward the technical requirements up to OpenID4VP Draft number 22 and OpenID HAIP draft 02.

This issue aims to clarify that it would worth to get LSP Potential aligned with the latest OpenID draft, therefore with OpenID4VP Draft number 24 and OpenID HAIP Draft number 03.

OpenID4VP 22 -> 24

Generally, DCQL and the remove of client id scheme was introduced in draft 22 and already implemented in the current technical specs version 0.9.1.
Draft 23 and 24 consolidates the implementations of W3C Digital Credentials API and mdoc cbor. Only all about mdoc cbor should be considered for interop in the interop stage, since W3C Digital Credentials API is kept out of requirements.

Another new feature is the transaction_data in the presentation flow, something required for the new use cases.

24

• add mdoc specific intent_to_retain mechanism, using the definition from 18013-5
• require typ value in request object to be oauth-authz-req+jwt
• add SessionTranscript requirements about mdoc cbor

23

• choice of encryption JWE algorithms available, HPKE draft for Mdoc cbor should be considered too
• transaction_data in presentation
• dcql_query to list of allowed parameters in W3C Digital Credentials API appendix (out of scope)
• change credential format identifier vc+sd-jwt to dc+sd-jwt to align with the media type in draft -06 of [I-D.ietf-oauth-sd-jwt-vc]
• generalized W3C Digital Credentials API references (out of scope)
• changed response mode value for the OID4VP over the W3C Digital Credentials API (out of scope)
• updated to PE ver 2.1.1 (used to be 2.0.0) (Please note: PE removed in OpenID HAIP)

22

• Introduced the Digital Credentials Query Language
  add transaction data mechanism
• remove client_id_scheme and turn it into a prefix of the client_id; this addresses a security issue with the previous solution
• Clarified what can go in the client_metadata parameter

OpenID HAIP 02 -> 03

No considerable changes between 02 and 03, only security considerations.

02

• Mandate DCQL instead of presentation exchange
• details for mdoc profile over W3C Digital Credentials API (out of scope)~

[peppelinux]

We also want to map the following requirements

• Mandate A256GCM for response encryption (compliant with 18013-7)
• Specify ES256 to sign the presentation request (specified in the Potential profiles)
• Update to use draft -23 of OpenID4VP and - 02 of HAIP:
  • Deprecating the use of jwks_uri in the client_metadata to pass the RP's public key that the wallet uses to encrypt (jwks will be used instead)
  • MS's are encouraged to transition to DCQL however Presentation exchange will still be valid
• Ensuring that the state parameter is embedded in the payload of the encrypted JWE, not outside encrypted JWE:
  • Mandate client_id_scheme x509_san_dns to sign the request
  • Mandate x509 to sign sd-jwt but support for web-based key resolution with .well-known/jwt-vci-ssuer will still be provided https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwtvc.html#name-jwt-vc-issuer-metadata

[simonebaldiniintesa]

Within the LSP Potential framework, with particular reference to the use of the 'transaction_data' parameter as specified in both the OpenID4VP draft numbers 23 and 24, as well as in the Potential UC5 specs V2, since this parameter is specified as optional, it could be considered to conduct tests on the QES with an approach aimed at minimizing (if not eliminating) impacts on already scheduled activities.

The idea is as follows: Since transaction_data is optional in the UC5 context, in its absence, the presentation transaction, from a technical and functional point of view, is configured similarly to the presentation of a PID for registration or access to an online service (e.g., UC1).

If the QTSPs, acting as RP-Verifiers of the Wallet, were to start submitting PID presentation requests to the Wallet profiled like those that an RP intending to perform a simple online access/registration via Wallet would generate, there is a high probability that there would be excellent opportunities to conduct tests within the QES without expending too much effort compared to the existing roadmap for the already scheduled use-cases.

I propose to address this point during the SAL scheduled for today, March 13, 2025.