Define SessionTranscript and JARM for mso_mdoc format in 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 #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)