-
Notifications
You must be signed in to change notification settings - Fork 36
add option to have signed Credential Issuer metadata, remove signed_metadata from Credential Issuer metadata
#520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
532fe5d
80646b2
bb071cb
9897fcb
942d711
c755f20
4ef8680
abc848d
34b84f4
a9ad056
9ec4b7f
da367ad
6298321
351c6ac
4e67a14
7c8b199
a1efc2a
60a33f0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1395,7 +1395,14 @@ Credential Issuers publishing metadata MUST make a JSON document available at th | |
|
|
||
| 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-Content` Header in the HTTP GET request to indicate whether it supports signed metadata. | ||
|
|
||
| The Credential Issuer MUST respond with HTTP Status Code 200 and return the Credential Issuer Metadata containing the [parameters defined in this specification](#credential-issuer-parameters) as either: | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| * an unsigned JSON document using the media type `application/json` | ||
| * a signed JSON Web Token (JWT) containing the Credential Issuer Metadata in its payload using the media type `application/jwt` | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The Credential Issuer MAY ignore the `Accept-Content` Header. It MUST indicate the type of the returned Credential Issuer Metadata using the HTTP `Content-Type`. | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| 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: | ||
jogu marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
|
|
@@ -1412,6 +1419,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 | ||
|
|
||
| The signed metadata MUST be secured using JSON Web Signature (JWS) [@!RFC7515] and MUST contain the following elements: | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| * 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). | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you, @jogu! |
||
| * `typ`: REQUIRED. MUST be `key-attestation+jwt`, which explicitly types the key proof JWT as recommended in Section 3.11 of [@!RFC8725]. | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| * 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 | ||
jogu marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| * `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]. | ||
|
|
||
| The Wallet SHOULD establish trust in the signer of the metadata, and obtain the keys to validate the signature before processing the metadata, e.g. using JOSE headers like `x5c`, `kid` or `trust_chain` to convey the public key. The concrete mechanism how to do that is out of scope of this specification. | ||
paulbastian marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| ### Credential Issuer Metadata Parameters {#credential-issuer-parameters} | ||
|
|
||
| This specification defines the following Credential Issuer Metadata parameters: | ||
|
|
@@ -1428,7 +1451,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 supports for batch issuance of Credentials on 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. | ||
| * `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. | ||
|
|
@@ -2750,6 +2772,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 | ||
| * Adds an option to return DPoP Nonce from the Nonce Endpoint | ||
| * Change Cryptographic Holder Binding to Cryptographic Key Binding | ||
| * add privacy considerations for the client_id used with wallet attestations | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.