-
Notifications
You must be signed in to change notification settings - Fork 25
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 Multi RP Credentials/Authentication capability #308
base: main
Are you sure you want to change the base?
Changes from 14 commits
0833045
141e359
5c69e3e
54a1672
71268d6
43521e1
79a01ee
4c7867d
1ef2c5a
80c8ffe
b8c1449
e2fe62e
7c2ec1c
58e3ffa
ed6c840
1f50e80
f912e13
7e2b268
72a31f8
4f13bd4
c9de4d1
9dbbc4e
20964b0
a49eb50
f6dea92
e32cecf
d8bb9ff
d7a5048
339e966
1a2f830
6d93c66
9d7321c
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 |
---|---|---|
@@ -1,31 +1,10 @@ | ||
{ | ||
"client_id": "https://client.example.org", | ||
"expected_origins": [ | ||
"https://origin1.example.com", | ||
"https://origin2.example.com" | ||
], | ||
"response_type": "vp_token", | ||
"response_mode": "w3c_dc_api.jwt", | ||
"nonce": "n-0S6_WzA2Mj", | ||
"client_metadata": { | ||
"vp_formats": { | ||
"vc+sd-jwt": { | ||
"sd-jwt_alg_values": [ "PS256" ], | ||
"kb-jwt_alg_values": [ "PS256" ] | ||
} | ||
}, | ||
"jwks": { | ||
"keys": [ | ||
{ | ||
"kty": "EC", | ||
"crv": "P-256", | ||
"x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", | ||
"y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", | ||
"use": "enc", | ||
"kid": "1" | ||
} | ||
] | ||
} | ||
}, | ||
"presentation_definition": {...} | ||
"dcql_query": {...} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
{ | ||
"expected_origins": [ | ||
"https://origin1.example.com", | ||
"https://origin2.example.com" | ||
], | ||
"client_id": "x509_san_dns:rp.example.com", | ||
"client_metadata": { | ||
"jwks": { | ||
"keys": [ | ||
{ | ||
"kty": "EC", | ||
"crv": "P-256", | ||
"x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", | ||
"y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", | ||
"use": "enc", | ||
"kid": "1" | ||
} | ||
] | ||
} | ||
}, | ||
"response_type": "vp_token", | ||
"response_mode": "w3c_dc_api.jwt", | ||
"nonce": "n-0S6_WzA2Mj", | ||
"dcql_query": {...} | ||
} |
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -2025,19 +2025,86 @@ The Verifier MAY send all the OpenID4VP request parameters as members in the req | |||||||||
|
||||||||||
The Verifier MAY send a signed request, for example, when identification and authentication of the Verifier is required. | ||||||||||
|
||||||||||
The signed request allows the Wallet to authenticate the Verifier using one or more trust framework(s) in addition to the Web PKI utilized by the browser. An example of such a trust framework is the Verifier (RP) management infrastructure set up in the context of the eIDAS regulation in the European Union, in which case, the Wallet can no longer rely only on the web origin of the Verifier. This web origin MAY still be used to further strengthen the security of the flow. The external trust framework could, for example, map the Client Identifier to registered web origins. | ||||||||||
|
||||||||||
The signed Request Object MAY contain all the parameters listed in (#browser_api_request), except `request`. | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
Below is a non-normative example of such a request sent over the W3C Digital Credentials API: | ||||||||||
Verifiers can format signed Requests either using JWS Compact Serialization or JWS Serialization [@!RFC7515]). | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
#### JWS Compact Serialization | ||||||||||
|
||||||||||
In case of the JWS Compact Serialization, all request parameters are encoded in a request object as defined in (#vp_token_request) and the JWS object is used as the value of the `request` claim in the `data` element of the API call. This is illustated in the following example. | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
```js | ||||||||||
{ request: "eyJhbGciOiJF..." } | ||||||||||
``` | ||||||||||
|
||||||||||
This is an example of the payload of a signed OpenID4VP request used with the W3C Digital Credentials API: | ||||||||||
This is an example of the payload of a signed OpenID4VP request used with the W3C Digital Credentials API in conjunction with JWS Compact Serialization: | ||||||||||
|
||||||||||
<{{examples/digital_credentials_api/signed_request_payload_compact.json}} | ||||||||||
|
||||||||||
#### JWS JSON Serialization | ||||||||||
|
||||||||||
The JWS JSON Serialization [@!RFC7515]) allows the Verifier to use multiple Client Identifiers and corresponding key material and metadata to protect the same request. This serves use cases where the Verifier requests credentials belonging to different trust frameworks and, therefore, needs to authenticate in the context of those trust frameworks. | ||||||||||
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.
Suggested change
this is just a suggestion, but please provide an overview of the solution here. otherwise there is a jump between this short description and the technical details below..
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
In this case, the following request parameters MUST be present in the protected header of the respective `signature` object: | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
* `client_id` | ||||||||||
* `client_metadata` | ||||||||||
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
All other request parameters MUST be present in the `payload` element of the JWS object. | ||||||||||
|
||||||||||
Below is a non-normative example of such a request: | ||||||||||
|
||||||||||
```js | ||||||||||
{ | ||||||||||
"payload": "eyAiaXNzIjogImh0dHBzOi8...NzY4Mzc4MzYiIF0gfQ", | ||||||||||
"signatures": [ | ||||||||||
{ | ||||||||||
"protected": "eyJhbGciOiAiRVMyNT..MiLCJraWQiOiAiMSJ9XX19fQ", | ||||||||||
"signature": "PFwem0Ajp2Sag...T2z784h8TQqgTR9tXcif0jw" | ||||||||||
}, | ||||||||||
{ | ||||||||||
"protected": "eyJhbGciOiAiRVMyNTY...tpZCI6ICIxIn1dfX19", | ||||||||||
"signature": "irgtXbJGwE2wN4Lc...2TvUodsE0vaC-NXpB9G39cMXZ9A" | ||||||||||
} | ||||||||||
] | ||||||||||
} | ||||||||||
``` | ||||||||||
|
||||||||||
<{{examples/digital_credentials_api/signed_request_payload.json}} | ||||||||||
Every `signature` object in the structure contains the parameters and signature specific to a particular Client Identifier. The signature is calculated as specified in section 5.1 of [@!RFC7515]. | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
The signed request allows the Wallet to authenticate the Verifier using a trust framework other than the Web PKI utilized by the browser. An example of such a trust framework is the Verifier (RP) management infrastructure set up in the context of the eIDAS regulation in the European Union, in which case, the Wallet can no longer rely only on the web origin of the Verifier. This web origin MAY still be used to further strengthen the security of the flow. The external trust framework could, for example, map the Client Identifier to registered web origins. | ||||||||||
This is an example of a protected header: | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
``` | ||||||||||
{ | ||||||||||
"alg": "ES256", | ||||||||||
"kid": "k2bdc", | ||||||||||
"x5c": [ | ||||||||||
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. why would you have a kid (with my initials no less) alongside x5c? 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. removed it |
||||||||||
"MIICOjCCAeG...djzH7lA==", | ||||||||||
"MIICLTCCAdS...koAmhWVKe" | ||||||||||
], | ||||||||||
"client_id": "x509_san_dns:rp.example.com", | ||||||||||
"client_metadata": { | ||||||||||
"jwks": { | ||||||||||
"keys": [ | ||||||||||
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 know there's other related commentary so please excuse any redundancy but it seems pretty awkward to have what are probably ephemeral encryption keys in each of the headers. 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. Would you prefer to have one key in the request body? that would certainly also solve the apv/apu challenge. However, as far as I remember, there was also the desire to have authenticated keys. I would assume those would be provided with a cert chain related to the trust framework related to a certain Client Identifier. 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 would assume in that case to the best of how I understand things, those keys would be authenticated by the signature over them and trust in the key that applied that signature is established by that cert chain related to the trust framework related to a certain Client Identifier. I don't think that's how some of those that have expressed the desire to have authenticated keys think it should or will work. But it's how I imagine it'd be done with the fewest breaking or impractical changes down the stack of things OpenID4VP builds on. |
||||||||||
{ | ||||||||||
"kty": "EC", | ||||||||||
"crv": "P-256", | ||||||||||
"x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4", | ||||||||||
"y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM", | ||||||||||
"use": "enc", | ||||||||||
"kid": "1" | ||||||||||
} | ||||||||||
] | ||||||||||
} | ||||||||||
} | ||||||||||
} | ||||||||||
``` | ||||||||||
|
||||||||||
This is an example of the payload of a signed OpenID4VP request used with the W3C Digital Credentials API in conjunction with JWS JSON Serialization: | ||||||||||
tlodderstedt marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||
|
||||||||||
<{{examples/digital_credentials_api/signed_request_payload.json}} | ||||||||||
|
||||||||||
## Response | ||||||||||
|
||||||||||
|
@@ -2642,6 +2709,22 @@ established by [@!RFC7515]. | |||||||||
* Change Controller: OpenID Foundation Artifact Binding Working Group - [email protected] | ||||||||||
* Specification Document(s): (#verifier_attestation_jwt) of this specification | ||||||||||
|
||||||||||
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 am not a DE on the JSON Web Signature and Encryption Header Parameters Registry so I can only speculate but if I were, I'd likely have questions... 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. like? ... 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. Well, the first question that would come to my mind is, "what the fuck is this?" but think about it from the perspective that this will maybe eventually be put forward through various bureaucratic entities to be considered as a registered JWS header. JOSE is a general purpose thing that is many layers removed from this document and the DE's might not know or care about OpenID4VP or any of this stuff. What is 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 added a suggestion to enhance the description (below). I honestly don't know what to say more about it. I hope this works for you. |
||||||||||
### client_id | ||||||||||
|
||||||||||
* Header Parameter Name: `client_id` | ||||||||||
* Header Parameter Description: This header contains a Client Identifier. | ||||||||||
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.
Suggested change
|
||||||||||
* Header Parameter Usage Location: JWS | ||||||||||
* Change Controller: IETF | ||||||||||
* Specification Document(s): [@!RFC6749] | ||||||||||
|
||||||||||
### client_metadata | ||||||||||
|
||||||||||
* Header Parameter Name: `jwt` | ||||||||||
* Header Parameter Description: This header contains a JWT. Processing rules MAY depend on the `typ` header value of the respective JWT. | ||||||||||
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. need to fix copy/paste 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. fixed 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.
Suggested change
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. fixed it with the text from the parameter definition + added reference to the definition |
||||||||||
* Header Parameter Usage Location: JWS | ||||||||||
* Change Controller: OpenID Foundation Digital Credentials Working Group - [email protected] | ||||||||||
* Reference: (#vp_token_request) of this specification | ||||||||||
|
||||||||||
## Uniform Resource Identifier (URI) Schemes Registry | ||||||||||
|
||||||||||
This specification registers the following URI 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.
Why were the
client_id
,client_metadata
, andjwks
deleted? This change seems unrelated to the purpose of this PR.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.
This is indeed related to this PR, as this data elements are RP specific. Consequently, the PR moves them into the RP credential specific elements of the request.
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.
We should discuss where the
client_id
,client_metadata
, andjwks
claims should go when using the Compact Serialization. These would normally be claims - not header parameters.I understand the reasoning for making them header parameters when using the JSON Serialization, but in my view, that's not the normal case, and we should make the normal case natural.
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.
client_id
,client_metadata
, andjwks
are request parameters when using the Compact Serialization. see examples/digital_credentials_api/signed_request_payload_compact.json