DC API: Always use Origin for binding response #448

jogu · 2025-03-06T12:37:08Z

Implements option 5 from #395 (comment)

The means that, for example, the aud value in the SD-JWT key binding is based on the Origin obtained for the platform, even in the case of signed requests.

The Client Identified Scheme prefix on the value is retained in these cases, to avoid any potential mixup attack between these DC API responses and non-DC API responses to clients using OpenID Federation.

The Client Identifier Scheme name is changed from 'web-origin' to just 'origin' as it may contain a native app identifier, as per #351.

The "client_id" is removed from the mdoc OpenID4VPDCAPIHandover as it now serves no clear purpose.

It is left unsaid whether the Wallet is required to validate the signature on signed requests in all cases, this is a policy decision for Wallets. This change allows Wallets to skip the validation but still return a response that the Verifier can successfully process, as there is no longer any uncertaintly over what would be used for aud in SD-JWT KB JWT or for client_id in the ISO mdoc OpenID4VPDCAPIHandover structure.

closes #351
closes #395

Implements option 5 from #395 (comment) The means that, for example, the aud value in the SD-JWT key binding is based on the Origin obtained for the platform, even in the case of signed requests. The Client Identified Scheme prefix on the value is retained in these cases, to avoid any potential mixup attack between these DC API responses and non-DC API responses to clients using OpenID Federation. The Client Identifier Scheme name is changed from 'web-origin' to just 'origin' as it may contain a native app identifier, as per #351. The "client_id" is removed from the mdoc OpenID4VPDCAPIHandover as it now serves no clear purpose. It is left unsaid whether the Wallet is required to validate the signature on signed requests in all cases, this is a policy decision for Wallets. This change allows Wallets to skip the validation but still return a response that the Verifier can successfully process, as there is no longer any uncertaintly over what would be used for `aud` in SD-JWT KB JWT or for `client_id` in the ISO mdoc OpenID4VPDCAPIHandover structure. closes #351 closes #395

c2bo · 2025-03-07T12:43:08Z

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


-* `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api).
+* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.


Shouldn't we remove this whole section? This is not about a client_id anymore - we are just changing what to put into aud for DC API?

Suggested change

* `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api).

* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.

@c2bo I did wonder about that, but it's defined that what goes into aud is the client_id, and we're back to the problem of putting something into client_id that I think we need to be clear if it was intended for a client that authenticated using federation (+ custom url schemes) or one authenticated using just web PKI (+ DC API), for the same reasons we originally put the client id scheme into the aud - there's no other way for clients to tell the difference between those two types of responses.

Or to put another way, we are defining a meaning for 'origin' client id scheme in the response, so it's important that people don't define an origin client id scheme that means something different, hence retaining the definition in the client id scheme section as it would eventually need to be registered in any future IANA registry of client id schemes.

If Federation was always prefixed (with something other than "https://") then I think using just the url would make sense.

The alternative to say that in OID4VC over DC API, the audience of the credential presentation is the origin of the request and not the client identifier. That would require us to clearly split the spec in the "traditional" and the "DC" part including all security considerations.

That feels like the better/cleaner approach to me, but a pretty big change - especially given the current timelines

@tlodderstedt

The alternative to say that in OID4VC over DC API, the audience of the credential presentation is the origin of the request and not the client identifier. That would require us to clearly split the spec in the "traditional" and the "DC" part including all security considerations.

I don't think we really have a defined concept of the "audience of the credential presentation" in our credential format profiles though - we'd have to either introduce that concept, or have separate text for "traditional" versus "DC" in the credential format profiles too.

I don't think we really have a defined concept of the "audience of the credential presentation"

why? we do use a term audience (the Client Identifier of the Verifier) in the spec already.

That feels like the better/cleaner approach to me, but a pretty big change - especially given the current timelines

as an option, we could merge this PR and do this as part of a PR addressing #453 ? (cc @awoie )

so basically, we want the aud value to be prefixed with origin:, right? (to basically prevent the attacks that made us turn client id scheme parameter into a prefix in the first place). in which case, i agree it makes sense to keep this, but I would like to see more explanation that just The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. something like

The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. aud claims of the Verifiable Presentation MUST be the origin value prefixed with origin:

I've added a sentence of explanation like @Sakurann suggested.

tlodderstedt · 2025-03-11T18:57:45Z

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


 Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute.

+In places where the Client Identifier would be used in the response (for example, the `aud` value in a Key Binding JWT), the Origin MUST be used instead, prefixed with `origin:`.


This should go into a general description of the DC API profile. Here I would mention that client ids with authentication credentials can go into the request, but only for authentication/authorization purposes. The audience of the credential presentation is not affected by any of those client ids.

agreed. made suggestion above

I've rewritten this text and also added an explicit sentence about explaining the audience isn't affected by the client id in the request.

Sakurann · 2025-03-17T19:26:38Z

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


-* `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api).
+* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.


so basically, we want the aud value to be prefixed with origin:, right? (to basically prevent the attacks that made us turn client id scheme parameter into a prefix in the first place). in which case, i agree it makes sense to keep this, but I would like to see more explanation that just The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. something like

The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses. aud claims of the Verifiable Presentation MUST be the origin value prefixed with origin:

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

Sakurann · 2025-03-17T19:29:27Z

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


 Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute.

+In places where the Client Identifier would be used in the response (for example, the `aud` value in a Key Binding JWT), the Origin MUST be used instead, prefixed with `origin:`.


agreed. made suggestion above

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

Sakurann · 2025-03-18T21:20:13Z

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


 Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute.

+The security properties that are normally provided by the Client Identifier are achieved by binding the response to the Origin it was received from.
+
+The audience for the response (for example, the `aud` value in a Key Binding JWT) MUST be the Origin, prefixed with `origin:`. This is the case even for signed requests - when using OpenID4VP over the DC API the Client Identifier is never used as the audience for the response.


Suggested change

The audience for the response (for example, the `aud` value in a Key Binding JWT) MUST be the Origin, prefixed with `origin:`. This is the case even for signed requests - when using OpenID4VP over the DC API the Client Identifier is never used as the audience for the response.

The audience for the response (for example, the `aud` value in a Key Binding JWT) MUST be the Origin, prefixed with `origin:`, for example `origin:https://verifier.example.com/`. This is the case even for signed requests. Therefore, when using OpenID4VP over the DC API, the Client Identifier is not used as the audience for the response.

Sakurann · 2025-03-18T21:21:13Z

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

@@ -574,7 +574,7 @@ Body

 * `x509_san_dns`: When the Client Identifier Scheme is `x509_san_dns`, the Client Identifier MUST be a DNS name and match a `dNSName` Subject Alternative Name (SAN) [@!RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the `x5c` JOSE header [@!RFC7515] of the signed request object. The Wallet MUST validate the signature and the trust chain of the X.509 certificate. All Verifier metadata other than the public key MUST be obtained from the `client_metadata` parameter. If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the `redirect_uri` value. If not, the FQDN of the `redirect_uri` value MUST match the Client Identifier without the prefix `x509_san_dns:`. Example Client Identifier: `x509_san_dns:client.example.org`.

-* `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api).
+* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests. In OpenID4VP over the Digital Credentials API the audience of the Credential Presentation is the origin value prefixed by `origin:`, for example `origin:https://verifier.example.com/`.


Suggested change

* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests. In OpenID4VP over the Digital Credentials API the audience of the Credential Presentation is the origin value prefixed by `origin:`, for example `origin:https://verifier.example.com/`.

* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests. In OpenID4VP over the Digital Credentials API, the audience of the Credential Presentation is always the origin value prefixed by `origin:`, for example `origin:https://verifier.example.com/`.

Sakurann · 2025-03-18T21:24:37Z

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

@@ -2136,7 +2141,7 @@ This `presentation_definition` parameter contains a single `input_descriptor` el
 The following requirements apply to the `nonce` and `aud` claims of the Verifiable Presentation:

 - the `nonce` claim MUST be the value of `nonce` from the Authorization Request;
- the `aud` claim MUST be the value of the Client Identifier; or effective Client Identifier for an unsigned Authorization Request over the DC API, as described in (#dc_api_request).
+- the `aud` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).


Suggested change

- the `aud` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

- the `aud` claim MUST be the value of the Client Identifier. For a request over the DC API, it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

Sakurann · 2025-03-18T21:25:00Z

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

@@ -2181,7 +2186,7 @@ This `presentation_definition` parameter contains a single `input_descriptor` el
 The following requirements apply to the `challenge` and `domain` claims within the `proof` object in the Verifiable Presentation:

 - the `challenge` claim MUST be the value of `nonce` from the Authorization Request;
- the `domain` claim MUST be the value of the Client Identifier; or effective Client Identifier for an unsigned Authorization Request over the DC API, as described in (#dc_api_request).
+- the `domain` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).


Suggested change

- the `domain` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

- the `domain` claim MUST be the value of the Client Identifier. For a request over the DC API, it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

Sakurann · 2025-03-18T21:25:16Z

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

- the `aud` claim MUST be the value of the Client Identifier; 
-
-Note that for an unsigned Authorization Request over the DC API, the `client_id` parameter is not used. Instead, the effective Client Identifier is derived from the Origin, as described in (#dc_api_request).
+- the `aud` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).


Suggested change

- the `aud` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

- the `aud` claim MUST be the value of the Client Identifier; For a request over the DC API, it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

Sakurann · 2025-03-18T21:26:31Z

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

@@ -2052,14 +2052,16 @@ Out of the Authorization Request parameters defined in [@!RFC6749] and (#vp_toke
 * `transaction_data`
 * `dcql_query`

-The `client_id` parameter MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet determines the effective Client Identifier from the Origin. The effective Client Identifier is composed of a synthetic Client Identifier Scheme of `web-origin` and the Origin itself. For example, an Origin of `https://verifier.example.com` would result in an effective Client Identifier of `web-origin:https://verifier.example.com`. The transport of the request and Origin to the Wallet is platform-specific and is out of scope of OpenID4VP over the W3C Digital Credentials API. The Wallet MUST ignore any `client_id` parameter that is present in an unsigned request.
+The `client_id` parameter MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet MUST ignore any `client_id` parameter that is present in an unsigned request.


Suggested change

The `client_id` parameter MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet MUST ignore any `client_id` parameter that is present in an unsigned request.

The `client_id` parameter MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet MUST ignore any `client_id` parameter that is present in an unsigned request.

In signed requests, `client_id` parameter MUST be present, as it governs Client Identifier Scheme specific handling of the request.

this one sentence would prevent confusion i had...

Sakurann

looks good - editorial suggestions. assuming majority of them would be incorporated

jogu mentioned this pull request Mar 6, 2025

feat: add example for sessiontranscript related structures #449

Open

Sakurann requested review from danielfett, tlodderstedt, davidz25, c2bo, leecam, tplooker, paulbastian, awoie, Sakurann, martijnharing, bc-pi and hlozi March 6, 2025 16:08

Sakurann mentioned this pull request Mar 6, 2025

Improve text on effective Client Identifiers #435

Closed

jogu force-pushed the dc-api-remove-clientid-in-responses branch from fb638a0 to 995152a Compare March 7, 2025 03:41

c2bo mentioned this pull request Mar 7, 2025

text about effective client id in DC API can probably be improved #399

Open

c2bo reviewed Mar 7, 2025

View reviewed changes

Sakurann added this to the Final 1.0 milestone Mar 11, 2025

Sakurann added the priority label Mar 11, 2025

tlodderstedt reviewed Mar 11, 2025

View reviewed changes

Sakurann requested changes Mar 17, 2025

View reviewed changes

jogu and others added 2 commits March 18, 2025 10:55

Apply (part of) Kristina's suggestion

87e010b

Further revisions to attempt to address feedback on the PR

be943cf

Sakurann reviewed Mar 18, 2025

View reviewed changes

Sakurann approved these changes Mar 18, 2025

View reviewed changes

Sakurann requested review from tlodderstedt and c2bo March 18, 2025 21:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DC API: Always use Origin for binding response #448

DC API: Always use Origin for binding response #448

jogu commented Mar 6, 2025

c2bo Mar 7, 2025

jogu Mar 10, 2025

tlodderstedt Mar 11, 2025

c2bo Mar 12, 2025

jogu Mar 13, 2025

Sakurann Mar 17, 2025

Sakurann Mar 17, 2025

jogu Mar 18, 2025

tlodderstedt Mar 11, 2025

Sakurann Mar 17, 2025

jogu Mar 18, 2025 •

edited

Loading

Sakurann Mar 17, 2025

Sakurann Mar 17, 2025

Sakurann Mar 18, 2025

Sakurann Mar 18, 2025

Sakurann Mar 18, 2025

Sakurann Mar 18, 2025

Sakurann Mar 18, 2025

Sakurann Mar 18, 2025

Sakurann left a comment


		* `web-origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme if the request is not sent via the Digital Credentials API defined in (#dc_api).
		* `origin`: This Client Identifier Scheme is defined in (#dc_api_request). The Wallet MUST NOT accept this Client Identifier Scheme in requests - it is only used in responses.


		Every OpenID4VP Authorization Request results in a response being provided through the Digital Credentials API (DC API). The response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Authorization Response parameters as defined for the Response Type are represented as an object within the `data` attribute.

		In places where the Client Identifier would be used in the response (for example, the `aud` value in a Key Binding JWT), the Origin MUST be used instead, prefixed with `origin:`.

	The audience for the response (for example, the `aud` value in a Key Binding JWT) MUST be the Origin, prefixed with `origin:`. This is the case even for signed requests - when using OpenID4VP over the DC API the Client Identifier is never used as the audience for the response.
	The audience for the response (for example, the `aud` value in a Key Binding JWT) MUST be the Origin, prefixed with `origin:`, for example `origin:https://verifier.example.com/`. This is the case even for signed requests. Therefore, when using OpenID4VP over the DC API, the Client Identifier is not used as the audience for the response.

	- the `aud` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).
	- the `aud` claim MUST be the value of the Client Identifier. For a request over the DC API, it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

	- the `domain` claim MUST be the value of the Client Identifier; or for a request over the DC API MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).
	- the `domain` claim MUST be the value of the Client Identifier. For a request over the DC API, it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

DC API: Always use Origin for binding response #448

Are you sure you want to change the base?

DC API: Always use Origin for binding response #448

Conversation

jogu commented Mar 6, 2025

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

Choose a reason for hiding this comment

jogu Mar 18, 2025 • edited Loading

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

Sakurann left a comment

Choose a reason for hiding this comment

jogu Mar 18, 2025 •

edited

Loading