-
Notifications
You must be signed in to change notification settings - Fork 26
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
add small note about client id parameters for dc api #458
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Timo Glastra <[email protected]>
Some notes I also shared with @peppelinux over email:
|
The list of parameters that can be used in the DC API defined in section A.2 is explicitly prefixed with:
I'm not actually sure how to interpret that text, given that The intent of all this text was to make sure that not all the request parameters from https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters automatically became allowable to use in the DC API. For example, So likely your proposed text makes sense as I can't currently think of a case where a client id scheme might define a parameter that doesn't make sense in the DC API. |
@@ -2181,7 +2181,7 @@ In addition to the above-mentioned parameters, a new parameter is introduced for | |||
|
|||
* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). An array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet can detect replay of the request from a malicious Verifier by comparing values in this parameter to the Origin. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. | |||
|
|||
Additional request parameters MAY be defined and used with OpenID4VP over the DC API. | |||
Additional request parameters MAY be defined and used with OpenID4VP over the DC API, including parameters defined by a specific client identifier scheme (such as the `trust_chain` parameter for the `https` client id scheme). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it actually makes sense to add this note further up - either before line 2176 or before 2180? And word it more like:
Parameters defined by a specific client identifier scheme (such as the
trust_chain
parameter for the OpenID Federation client id scheme) are also supported over the W3C Digital Credentials API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 2176 would be good, directly after the list of parameters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to move the whole sentence up
@@ -2181,7 +2181,7 @@ In addition to the above-mentioned parameters, a new parameter is introduced for | |||
|
|||
* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). An array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet can detect replay of the request from a malicious Verifier by comparing values in this parameter to the Origin. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. | |||
|
|||
Additional request parameters MAY be defined and used with OpenID4VP over the DC API. | |||
Additional request parameters MAY be defined and used with OpenID4VP over the DC API, including parameters defined by a specific client identifier scheme (such as the `trust_chain` parameter for the `https` client id scheme). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 2176 would be good, directly after the list of parameters
Okay thanks for the feedback, i will update the PR |
Fixes #436