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)?

does this issue overlap with #174 ? It seems like we can probably close one of them?

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

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

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.

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 #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.