add option to have signed Credential Issuer metadata, remove signed_metadata from Credential Issuer metadata
#520
Conversation
…metadata` from Credential Issuer metadata
To give a bit more context on this: Paul and I had a bit of a discussion if we need to support multiple signatures similar to what was introduced in OpenID4VP. We came to the conclusion that starting with a JWT seems to be the more pragmatic choice and if we realise we need to support that feature, we could probably introduce it rather simple with a new media type (jose+json based). Using JWT and different Issuer deployments for different trust ecosystems seems reasonable to me. |
| 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: |
There was a problem hiding this comment.
For interoperability, what are we normatively implying implementations must support, it would appear we are imply that all credential issuer implementations MUST support signed metadata or are we saying that only plain JSON MUST be supported and the client/wallet gets to decide what it wants to support?
There was a problem hiding this comment.
The either to me implies that the issuer can choose. In the next section, it says the issuer may ignite the accept header and send whatever he likes, so to me it seems signed metadata is optional. That means wallets must support both.
There was a problem hiding this comment.
Im not sure I support making signed metadata required for wallet/client implementations I'd prefer we only require them to support unsigned which is consistent with the equivalent feature in OAuth and OpenID connect.
There was a problem hiding this comment.
wg discussion.
- no normative requirement for the wallet to support this.
- HAIP can mandate it.
Co-authored-by: Tobias Looker <[email protected]>
Co-authored-by: Christian Bormann <[email protected]>
Co-authored-by: Tobias Looker <[email protected]>
Co-authored-by: Christian Bormann <[email protected]>
| @@ -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` Header in the HTTP GET request to indicate whether it supports signed metadata. | |||
There was a problem hiding this comment.
| 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 whether it supports signed metadata. | |
| 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. |
There was a problem hiding this comment.
| 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 whether it supports signed metadata. | |
| 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, signal whether it supports signed metadata. |
@sloops77 I let myself improve it further. Saying straight that the mime type is used only determine wallet support for metadata is not ideal, but there's a value in keeping it explicit too.
| * 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` | ||
|
|
||
| The Credential Issuer MAY ignore the `Accept` Header. It MUST indicate the type of the returned Credential Issuer Metadata using the HTTP `Content-Type`. |
There was a problem hiding this comment.
| The Credential Issuer MAY ignore the `Accept` Header. It MUST indicate the type of the returned Credential Issuer Metadata using the HTTP `Content-Type`. | |
| The Credential Issuer MAY ignore the `Accept` Header. If the Credential Issuer receives a request with an `Accept` header set to both media types then it SHOULD respond with a signed metadata format if possible (ie. `applicaiton/jwt`). It MUST indicate the type of the returned Credential Issuer Metadata using the HTTP `Content-Type`. |
Closes #202