You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)~
The text was updated successfully, but these errors were encountered:
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.
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
23
choice of encryption JWE algorithms available, HPKE draft for Mdoc cbor should be considered tootransaction_data in presentationdcql_query to list of allowed parameters in W3C Digital Credentials API appendix(out of scope)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
add transaction data mechanism
OpenID HAIP 02 -> 03
No considerable changes between 02 and 03, only security considerations.
02
details for mdoc profile over W3C Digital Credentials API(out of scope)~The text was updated successfully, but these errors were encountered: