Make transaction data credential format specific and define details for sd-jwt and mdoc

[sander]

This enables the QES creation use case where transaction data contains parameters for advanced e-signature creation. In these cases, the transaction data do not get hashed in their JSON representation format using a single hash algorithm. Instead, the X.509 credential format specifies specific ways of processing, that still meet the broadened requirements.

Highlight of changes:

• Leave it up to credential format transaction data type specs to define transaction data support and requirements.
• Clarify that W3C VC and AnonCreds do not have specified transaction data support.
• Clarify how to support transaction data with mdoc.
• Move transaction_data_hashes and transaction_data_hashes_alg into SD-JWT VC format spec.
  • Keep sha-256 a mandatory default.
  • Remove sha-256 interoperability promotion remark.
  • Clarify what to hash.
  • Clarify how to represent the digest.

Closes #423

Closes #418

Relates to #259

Does not address #442, #443

[babisRoutis]

Dear @sander

Can you please update the description of the PR and replace "Context #421" with "Closes #421"?
This will associate the PR with the issue.

[sander]

Done, thanks @babisRoutis.

[babisRoutis]

Done, thanks @babisRoutis.

Pointed description to issue 423.

[tlodderstedt]

@c2bo @sander After re-reading the spec and playing with some examples, I would argue transaction_data_hashes_alg and transaction_data_hashes are designed and might work well for sd-jwt. I'm not so sure for mdoc and I'm pretty sure it does not work well for x.509 (QES). For example, the transaction data type for QES (see below) already contains identifiers for algorithms (hashAlgorithmOID) based on pre-existing standards (ETSi and CSC) and QES/CMS standards define what needs to be incorporated into the signature, some of this data not even passed in the request but obtained from other sources, like time stamping services (in this cases the "T" in "Ades-B-T").

{
    "type": "https://cloudsignatureconsortium.org/2025/qes",
    "credential_ids": [
        "certificate_by_policy"
    ],
    "signatureQualifier": "eu_eidas_qes",
    "documentDigests": [
        {
            "signature_format": "P",
            "conformance_level": "Ades-B-T",
            "signed_envelope_property": "Certification",
            "label": "Example Contract",
            "href": "https://protected.rp.example/contract-01.pdf?token=HS9naJKWwp901hBcK348IUHiuH8374",
            "checksum": "sha256-sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
            "access": {
                "type": "OTP",
                "oneTimePassword": "51623"
            }
        }
    ],
    "hashAlgorithmOID": "2.16.840.1.101.3.4.2.1"
}

Based on those thoughts, I would suggest to make the way transaction data is included or referenced truly a credential format specific thing. That would mean to move transaction_data_hashes_alg and transaction_data_hashes to appendix B.4 and change the second and third paragraph in section 8.4 to something like

"The Wallet that received the transaction_data parameter in the request MUST include a representation or reference to the data in the in the respective credential presentation. How this is done is specific to each credential format and is defined by each Credential Format, such as those in Appendix B. If the wallet does not support transaction_data parameter, it MUST return an error."

[sander]

@tlodderstedt agreed. My original PR was to keep the change as small as possible, but your proposal is the better change.

For mdoc queries, the transaction data is expected to be returned as DeviceSignedItems. That means that the document type specification should include attribute definitions matching the transaction data requirements. This is something we cannot specify in detail in OpenID4VCI. Instead CSC should ensure that rulebooks get published/extended with device-signed attribute definitions confirming QES creation in the QTSP-centric model. This could be an extension of the PID rulebook in the case of one-time signatures for example. For the Wallet-centric model, we’re good already.

Since OID4VCI also specifies a W3C VC credential format, what would be the best way to include transaction data there?

[Sakurann]

WG discussion:

• keep text with terminology specific to mdoc/sd-jwt vc, but add a generic text that transaction data type rules the content of transaction data and each credential format defines how to incorporate it.
  • how The Wallet that received the transaction_data parameter in the request includes a representation or reference to the transaction data in the respective credential presentation is transaction data type specific, not credential format specific.
• current text for mdoc makes sense: each transaction data type defines namespace etc and each doctype defines whether it authorizes that transaction data type
• agreed to provide the same level of flexibility to sd-jwt vc (keeping transaction_data_hashes_alg and transaction_data_hashes parameters as recommendation/jfyi, or potentially dropping them even)

[tlodderstedt]

non-normative example does not match the new heading in my opinion. Suggest to frame it as "example profile" or "one profile"

[sander]

abcddf1