slight tweak to default treatment of https URLs #468

aaronpk · 2025-03-24T06:31:55Z

unambiguously defines the plain https Client Identifier URLs as a fallback to mean OpenID Federation

This is a PR against the open PR #401

Context of this PR is documented in #401 (comment)

unambiguously defines the plain https Client Identifier URLs as a fallback to mean OpenID Federation

as per joseph's suggestion

Sakurann

i am not comfortable with keeping https to be reserved only for openid federation. what I said in #401 (comment)

Sakurann · 2025-03-24T21:21:10Z

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


 For example, if an Authorization Request contains `client_id=example-client`, the Wallet would interpret the Client Identifier as referring to a pre-registered client.

+If the Client Identifier begins with `https://` the full Client Identifier URL represents an Entity Identifier defined in OpenID Federation [@!OpenID.Federation] and MUST be processed as though it was prefixed with `openid_federation` as described below.


I personally don't have an issue with OpenID4VP defining the default behavior of https URLs as long as it's defined only within the context of OpenID4VP and doesn't spill out to unrelated communities and ecosystems.

if this is the case, it must be much more explicit that this https:// behavior is only for openid4vp context

Aaron's intent is to make it not ambiguous that within the context of openid4vp, https client_id_scheme is federation.
Brian's PR says, if there is no prefix, the wallet implementation picks the default. so this PR clarifies, when the url does not have a prefix, default is openidfederation.

jogu · 2025-03-26T02:58:28Z

I got a request for a rendered version of this PR so uploaded html that would result from this PR here in case it's useful to others:

https://www.heenan.me.uk/~joseph/openid-4-verifiable-presentations-1_0-pr468-2025-04-26.html#section-5.10

selfissued

This improves the PR that it would be merged into by removing the breaking change.

lj-raidiam · 2025-04-01T14:59:54Z

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

 * `x509_hash`: When the Client Identifier Scheme is `x509_hash`, the Client Identifier MUST be a hash and match the hash of 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 parameter [@!RFC7515] of the signed request object. The value of `x509_hash` is the base64url encoded value of the SHA-256 hash of the DER-encoded X.509 certificate. The Wallet MUST validate the signature and the trust chain of the X.509 leaf certificate. All verifier metadata other than the public key MUST be obtained from the `client_metadata` parameter. Example Client Identifier: `x509_hash:Uvo3HtuIxuhC92rShpgqcT3YXwrqRxWEviRiA0OZszk`

-To use the Client Identifier Schemes `https`, `did`, `verifier_attestation`, `x509_san_dns` and `x509_hash`, Verifiers MUST be confidential clients. This might require changes to the technical design of native apps as such apps are typically public clients.
+* `openid_federation`: This value indicates that the Client Identifier is an Entity Identifier defined in OpenID Federation [@!OpenID.Federation]. Processing rules given in [@!OpenID.Federation] MUST be followed. Automatic Registration as defined in [@!OpenID.Federation] MUST be used. The Authorization Request MAY also contain a `trust_chain` parameter. The final Verifier metadata is obtained from the Trust Chain after applying the policies, according to [@!OpenID.Federation]. The `client_metadata` parameter, if present in the Authorization Request, MUST be ignored when this Client Identifier scheme is used. Example Client Identifier: `openid_federation:https://federation-verifier.example.com`.


We would need to add here (without the openid_federation: prefix) like in case of the redirect_uri

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

Sakurann · 2025-04-01T20:07:29Z

WG discussion:

be clear that https is not a prefix, because it is not.
default is openid_federation: prefix is used for openid federation deployments.
- dids also get prefixed with decentralzied-identifier:
but! if client_id does not have a prefix, and it happens to start with https://, there is one expected behavior, which is the same as openid_federation:
- do we need to be explicit about this "no prefix, but it's https" scenario? if we are trying to discourage no-prefix scenario at all? if not harmful, might be better to define a behavior rather than keeping ?
add security considerations on this
- as long as someone is using https prefix, security issue that led to prefixing client id remains? vs this issue exists only when there are multiple ways to interpret, but not when there is one way to interpret https prefix.

Sakurann · 2025-04-01T21:13:26Z

chair hat off, we should also define behavior when client_id does not have a prefix, and does not happen to start with https://

jogu · 2025-04-01T21:38:54Z

Just for info for readers: there is some overlap with the federation spec owned connect wg here, and this is scheduled to be discussed on Thursday's Connect WG call, we're trying to the best of our ability to have alignment between Connect, DCP & OAuth working groups.

jogu · 2025-04-01T21:40:57Z

@Sakurann

chair hat off, we should also define behavior when client_id does not have a prefix, and does not happen to start with https://

There's text here (which I think has been there a while):

https://www.heenan.me.uk/~joseph/openid-4-verifiable-presentations-1_0-pr468-2025-04-26.html#section-5.10.2

in particular:

If a : character is not present in the Client Identifier, the Wallet MUST treat the Client Identifier as referencing a pre-registered client. This is equivalent to the [RFC6749] default behavior, i.e., the Client Identifier needs to be known to the Wallet in advance of the Authorization Request. The Verifier metadata is obtained using [RFC7591] or through out-of-band mechanisms.

Do you think this needs any change?

sloops77 · 2025-04-02T01:58:39Z

i listened to the discussion and it seems strange to have two ways of being able to utilize openid federation. What are the consequences?

The wallets in the existing ecosystems may end up implementing the openid_federation prefix for ecosystem interop anyway.
For new implementors how do they navigate having two ways to implement open id fed? Should they implement the prefix or rely on the default behaviour or should they do both? The right answer will depends on their use case - but the decision can be quite nuanced and therefore its opening up room for incorrect decisions by implementors and therefore interop issues

Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>

sloops77 · 2025-04-03T21:32:29Z

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

 For example, if an Authorization Request contains `client_id=example-client`, the Wallet would interpret the Client Identifier as referring to a pre-registered client.

+If the Client Identifier begins with `https://` the full Client Identifier URL represents an Entity Identifier defined in OpenID Federation [@!OpenID.Federation] and MUST be processed as though it was prefixed with `openid_federation` as described below.
+Note that like all requirements in this specification, this requirement only applies when using this specification.


this new sentence is a tautology

Sakurann · 2025-04-05T09:55:20Z

please re-review PR #401 in light of new understanding in DCP WG that is documented in #401 (comment)

bc-pi

the underlying openid:equal-treatment-under-the-prefix branch and open PR #401 against which this one was created no longer has default so this has effectively been overcome by events

aaronpk · 2025-04-07T03:36:17Z

I don't think this PR is necessary anymore since the changes to #401, as has been discussed in the WG call and in the issue comments.

slight tweak to default treatment of https URLs

2c25a1b

unambiguously defines the plain https Client Identifier URLs as a fallback to mean OpenID Federation

aaronpk mentioned this pull request Mar 24, 2025

make consistent the use of prefixes in the client_id prefixing #401

Merged

move https fallback definition into fallback section

fdf2192

as per joseph's suggestion

Sakurann requested changes Mar 24, 2025

View reviewed changes

Sakurann reviewed Mar 24, 2025

View reviewed changes

selfissued approved these changes Apr 1, 2025

View reviewed changes

lj-raidiam reviewed Apr 1, 2025

View reviewed changes

selfissued reviewed Apr 1, 2025

View reviewed changes

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

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

955b716

Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>

sloops77 reviewed Apr 3, 2025

View reviewed changes

Sakurann added the pending-close label Apr 5, 2025

bc-pi requested changes Apr 6, 2025

View reviewed changes

aaronpk closed this Apr 7, 2025


		For example, if an Authorization Request contains `client_id=example-client`, the Wallet would interpret the Client Identifier as referring to a pre-registered client.

		If the Client Identifier begins with `https://` the full Client Identifier URL represents an Entity Identifier defined in OpenID Federation [@!OpenID.Federation] and MUST be processed as though it was prefixed with `openid_federation` as described below.

slight tweak to default treatment of https URLs #468

slight tweak to default treatment of https URLs #468

Uh oh!

Conversation

aaronpk commented Mar 24, 2025 • edited by Sakurann Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sakurann left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sakurann Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

Sakurann Apr 1, 2025

Choose a reason for hiding this comment

Uh oh!

jogu commented Mar 26, 2025

Uh oh!

selfissued left a comment

Choose a reason for hiding this comment

Uh oh!

lj-raidiam Apr 1, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Sakurann commented Apr 1, 2025

Uh oh!

Sakurann commented Apr 1, 2025

Uh oh!

jogu commented Apr 1, 2025

Uh oh!

jogu commented Apr 1, 2025

Uh oh!

sloops77 commented Apr 2, 2025

Uh oh!

sloops77 Apr 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sakurann commented Apr 5, 2025

Uh oh!

bc-pi left a comment

Choose a reason for hiding this comment

Uh oh!

aaronpk commented Apr 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

aaronpk commented Mar 24, 2025 •

edited by Sakurann

Loading

Sakurann left a comment •

edited

Loading

sloops77 Apr 3, 2025 •

edited

Loading