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.

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

Open
wants to merge 32 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 14 commits
Commits
Show all changes
32 commits
Select commit Hold shift + click to select a range
0833045
first sketch
tlodderstedt Nov 5, 2024
141e359
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Nov 14, 2024
5c69e3e
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Nov 14, 2024
54a1672
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Nov 14, 2024
71268d6
fixed typo
tlodderstedt Nov 14, 2024
43521e1
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Nov 26, 2024
79a01ee
recovered JWS Compact Serialization
tlodderstedt Dec 6, 2024
4c7867d
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
1ef2c5a
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
80c8ffe
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
b8c1449
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
e2fe62e
added IANA registration of JOSE header parameters
tlodderstedt Jan 10, 2025
7c2ec1c
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
58e3ffa
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 10, 2025
ed6c840
Merge branch 'main' into multiple-rp-credentials
Sakurann Jan 14, 2025
1f50e80
fixed copy and paste
tlodderstedt Jan 14, 2025
f912e13
Merge branch 'multiple-rp-credentials' of https://github.com/openid/O…
tlodderstedt Jan 14, 2025
7e2b268
removed kid in example
tlodderstedt Jan 14, 2025
72a31f8
added entry to document history
tlodderstedt Jan 14, 2025
4f13bd4
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 14, 2025
c9de4d1
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 14, 2025
9dbbc4e
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 14, 2025
20964b0
Merge branch 'multiple-rp-credentials' of https://github.com/openid/O…
tlodderstedt Jan 14, 2025
a49eb50
moved client_metadata back into request
tlodderstedt Jan 14, 2025
f6dea92
removed client_metadata JOSE header registration
tlodderstedt Jan 14, 2025
e32cecf
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 23, 2025
d8bb9ff
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 23, 2025
d7a5048
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 23, 2025
339e966
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 23, 2025
1a2f830
Update openid-4-verifiable-presentations-1_0.md
tlodderstedt Jan 23, 2025
6d93c66
modified example to match change re enc key
tlodderstedt Jan 27, 2025
9d7321c
Merge branch 'multiple-rp-credentials' of https://github.com/openid/O…
tlodderstedt Jan 27, 2025
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
23 changes: 1 addition & 22 deletions examples/digital_credentials_api/signed_request_payload.json
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": {...}
Copy link
Member

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, and jwks deleted? This change seems unrelated to the purpose of this PR.

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 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.

Copy link
Member

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, and jwks 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

client_id, client_metadata, and jwks are request parameters when using the Compact Serialization. see examples/digital_credentials_api/signed_request_payload_compact.json

}
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": {...}
}
91 changes: 87 additions & 4 deletions openid-4-verifiable-presentations-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
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.
Using JWS JSON Serialization [@!RFC7515]) to send the Request 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.
This is achieved by passing multiple signatures of the same paylod in the protected header.

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": [
Copy link
Member

@bc-pi bc-pi Jan 13, 2025

Choose a reason for hiding this comment

The 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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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": [
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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.

Copy link
Member

@bc-pi bc-pi Jan 15, 2025

Choose a reason for hiding this comment

The 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

Expand Down Expand Up @@ -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

Copy link
Member

Choose a reason for hiding this comment

The 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...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

like? ...

Copy link
Member

@bc-pi bc-pi Jan 15, 2025

Choose a reason for hiding this comment

The 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 client_id and what does it do and why does it need or deserve to be general reserved JOSE header? This header contains a Client Identifier. and a pointer to RFC6749 are not, in my narrow view as the DE for a different registry, helpful at all.

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 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.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Suggested change
* Header Parameter Description: This header contains a Client Identifier.
* Header Parameter Description: This header contains a Client Identifier. A Client Identifier is used in OAuth to identify a certain client. It is defined in [@!RFC6749], section 2.2.

* 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.
Copy link
Member

Choose a reason for hiding this comment

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

need to fix copy/paste

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

fixed

Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* 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.
* Header Parameter Name: `client_metadata`
* Header Parameter Description: This header contains Client Metadata.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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
Expand Down