define where in mdoc presentation to include transaction data

[Sakurann]

for sd-jwt vc, it is in key binding jwt. for mdoc, is it session_transcript?

[c2bo]

If I recall correctly, someone mentioned a week ago that this is already defined/proposed somewhere for mDoc? Might've been @martijnharing (sorry if I recalled and tagged you incorrectly)?

[jogu]

does this issue overlap with https://github.com/openid/OpenID4VP/issues/174 ? It seems like we can probably close one of them?

[Sakurann]

I was hoping to close #174 and few other issues with PR #197

[leecam]

for mdocs wouldn't it be in the device signed data?

[babisRoutis]

Dear @Sakurann

Kindly requesting, to consider prioritizing the present issue.

EUDIW Ref. Impl. has to add support for transaction_data to the rQES use-cases.

Given that currently (ARF 1.5) defines PID only in mso_mdoc, our RSSP AS requires from the holder to present a PID in mso_mdoc to authorize the use of a signing key.

[sander]

EUDIW Ref. Impl. has to add support for transaction_data to the rQES use-cases.

Given that currently (ARF 1.5) defines PID only in mso_mdoc, our RSSP AS requires from the holder to present a PID in mso_mdoc to authorize the use of a signing key.

@babisRoutis This is an important use case. See https://github.com/openid/OpenID4VP/pull/421 for a first clarification. If this clarification is correct, the work is out of scope for OIDF and in scope for CSC and EC. In my interpretation, we need:

• the CSC data model to specify:
  • a transaction data type https://cloudsignatureconsortium.org/2025/qes for authorizing the use of a signing key;
  • an mdoc NameSpace identifier
  • for each parameter in this transaction data type:
    • the DataElementIdentifier string value;
    • the DataElementValue CBOR type and encoding rules;
• the PID rulebook to specify:
  • support for these device-signed (mdoc authenticated) attributes.

[Sakurann]

resolved by #421 being merged