Add Multi RP Credentials/Authentication capability #308

tlodderstedt · 2024-11-05T21:07:09Z

This PR changes the way requests are signed to the Digital Credentials API from compact serialization (single RP) to JWS JSON Serialization (Multiple RPs).
Questions to the WG:

Do you want to keep (re-add) the JWS Compact Serialization to the Digital Credentials API profile?
Do we want the Multi RP capability to the traditional OID4VP flow?

resolves #248

openid-4-verifiable-presentations-1_0.md

selfissued

The JWS Compact Serialization is supported by essentially all implementations, whereas many don't support the JSON Serialization, in part, because JWTs don't use it.

I believe switching to the JSON Serialization would present an unnecessary burden to developers and harm interoperability.

(For what it's worth, I believe that adding the JSON Serialization a dozen or so years ago at all was a mistake, but I realize that that's water under the bridge.)

David-Chadwick · 2024-11-12T22:59:26Z

As I pointed out in the issue that this PR purports to resolve: when there is a trust infrastructure in place the request does not need to be signed as the wallet can determine the authenticity of the RP using the trust infrastructure. So we do not need multiple signatures and JSON serialisation.

Sakurann · 2024-11-14T16:02:57Z

@David-Chadwick well... the wallet determines the authenticity of the RP using the trust infrastructure based on the keys used to sign the request, that's why signature is crucial here.

Co-authored-by: Stefan Charsley <[email protected]>

Co-authored-by: Christian Bormann <[email protected]>

tlodderstedt · 2024-11-14T16:54:14Z

As I pointed out in the issue that this PR purports to resolve: when there is a trust infrastructure in place the request does not need to be signed as the wallet can determine the authenticity of the RP using the trust infrastructure. So we do not need multiple signatures and JSON serialisation.

The profile supports unsigned requests. Would that be appropriate for your use cases?

openid-4-verifiable-presentations-1_0.md

David-Chadwick · 2024-11-14T21:21:11Z

@Sakurann What you say is only one way of evaluating trust. The trust infrastructure can equally well decide if the RP is trustworthy or not based on its asserted name or ID. No keys are needed for this. If the asserted name/ID is deemed to be untrustworthy by the trust infrastructure, then the wallet knows not to trust the RP. If the name/ID is deemed to be trustworthy then there are two cases. 1. The RP is giving its true name, or 2. the RP is masquerading as a trustworthy RP. The latter can be protected against by the trust infrastructure providing the return URI of the RP for the wallet's response, and then the masquerading RP will not glean any information from the wallet. This is what we implemented. To prevent a DOS attack on the real trustworthy RP, we could add an extra protection feature, namely, the RP provides a random number on its request, which forms the query parameter on the wallet's reply to the return URI. The RP checks this parameter and if it is not recognised throws the wallet's response away.

David-Chadwick · 2024-11-14T21:24:43Z

@tlodderstedt Yes, not requiring the RP's request to be signed solves the use case, and it also solves the problem of requiring multiple signatures to be on the request, because no signatures are actually needed. The RP can provide a set of names/IDs, one for each trust infrastructure that it is a member of. Then the wallet can match the presented trust infrastructures to the ones it is a member of, and where there is an intersection find out if the RP is trustworthy or not.

tlodderstedt · 2024-11-15T07:28:29Z

The JWS Compact Serialization is supported by essentially all implementations, whereas many don't support the JSON Serialization, in part, because JWTs don't use it.

I believe switching to the JSON Serialization would present an unnecessary burden to developers and harm interoperability.

(For what it's worth, I believe that adding the JSON Serialization a dozen or so years ago at all was a mistake, but I realize that that's water under the bridge.)

@selfissued The requirement we are asked to fulfill is to allow for multiple RP credentials being proven (through signatures) in a single request. We have extensively discussed this requirement in the hybrid workshop and agreed to support it. The design in the PR is, in my opinion, the simplest and most robust solution we can do it (alternative proposals involved canonicalization). So from my standpoint, what we can do is to also continue to support compact serialization. That's why I asked that question further up.

Co-authored-by: Kristina <[email protected]>

selfissued · 2024-12-03T19:00:18Z

examples/digital_credentials_api/signed_request_payload.json

-    }
-  },
-  "presentation_definition": {...}
+  "dcql_query": {...}


Why were the client_id, client_metadata, and jwks deleted? This change seems unrelated to the purpose of this PR.

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.

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.

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

openid-4-verifiable-presentations-1_0.md

selfissued · 2024-12-03T19:11:56Z

openid-4-verifiable-presentations-1_0.md

+The following request parameters MUST be present in the protected header of the respective signature object: 
+
+* `client_id`
+* `client_metadata`


These aren't defined header parameters, so this is weird. Why aren't these being sent as claims in the request?

because they are specific to a certain RP credential

selfissued · 2024-12-03T19:13:35Z

openid-4-verifiable-presentations-1_0.md

+        "payload": "eyAiaXNzIjogImh0dHBzOi8...NzY4Mzc4MzYiIF0gfQ",
+        "signatures": [
+        {
+          "protected": "eyJhbGciOiJFUzI1NiJ9",


I would have expected a "kid" parameter - not just "alg".

not sure what you mean, see an header example (with kid and alg) below

eyJhbGciOiJFUzI1NiJ9 decodes to {"alg":"ES256"}, which has no kid.

Co-authored-by: Christian Bormann <[email protected]>

…penID4VP into multiple-rp-credentials

tlodderstedt · 2025-01-14T21:11:34Z

Discussion in the WG meeting on the 14th of Jan:

session transcript: there are two proposals on the table that were agreed to think through

@hlozi suggested to drop the Client Identifier from the session transcript (and have the origin only)
@awoie suggested to represent the relationship between a certain Client Identifier and the sub query / credential that Client Identifier is related to in the request and use that information to determine the expected Client Identifier for the corresponding Device Response object.

response encryption: conclusion was to move the client_metadata parameter into the payload (again), i.e. there is one encryption key per request. (see a49eb50)

awoie · 2025-01-14T21:40:16Z

Discussion in the WG meeting on the 14th of Jan:

session transcript: there are two proposals on the table that were agreed to think through

@awoie suggested to represent the relationship between a certain Client Identifier and the sub query / credential that Client Identifier is related to in the request and use that information to determine the expected Client Identifier for the corresponding Device Response object.

I don't think this is possible. I'm leaning towards removing the client_id from SessionTranscript but it raises the question why it is needed for other verifiable presentations in case of DC API.

paulbastian · 2025-01-14T21:46:28Z

I summarized my views in this flow chart. I came to the conclusion that client_id is not needed in session transcript. Ultimately that would mean it makes sense to have aud in KB-JWT to represent origin in DC-API case.

tlodderstedt · 2025-01-16T16:40:25Z

I don't think this is possible. I'm leaning towards removing the client_id from SessionTranscript but it raises the question why it is needed for other verifiable presentations in case of DC API.

Can you please explain why this is not possible? We can add a "credentials" array to every client identifier specific "signature" object and use that to link the Client Identifier.

tlodderstedt · 2025-01-16T16:43:00Z

I summarized my views in this flow chart. I came to the conclusion that client_id is not needed in session transcript. Ultimately that would mean it makes sense to have aud in KB-JWT to represent origin in DC-API case.

That would mean the audience restriction would differ depending on the "transport". I would assume that makes implementations (at least in transition from traditional protocol to DC) harder. It also changes the level on which the restriction needs to be checked (client id/application vs. origin/transport).

paulbastian · 2025-01-16T17:01:45Z

I summarized my views in this flow chart. I came to the conclusion that client_id is not needed in session transcript. Ultimately that would mean it makes sense to have aud in KB-JWT to represent origin in DC-API case.

That would mean the audience restriction would differ depending on the "transport". I would assume that makes implementations (at least in transition from traditional protocol to DC) harder. It also changes the level on which the restriction needs to be checked (client id/application vs. origin/transport).

That's already the reality for ISO mdoc format. I don't think it makes it much more complicated, because the input for credential formats, so mdoc and SD-JWT implementations don't need to change. The protocol implementations change anyway when people add DC-API, the change is how to build session_transcript/aud and that's what you stuff into the credential format library.

tlodderstedt · 2025-01-16T17:02:29Z

That's already the reality for ISO mdoc format.

Doesn't the device response contain the client id?

paulbastian · 2025-01-16T17:08:08Z

That's already the reality for ISO mdoc format.

Doesn't the device response contain the client id?

Not sure what you mean with device response.

client_id is present at two places in ISO18013-7

as Authorization Request parameter
in the session_transcript

The first is removed with DC-API and the second may be as well following my discussion line here in this thread.

and imo that makes sense, the client_id is kind of an origin equivalent, because OAuth couldn't achieve this without OS support.

openid-4-verifiable-presentations-1_0.md

peppelinux

I can approve this PR because it enables an important flexibility in how a wallet evaluates the trust with an RP.

I have read and I found valuable the comments of other contributors, I have decided to approve it in the current status anyway to facilitate the process.

Regarding the question: would we be able to support both compact and json serialization, I want to answer that it would be in the scope of any good library detect and support both the formats, in full support of RFC 7515. I would not use openid4vp to limit the use of the serialization types (impl profile could decide this, if/when required).

tlodderstedt · 2025-01-23T15:43:22Z

The first is removed with DC-API and the second may be as well following my discussion line here in this thread.

Not sure what you mean, the client identifier is either present in the request (signed request) or determined from the origin (unsigned request).

and imo that makes sense, the client_id is kind of an origin equivalent, because OAuth couldn't achieve this without OS support.

They are different (in case of signed request) and the client identifier is more of a logical identifier that could be used from different origins.

Co-authored-by: Giuseppe De Marco <[email protected]>

Co-authored-by: Brian Campbell <[email protected]>

Co-authored-by: Kristina <[email protected]>

tlodderstedt · 2025-01-23T15:48:55Z

openid-4-verifiable-presentations-1_0.md

+### client_id
+
+* Header Parameter Name: `client_id`
+* Header Parameter Description: This header contains a Client Identifier. 


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.

Sakurann · 2025-01-23T16:33:47Z

openid-4-verifiable-presentations-1_0.md

+{
+  "alg": "ES256",
+  "x5c": [
+    "MIICOjCCAeG...djzH7lA==",
+    "MIICLTCCAdS...koAmhWVKe"
+  ],
+  "client_id": "x509_san_dns:rp.example.com"
+}


specific proposal for disambiguating credential requested and credential_id

Suggested change

{

"alg": "ES256",

"x5c": [

"MIICOjCCAeG...djzH7lA==",

"MIICLTCCAdS...koAmhWVKe"

],

"client_id": "x509_san_dns:rp.example.com"

}

{

"alg": "ES256",

"x5c": [

"MIICOjCCAeG...djzH7lA==",

"MIICLTCCAdS...koAmhWVKe"

],

"client_id": "x509_san_dns:rp.example.com",

"credential_ids": [ <Array of strings each referencing a Credential requested by the Verifier> ]

}

credential_ids: REQUIRED. Array of strings each referencing a Credential requested by the Verifier that can be used in session transcript. In [DIF.PresentationExchange], the string matches the id field in the Input Descriptor. In the Digital Credentials Query Language, the string matches the id field in the Credential Query. If there is more than one element in the array, the Wallet MUST use only one of the referenced Credentials for session transcript

credential_id and client_id has to be 1:1 mapping. so that RP can determine a client_id based on the credential_id

alternative proposal:
wallet puts used client_id in the response next to the credential:

{ "my_credential": { “payload”: “eyJhbGci...QMA”, “client_id”: “asdf” } }

what prevents MITM replaying the request RP sent through the DC API:

for unsigned requests, origin is in the returned credential because origin == client_id

for signed request, expected_origins is in the signed request that MITM cannot modify

what prevents MITM replaying the request RP sent through the DC API:

for unsigned requests, origin is in the returned credential because origin == client_id

for signed request, expected_origins is in the signed request that MITM cannot modify

Thank you for this summary and apologies for struggling with the concept during the most recent DCP call. One nit just for posterity is that for unsigned request the client_id contains the origin and is prefixed (it doesn't strictly equal origin).

How about adding the client_id as an optional parameter (array of strings) to the Credential Query? That would simplify things quite a bit imho for the request:

If client_id is not present in the Credential Query: you use only one client_id in the request and nothing changes to the status quo (without multi-rp)

If client_id is present, the wallet can directly match which client ids are possible for each requested credential and choose accordingly

The DCQL vp_token gets an optional parameter client_id as well that is only included if more than one client_id was provided in the request (the DCQL query) and not present otherwise --> nothing changes for normal flows.

That way nothing changes for simple flows, but mult-rp flows extend the normal data structures without any unnecessary duplication unless I am missing something.

Sakurann · 2025-01-23T19:58:28Z

WG discussion notes
issue: which client id to put in the session transcript - there are two proposals on the table that were agreed to think through:

drop the Client Identifier from the session transcript (and have the origin only)
represent the relationship between a certain Client Identifier and the sub query / credential that Client Identifier is related to in the request and use that information to determine the expected Client Identifier for the corresponding Device Response object.

arguments to go the second way:

this means no more audience restriction and that has been a fundamental security feature. much larger change since openid4vp specification currently mandates audience restrictions for all credential format. which means this has impact on other credential formats too.
second approach is also disambiguation

proposal and further discussion documented https://github.com/openid/OpenID4VP/pull/308/files#r1927297499

Sakurann · 2025-01-23T20:02:22Z

We don't have another DCP WG mtg before ISO virtual mtg next week. Having heard DCP WG discussion and having re-read ISO requirement, what I would like to offer as a way forward is to explain at the ISO virtual mtg that we are addressing ISO requirement of “mdoc authentication must be bound to the origin” not by including origin in the session transcript but by what is described below. If this gets accepted, we can remove origin from session transcript as an option, and conclude this circular discussion we have been having:

what prevents MITM replaying the request RP sent through the DC API:

for unsigned requests, origin is in the returned credential because origin == client_id

for signed request, expected_origins is in the signed request that MITM cannot modify

David-Chadwick · 2025-01-23T20:47:46Z

Would it be better to rephrase the first bullet point to

for unsigned requests, the resulting credential is returned to the origin, because origin == client_id

GarethCOliver · 2025-01-23T23:55:37Z

Use Case: As a Verifier I want to request mDLs to verify KYC, and I accept mDLs issued in the EU, US.

US uses web PKI
EU uses an explicit trust framework

This seems like it would be a problem, unless we allow a mechanism to know to use the origin for particular returned credentials. (A US wallet may not be able to validate an EU signature, and so can't verify the signature over expected_origins)

…penID4VP into multiple-rp-credentials

tlodderstedt · 2025-02-04T20:15:26Z

Use Case: As a Verifier I want to request mDLs to verify KYC, and I accept mDLs issued in the EU, US.

US uses web PKI EU uses an explicit trust framework

This seems like it would be a problem, unless we allow a mechanism to know to use the origin for particular returned credentials. (A US wallet may not be able to validate an EU signature, and so can't verify the signature over expected_origins)

The question is whether the RP should be able to explicitly send an unsigned message or whether there should be a special logic to always try Web PKI in addition to the signed request.

first sketch

0833045

tlodderstedt mentioned this pull request Nov 5, 2024

How can verifiers that support multiple trust models/ecosystems know how to authenticate to the wallet? #248

Open

charsleysa reviewed Nov 10, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

c2bo reviewed Nov 11, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

selfissued requested changes Nov 12, 2024

View reviewed changes

tlodderstedt and others added 4 commits November 14, 2024 17:51

Update openid-4-verifiable-presentations-1_0.md

141e359

Co-authored-by: Stefan Charsley <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

5c69e3e

Co-authored-by: Christian Bormann <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

54a1672

Co-authored-by: Christian Bormann <[email protected]>

fixed typo

71268d6

tlodderstedt requested review from c2bo, peppelinux and charsleysa November 14, 2024 16:54

Sakurann reviewed Nov 14, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

Sakurann added priority ISO? labels Nov 22, 2024

Update openid-4-verifiable-presentations-1_0.md

43521e1

Co-authored-by: Kristina <[email protected]>

tlodderstedt requested review from martijnharing and removed request for charsleysa December 2, 2024 11:55

tlodderstedt mentioned this pull request Dec 3, 2024

refactor HAIP and add details for mdoc profile of OID4VP over the Browser API openid/oid4vc-haip#122

Merged

selfissued reviewed Dec 3, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

selfissued reviewed Dec 3, 2024

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

selfissued reviewed Dec 3, 2024

View reviewed changes

tlodderstedt and others added 4 commits January 14, 2025 20:00

Update openid-4-verifiable-presentations-1_0.md

9dbbc4e

Co-authored-by: Christian Bormann <[email protected]>

Merge branch 'multiple-rp-credentials' of https://github.com/openid/O…

20964b0

…penID4VP into multiple-rp-credentials

moved client_metadata back into request

a49eb50

removed client_metadata JOSE header registration

f6dea92

bc-pi mentioned this pull request Jan 21, 2025

Add version and request type to protocol identifier for DC API #381

Merged

peppelinux reviewed Jan 22, 2025

View reviewed changes

openid-4-verifiable-presentations-1_0.md Outdated Show resolved Hide resolved

peppelinux approved these changes Jan 22, 2025

View reviewed changes

tlodderstedt and others added 5 commits January 23, 2025 16:43

Update openid-4-verifiable-presentations-1_0.md

e32cecf

Co-authored-by: Giuseppe De Marco <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

d8bb9ff

Co-authored-by: Brian Campbell <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

d7a5048

Co-authored-by: Kristina <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

339e966

Co-authored-by: Kristina <[email protected]>

Update openid-4-verifiable-presentations-1_0.md

1a2f830

Co-authored-by: Kristina <[email protected]>

tlodderstedt commented Jan 23, 2025

View reviewed changes

Sakurann reviewed Jan 23, 2025

View reviewed changes

tlodderstedt added 2 commits January 27, 2025 12:22

modified example to match change re enc key

6d93c66

Merge branch 'multiple-rp-credentials' of https://github.com/openid/O…

9d7321c

…penID4VP into multiple-rp-credentials

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

Add Multi RP Credentials/Authentication capability #308

Are you sure you want to change the base?

Add Multi RP Credentials/Authentication capability #308

Conversation

tlodderstedt commented Nov 5, 2024 • edited by Sakurann Loading

selfissued left a comment

Choose a reason for hiding this comment

David-Chadwick commented Nov 12, 2024

Sakurann commented Nov 14, 2024

tlodderstedt commented Nov 14, 2024

David-Chadwick commented Nov 14, 2024

David-Chadwick commented Nov 14, 2024

tlodderstedt commented Nov 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tlodderstedt commented Jan 14, 2025 • edited Loading

awoie commented Jan 14, 2025

paulbastian commented Jan 14, 2025

tlodderstedt commented Jan 16, 2025

tlodderstedt commented Jan 16, 2025

paulbastian commented Jan 16, 2025

tlodderstedt commented Jan 16, 2025

paulbastian commented Jan 16, 2025 • edited Loading

peppelinux left a comment

Choose a reason for hiding this comment

tlodderstedt commented Jan 23, 2025

Choose a reason for hiding this comment

Sakurann Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Sakurann Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Sakurann Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bc-pi Jan 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Sakurann commented Jan 23, 2025

Sakurann commented Jan 23, 2025

David-Chadwick commented Jan 23, 2025

GarethCOliver commented Jan 23, 2025

tlodderstedt commented Feb 4, 2025

tlodderstedt commented Nov 5, 2024 •

edited by Sakurann

Loading

tlodderstedt commented Jan 14, 2025 •

edited

Loading

paulbastian commented Jan 16, 2025 •

edited

Loading

Sakurann Jan 23, 2025 •

edited

Loading

Sakurann Jan 23, 2025 •

edited

Loading

Sakurann Jan 23, 2025 •

edited

Loading

bc-pi Jan 23, 2025 •

edited

Loading