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

[tlodderstedt]

Is it just recommended or is this how the data must be represented in SD-JWTs?

[sander]

If we can still include new mandatory requirements at this stage, let’s indeed make it mandatory.

[sander]

I would however suggest to have that detail in a separate issue/PR, to keep the current one’s scope limited to enabling the use of transaction data in other credential formats such as X.509.

[tlodderstedt]

LGTM. Just added small editorial suggestion.

[Sakurann]

mostly editorial comments. but I don't understand why mdoc part is doctype specific and i would like to see If this parameter is not present, a default value of sha-256 MUST be used. readded

[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]

I suggest to drop this section as credential formats can give recommendations but do not need to. Implementers can freely decide which credential formats they use in conjunction with their transaction data types.

[sander]

Done in eaa0426

[tlodderstedt]

not sure whether we should make this a recommendation, too. Example sounds a bit to weak to me.

[tlodderstedt]

@Sakurann WDYT?

[sander]

How about Common Mechanism? Like in RFC 9396 § 2.2.

[Sakurann]

how common we want these to be? we say parameters are transaction data type specific and then we define parameters without binding them to any transaction data type?

[Sakurann]

Thinking about this more, this section on static configuration values is probably the closest to what we are looking for here (https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-profiles-that-define-static)

Suggested change

	#### Example Specification
	#### A Profile of Transaction Data in SD-JWT VC

Another option would be to move this section to implementation considerations, tho that might make it harder to read..

[Sakurann]

Suggested change

	Note: When following this recommendation, the transaction data mechanism requires use of an SD-JWT VC with cryptographic key binding.
	Note: When following this recommendation, the transaction data mechanism requires use of an SD-JWT VC with Cryptographic Holder Binding.

Cryptographic Holder Binding is a defined term we use

[Sakurann]

Suggested change

	* The transaction data includes the following parameter, in addition to `type` and `credential_ids` from (#new_parameters):
	* The `transaction_data` request parameter includes the following parameter, in addition to `type` and `credential_ids` from (#new_parameters):

[Sakurann]

Suggested change

	* The Key Binding JWT includes the following top level claim parameters:
	* The Key Binding JWT in the response includes the following top level parameters: