Signed Credential Metadata

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 https://github.com/openid/OpenID4VCI/pull/721#issuecomment-4294696408)

Start by reviewing the proposed extension in the issue and the linked pull request, https://github.com/openid/OpenID4VCI/pull/721, including the referenced discussion. Determine the repository's specification entry points and existing metadata definitions before deciding how credential_metadata_uri, signed metadata, and metadata_integrity should be incorporated; done requires an agreed interoperable protocol design.