Skip to content
Merged
Changes from all commits
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
532fe5d
add option to have signed Credential Issuer metadata, remove `signed_…
paulbastian May 27, 2025
80646b2
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 4, 2025
bb071cb
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 4, 2025
9897fcb
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 4, 2025
942d711
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 4, 2025
c755f20
Merge branch 'main' into signed_metadata_rework
paulbastian Jun 18, 2025
4ef8680
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 18, 2025
abc848d
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 19, 2025
34b84f4
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 20, 2025
a9ad056
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 22, 2025
9ec4b7f
Merge branch 'main' into signed_metadata_rework
c2bo Jun 23, 2025
da367ad
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 23, 2025
6298321
IANA application/openidvci-issuer-metadata+jwt
paulbastian Jun 24, 2025
351c6ac
Apply suggestions from code review
paulbastian Jun 24, 2025
4e67a14
Update openid-4-verifiable-credential-issuance-1_0.md
paulbastian Jun 24, 2025
7c8b199
Apply suggestions from code review based on the WG discussion
Sakurann Jun 24, 2025
a1efc2a
Apply suggestions from code review based on bikeshedding during the w…
Sakurann Jun 24, 2025
60a33f0
Apply Christian & dastoikov's suggestions
jogu Jun 26, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 49 additions & 3 deletions openid-4-verifiable-credential-issuance-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -1256,9 +1256,16 @@ For example, the metadata for the Credential Issuer Identifier `https://issuer.e

Communication with the Credential Issuer Metadata Endpoint MUST utilize TLS.

To fetch the Credential Issuer Metadata, the requester MUST send an HTTP request using the GET method and the path formed following the steps above. The Credential Issuer MUST return a JSON document compliant with this specification using the `application/json` media type and the HTTP Status Code 200.
To fetch the Credential Issuer Metadata, the Wallet MUST send an HTTP request using the GET method and the path formed following the steps above. The Wallet is RECOMMENDED to send an `Accept` header in the HTTP GET request to indicate the Content Type(s) it supports, and by doing so, signaling whether it supports signed metadata.

The Wallet is RECOMMENDED to send an `Accept-Language` Header in the HTTP GET request to indicate the language(s) preferred for display. It is up to the Credential Issuer whether to:
The Credential Issuer MUST respond with HTTP Status Code 200 and return the Credential Issuer Metadata containing the parameters defined in (#credential-issuer-parameters) as either

* an unsigned JSON document using the media type `application/json`, or
* a signed JSON Web Token (JWT) containing the Credential Issuer Metadata in its payload using the media type `application/jwt`.

The Credential Issuer MUST support returning metadata in an unsigned form 'application/json' and MAY support returning it in a signed form 'application/jwt'. In all cases the Credential Issuer MUST indicate the media type of the returned Metadata using the HTTP `Content-Type` header. It is RECOMMENDED for Credential Issuers to respond with a `Content-Type` matching to the Wallet's requested `Accept` header when the requested content type is supported.

The Wallet is RECOMMENDED to send an `Accept-Language` header in the HTTP GET request to indicate the language(s) preferred for display. It is up to the Credential Issuer whether to:

* send a subset the metadata containing internationalized display data for one or all of the requested languages and indicate returned languages using the HTTP `Content-Language` Header, or
* ignore the `Accept-Language` Header and send all supported languages or any chosen subset.
Expand All @@ -1273,6 +1280,22 @@ Host: server.example.com
Accept-Language: fr-ch, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

### Signed Metadata {#credential-issuer-signed-metadata}

The signed metadata MUST be secured using a JSON Web Signature (JWS) [@!RFC7515] and contain the following elements:

* in the JOSE header,
* `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry [@IANA.JOSE]. It MUST NOT be `none` or an identifier for a symmetric algorithm (MAC).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: is there a way for a client requesting signed metadata to check if the server’s supported signing algorithms would match the former’s capabilities, and potentially negotiate preferences?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we wanted to keep it simple to start with (that's how the oauth signed metadata and federation work too I believe) - it is possible that we could define a future mechanism using a header or where the issuer returns a json serialised response with multiple signatures.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @jogu!

* `typ`: REQUIRED. MUST be `openidvci-issuer-metadata+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725].

* in the JWT body,
* `iss`: OPTIONAL. String denoting the party attesting to the claims in the signed metadata
* `sub`: REQUIRED. String matching the Credential Issuer Identifier
* `iat`: REQUIRED. Integer for the time at which the Credential Issuer Metadata was issued using the syntax defined in [@!RFC7519].
* `exp`: OPTIONAL. Integer for the time at which the Credential Issuer Metadata is expiring, using the syntax defined in [@!RFC7519].

When requesting signed metadata, the Wallet MUST establish trust in the signer of the metadata. Otherwise, the Wallet MUST reject the signed metadata. When validating the signature, the Wallet obtains the keys to validate the signature before processing the metadata, e.g. using JOSE header parameters like `x5c`, `kid` or `trust_chain` to convey the public key. The concrete mechanisms how to do that are out of scope of this specification.

### Credential Issuer Metadata Parameters {#credential-issuer-parameters}

This specification defines the following Credential Issuer Metadata parameters:
Expand All @@ -1295,7 +1318,6 @@ This specification defines the following Credential Issuer Metadata parameters:
* `encryption_required`: REQUIRED. Boolean value specifying whether the Credential Issuer requires the additional encryption on top of TLS for the Credential Response. If the value is `true`, the Credential Issuer requires encryption for every Credential Response and therefore the Wallet MUST provide encryption keys in the Credential Request. If the value is `false`, the Wallet MAY choose whether it provides encryption keys or not.
* `batch_credential_issuance`: OPTIONAL. Object containing information about the Credential Issuer's support for issuance of multiple Credentials in a batch in the Credential Endpoint. The presence of this parameter means that the issuer supports more than one key proof in the `proofs` parameter in the Credential Request so can issue more than one Verifiable Credential for the same Credential Dataset in a single request/response.
* `batch_size`: REQUIRED. Integer value specifying the maximum array size for the `proofs` parameter in a Credential Request. It MUST be 2 or greater.
* `signed_metadata`: OPTIONAL. String that is a signed JWT. This JWT contains Credential Issuer metadata parameters as claims. The signed metadata MUST be secured using JSON Web Signature (JWS) [@!RFC7515] and MUST contain an `iat` (Issued At) claim, an `iss` (Issuer) claim denoting the party attesting to the claims in the signed metadata, and `sub` (Subject) claim matching the Credential Issuer identifier. If the Wallet supports signed metadata, metadata values conveyed in the signed JWT MUST take precedence over the corresponding values conveyed using plain JSON elements. If the Credential Issuer wants to enforce use of signed metadata, it omits the respective metadata parameters from the unsigned part of the Credential Issuer metadata. A `signed_metadata` metadata value MUST NOT appear as a claim in the JWT. The Wallet MUST establish trust in the signer of the metadata, and obtain the keys to validate the signature before processing the metadata. The concrete mechanism how to do that is out of scope of this specification and MAY be defined in the profiles of this specification.
* `display`: OPTIONAL. A non-empty array of objects, where each object contains display properties of a Credential Issuer for a certain language. Below is a non-exhaustive list of valid parameters that MAY be included:
* `name`: OPTIONAL. String value of a display name for the Credential Issuer.
* `locale`: OPTIONAL. String value that identifies the language of this object represented as a language tag taken from values defined in BCP47 [@!RFC5646]. There MUST be only one object for each language identifier.
Expand Down Expand Up @@ -2780,6 +2802,28 @@ in the manner described in [@RFC6838].
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - [email protected]
* Provisional registration? No

### application/openidvci-issuer-metadata+jwt

* Type name: `application`
* Subtype name: `openidvci-issuer-metadata+jwt`
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: Uses JWS Compact Serialization, as specified in [@!RFC7515].
* Security considerations: See the Security Considerations in [@!RFC7519].
* Interoperability considerations: n/a
* Published specification: (#credential-issuer-signed-metadata) of this specification
* Applications that use this media type: Applications that use signed metadata format defined in this specification
* Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information: Torsten Lodderstedt, [email protected]
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Torsten Lodderstedt, [email protected]
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - [email protected]
* Provisional registration? No

## Uniform Resource Identifier (URI) Schemes Registry

This specification registers the following URI scheme
Expand Down Expand Up @@ -2848,6 +2892,8 @@ The technology described in this specification was made available from contribut

-16

* Add option to have signed Credential Issuer metadata
* Remove `signed_metadata` from Credential Issuer metadata
* move proof type section to the Annex for readability, add some introduction and fix text in Section 8.1
* move `claims` and `display` into `credential_metadata` and allow for credential-format specific mechanisms to override it
* Remove the option to use `format` from `authorization_details` in the Authorization Request
Expand Down