Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Clarify what can go in client_metadata authz request parameter #233

Merged
merged 8 commits into from
Sep 27, 2024
Merged

Clarify what can go in client_metadata authz request parameter #233

Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
31f5699
Clarify what can go in client_metadata authz request parameter
jogu Aug 25, 2024
c4a7c30
Attempt to address Martijn's feedback
jogu Aug 28, 2024
24bcd57
Apply various review comments
jogu Sep 10, 2024
97df212
Removed no longer used reference to OID DCR.
jogu Sep 10, 2024
02129e6
Merge branch 'main' into clarify-client_metadata-parameter
jogu Sep 23, 2024
555f05c
Apply changes from code review
jogu Sep 23, 2024
6f19375
Apply Paul's suggestion
jogu Sep 23, 2024
91d1704
Update text around jwks to try to address Oliver's concern
jogu Sep 27, 2024
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
33 changes: 13 additions & 20 deletions openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -245,7 +245,7 @@ The Verifier articulates requirements of the Credential(s) that are requested us

The Verifier communicates a Client Identifier Scheme that indicate how the Wallet is supposed to interpret the Client Identifier and associated data in the process of Client identification, authentication, and authorization using `client_id_scheme` parameter. This parameter enables deployments of this specification to use different mechanisms to obtain and validate Client metadata beyond the scope of [@!RFC6749]. A certain Client Identifier Scheme MAY require the Verifier to sign the Authorization Request as means of authentication and/or pass additional parameters and require the Wallet to process them.

Depending on the Client Identifier Scheme, the Verifier can communicate a JSON object with its metadata using the `client_metadata` parameter which contains name/value pairs defined in Section 4.3 and Section 2.1 of the OpenID Connect Dynamic Client Registration 1.0 [@!OpenID.Registration] specification as well as [@!RFC7591].
Depending on the Client Identifier Scheme, the Verifier can communicate a JSON object with its metadata using the `client_metadata` parameter which contains name/value pairs.

This specification enables the Verifier to send both Presentation Definition JSON object and Client Metadata JSON object by value or by reference.

Expand All @@ -261,9 +261,17 @@ This specification defines the following new request parameters:
: OPTIONAL. A string identifying the scheme of the value in the `client_id` Authorization Request parameter (Client Identifier scheme). The `client_id_scheme` parameter namespaces the respective Client Identifier. If an Authorization Request uses the `client_id_scheme` parameter, the Wallet MUST interpret the Client Identifier of the Verifier in the context of the Client Identifier scheme. If the parameter is not present, the Wallet MUST behave as specified in [@!RFC6749]. See (#client_metadata_management) for the values defined by this specification. If the same Client Identifier is used with different Client Identifier schemes, those occurrences MUST be treated as different Verifiers. Note that the Verifier needs to determine which Client Identifier schemes the Wallet supports prior to sending the Authorization Request in order to choose a supported scheme.

`client_metadata`:
: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded.
: OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used:

A public key to be used by the Wallet as an input to the key agreement to encrypt Authorization Response (see (#jarm)). It MAY be passed by the Verifier using the `jwks` or the `jwks_uri` claim within the `client_metadata` request parameter.
* `jwks`: OPTIONAL. A JWKS as defined in [@!RFC7591]. It MAY contain one or more public keys, such as keys used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#jarm)), or keys for signature algorithms that require a public key of the Verifier. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests.
jogu marked this conversation as resolved.
Show resolved Hide resolved
* `vp_formats`: REQUIRED when not available to the Wallet via another mechanism. As defined in (#client_metadata_parameters).
* `authorization_signed_response_alg`: OPTIONAL. As defined in [@!JARM].
* `authorization_encrypted_response_alg`: OPTIONAL. As defined in [@!JARM].
* `authorization_encrypted_response_enc`: OPTIONAL. As defined in [@!JARM].

Authoritative data the Wallet is able to obtain about the Client from other sources, for example those from an OpenID Federation Entity Statement, take precedence over the values passed in `client_metadata`.

Other metadata parameters MUST be ignored unless a profile of this specification explicitly defines them as usable in the `client_metadata` parameter.

`request_uri_method`:
: OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the Request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present.
Expand Down Expand Up @@ -744,7 +752,7 @@ The JWT response document MUST include `vp_token` and `presentation_submission`

The key material used for encryption and signing SHOULD be determined using existing metadata mechanisms.

To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` or `jwks_uri` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms.
To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms.
Copy link
Member

@peppelinux peppelinux Sep 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Suggested change
To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms.
To encrypt the Authorization Response, the Wallet uses the 'jwks` parameter within the `client_metadata` request parameter. This is REQUIRED if no other methods are available to retrieve the Verifier's metadata, such as through the trust chain described in [@!OpenID.Federation].

Generally metadata in Federation are only final metadata derived from the trust chain.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This reads like encryption is mandatory, but we've not agreed that as a WG. Also I don't think 'securely encrypt' should be used, it's just encryption. As this is existing text (I only removed 'jwks_uri' from this sentence) I think we should handle changing this in a separate issue.

Copy link
Collaborator

Choose a reason for hiding this comment

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

how about paraphrasing like this?

Suggested change
To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` claim within the `client_metadata` request parameter, or within the metadata defined in the Entity Configuration when [@!OpenID.Federation] is used, or other mechanisms.
To obtain Verifier's public key for the input to the key agreement to encrypt the Authorization Response, the Wallet MUST use `jwks` claim within the `client_metadata` request parameter, if no other mechanisms such as the metadata defined in the Entity Configuration in [@!OpenID.Federation] are used.

Copy link
Collaborator Author

@jogu jogu Sep 11, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

@Sakurann I'm not sure how to read this. Does it mean "if the verifier has a jwks in its federation metadata it can't use ephemeral encryption keys"? If so I think that would be a normative change that I'm not sure I'm comfortable making in this PR.

Copy link
Member

Choose a reason for hiding this comment

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

Applied @jogu 's suggestion here: https://github.com/openid/OpenID4VP/pull/233/files#r1752230536

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm somewhat confused as to what the latest suggestion here is, but I think if people think updates are needed to the text around how keys from Federation overlap with keys from client_metadata parameter then we should handle that in a separate issue please as that's outside of the scope of this PR and hasn't been discussed in the working group yet. This PR does not make anything worse in that area.


To sign the Authorization Response, the Wallet MUST use a private key that corresponds to a public key made available in its metadata.

Expand Down Expand Up @@ -1381,22 +1389,6 @@ issuers in Self-Sovereign Identity ecosystems using TRAIN</title>
</front>
</reference>

<reference anchor="OpenID.Registration" target="https://openid.net/specs/openid-connect-registration-1_0.html">
<front>
<title>OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1</title>
<author fullname="Nat Sakimura">
<organization>NRI</organization>
</author>
<author fullname="John Bradley">
<organization>Ping Identity</organization>
</author>
<author fullname="Michael B. Jones">
<organization>Microsoft</organization>
</author>
<date day="8" month="Nov" year="2014"/>
</front>
</reference>

<reference anchor="Hyperledger.Indy" target="https://www.hyperledger.org/use/hyperledger-indy">
<front>
<title>Hyperledger Indy Project</title>
Expand Down Expand Up @@ -2082,6 +2074,7 @@ The technology described in this specification was made available from contribut

-22

* Clarified what can go in the `client_metadata` parameter
* Fixed #227: Enabled non-breaking extensibility.

-21
Expand Down