Some high-assurance flows, especially when dealing with DPCs, require additional security and traceability when producing presentation responses. Under [PSD2], the burden of proof for payments and SCA rests with the payment service provider. As a result, each transaction response must contain enough information to prove, or at least reconstruct, what happened.
The credential and its content are protected and can be cryptographically linked to the response; its display metadata is not. Yet credential selection in a transaction is driven by that metadata, which makes it part of the user's consent and therefore something that must also be protected.
Currently, there is no practical way to sign credential-specific display metadata directly. In practice, the only available option is to rely on signed issuer metadata, which can become disproportionately large and would bundle unrelated data into proof packages and audit logs.
For our purpose, we have extended OID4VCI as follows:
- A new
credential_metadata_uri parameter is added to credential_configurations_supported, allowing credential-specific metadata to be retrieved separately from general issuer metadata.
- When the
Wallet Unit requests Accept: application/jwt from the credential_metadata_uri, the Credential Issuer returns a signed JWT whose JOSE header contains typ=credential-metadata+jwt and an x5c certificate chain that resolves to the same attestation rpovider as the credential. The payload contains iss, identifying the Credential Issuer Identifier; sub, identifying the credential type as defined by the credential format, for example the vct for SD-JWT-VC or the doctype for mdoc; format, identifying the credential format as defined by OID4VCI; iat and exp, defining the issuance time and expiry time of the metadata JWT; credential_metadata_uri, identifying the exact authoritative URI from which the JWT was served and from which the Wallet Unit shall later renew the metadata to avoid any ambiguity; and credential_metadata, containing the signed display and transaction metadata itself.
With these additions, the presentation proof includes metadata_integrity, i.e. the integrity hash of the signed credential metadata JWT actually used for rendering. This allows the Relying Party to later prove which metadata was shown to the user when combined with a wallet integrity proof through the attestation provider.
This also allows credential metadata to evolve independently, for example to update supported transaction data types, without bloating issuer metadata or reissuing the credential.
I therefore propose adding a similar extension to OID4VCI itself, to ensure cross-ecosystem compatibility. Standardising credential_metadata_uri and signed credential metadata at the base protocol level would avoid profile-specific divergence and provide a common interoperable way to protect consent-relevant metadata.
(Created as requested in #721 (comment))
Some high-assurance flows, especially when dealing with DPCs, require additional security and traceability when producing presentation responses. Under [PSD2], the burden of proof for payments and SCA rests with the payment service provider. As a result, each transaction response must contain enough information to prove, or at least reconstruct, what happened.
The credential and its content are protected and can be cryptographically linked to the response; its display metadata is not. Yet credential selection in a transaction is driven by that metadata, which makes it part of the user's consent and therefore something that must also be protected.
Currently, there is no practical way to sign credential-specific display metadata directly. In practice, the only available option is to rely on signed issuer metadata, which can become disproportionately large and would bundle unrelated data into proof packages and audit logs.
For our purpose, we have extended
OID4VCIas follows:credential_metadata_uriparameter is added tocredential_configurations_supported, allowing credential-specific metadata to be retrieved separately from general issuer metadata.Wallet UnitrequestsAccept: application/jwtfrom thecredential_metadata_uri, theCredential Issuerreturns a signed JWT whose JOSE header containstyp=credential-metadata+jwtand anx5ccertificate chain that resolves to the same attestation rpovider as the credential. The payload containsiss, identifying theCredential Issuer Identifier;sub, identifying the credential type as defined by the credential format, for example thevctforSD-JWT-VCor thedoctypeformdoc;format, identifying the credential format as defined byOID4VCI;iatandexp, defining the issuance time and expiry time of the metadata JWT;credential_metadata_uri, identifying the exact authoritative URI from which the JWT was served and from which theWallet Unitshall later renew the metadata to avoid any ambiguity; andcredential_metadata, containing the signed display and transaction metadata itself.With these additions, the presentation proof includes
metadata_integrity, i.e. the integrity hash of the signed credential metadata JWT actually used for rendering. This allows theRelying Partyto later prove which metadata was shown to the user when combined with a wallet integrity proof through the attestation provider.This also allows credential metadata to evolve independently, for example to update supported transaction data types, without bloating issuer metadata or reissuing the credential.
I therefore propose adding a similar extension to OID4VCI itself, to ensure cross-ecosystem compatibility. Standardising credential_metadata_uri and signed credential metadata at the base protocol level would avoid profile-specific divergence and provide a common interoperable way to protect consent-relevant metadata.
(Created as requested in #721 (comment))