Define `SessionTranscript` and JARM for `mso_mdoc` format for vanilla OID4VP

[awoie]

Currently, OID4VP refers to ISO 18013-7 for a normative definition for how to use OID4VP with ISO mdocs. This dependency entails the following issue we could resolve by defining how to use the OID4VP request information to configure the SessionTranscript in the ISO mdoc response and JARM directly in the OID4VP specification:

• The final version (still under publication) of ISO 18013-7 refers to a specific version of OID4VP (ID-2). Even if ISO 18013-7 gets a new revision, the new version of ISO 18013-7 would lack behind changes or improvements introduced in future versions of OID4VP. For example, if we consider updating OID4VP to v1.1 or even v2.0 at some point, these changes wouldn't be available in ISO 18013-7 automatically.
  • One example would be the necessary updates around client ID scheme as described in client_metadata_uri security considerations OpenID4VP#14 that will become available in OID4VP v1.0, or
  • the expected_origins parameter when ISO mdocs are used with the Browser API.
• Since ISO 18013-7 was written with the mobile driving license use case in mind, it only allows the x509_san_dns client ID scheme. Other schemes should be possible as well if compliance to ISO 18103-7 is not a requirement for certain ecosystems.

The SessionTranscript is essentially a big detached nonce that is signed/mac'ed by the VP. Additionally, the mdoc section should define how to use JARM and how to use the apu (set to nonce) and apv (set to wallet nonce) values of the JWE to bind the encryption to the current transaction.

Additionally, the DCP WG should recommend to the ISO WG, to use the SessionTranscript definition from OID4VP instead in future revisions of ISO 18013-7.

Discussion point is how to distinguish between ISO 18013-7 SessionTranscript and the SessionTranscript defined in OID4VP when decrypting the JARM, and verifying the VP but this problem has to be solved as well when updating to a new version of SessionTranscript in ISO 18013-7 anyways, or more specifically OID4VPHandover (nested in SessionTranscript). I guess one solution could be that ISO 18013-7 defines to use the mdoc-oid4vp:// with their profile which could still indicate that their specific version is used while other ecosystems might define their own URI scheme. Note that for Browser API this problem would be no issue since ISO 18013-7 does not define Browser API yet.

I propose to add the CDDL for the SessionTranscript specific to OID4VP regular and Browser API to the mso_mdoc format section of OID4VP and also define how to use apu and apv values if JARM is used.

(cc @martijnharing @tplooker)

[Sakurann]

we have #135 and #131 now. closing in a week if no objections

[awoie]

To close this, we should create an issue for OID4VP using ISO mdoc over non-Browser API, right? Since this would require us to define another SessionTranscript. Would you agree, then I can create a ticket? I believe this is also expected according to the ISO meeting minutes you cited in the other issue.

[Sakurann]

ah, ok. good point. we can rename this ticket to talk about sessiontranscript for mdoc over vanilla OID4VP, or you can open a new ticket. i am ok either way - please let me know

[aarmam]

How is the mdoc generated nonce returned to verifier?

ISO 23220-4 / ISO 18013-7 state:

The mdoc App shall set the apu JWT (JWE) header parameter to the base64url-encoded-without-padding value of the mdocGeneratedNonce of the SessionTranscript as defined in Section 6.2.1.2.6.2.5.4. The mdoc shall set the apv JWT (JWE) header parameter to the base64url-encoded-without-padding value of the nonce Authorization Request parameter from the Authorization Request Object.

But this means response_mode=direct_post.jwt/fragment.jwt/query.jwt with only encrypted JWT is possible?

The SessionTranscript is essentially a big detached nonce that is signed/mac'ed by the VP. Additionally, the mdoc section should define how to use JARM and how to use the apu (set to nonce) and apv (set to wallet nonce) values of the JWE to bind the encryption to the current transaction.

ISO 23220-4 / ISO 18013-7 states that apu is set to wallet nonce and apv to nonce. I assume this is a mix up.

[jogu]

session transcript happened in openid/OpenID4VP#610 - apu/apv the WG decided not to do in openid/OpenID4VP#628 (comment)

closing as we have a separate ticket for the non-DC API mdoc profile.