[{"author": "Brian Campbell", "text": "

what would that look like?

", "time": "2025-01-06T17:16:38Z"}, {"author": "Christian Bormann", "text": "

client_id_scheme

", "time": "2025-01-06T17:18:16Z"}, {"author": "Daniel Fett", "text": "

This is why we removed the separate parameter client_id_scheme in OpenID4VPP again: https://github.com/openid/OpenID4VP/issues/124

", "time": "2025-01-06T17:19:21Z"}, {"author": "Emelia Smith", "text": "

will have a look at this, though, I would've thought in any stage post authorization request or PAR, the client_id is just an opaque value

", "time": "2025-01-06T17:21:54Z"}, {"author": "Emelia Smith", "text": "

so if you supported both openid federation and the oauth client id metadata documents, you'd still have a conflict of client_id's if the same URI can server multiple different types of clients id values

", "time": "2025-01-06T17:22:59Z"}, {"author": "Daniel Fett", "text": "

The problem arises as soon as there is more than one interpretation of the same client_id value. An explicit prefix disambiguates that while it still can be treated as an opaque value elsewhere.

", "time": "2025-01-06T17:22:59Z"}, {"author": "Alper Demir", "text": "

why ther is = sign between client_id and scheme?

", "time": "2025-01-06T17:23:00Z"}, {"author": "Emelia Smith", "text": "

like, in the later stages, client_id would be the same as a different client_id if client_id is not unique

", "time": "2025-01-06T17:23:29Z"}, {"author": "Joseph Heenan", "text": "

The problem is primarily/only currently with client_ids that have https: at the start of them

", "time": "2025-01-06T17:23:35Z"}, {"author": "Joseph Heenan", "text": "

\"why ther is = sign between client_id and scheme?\"

\n

On the previous slide? That's just showing how the client id is passed to the authorization server currently. It's unchanged.

", "time": "2025-01-06T17:24:19Z"}, {"author": "Emelia Smith", "text": "

That's sort of the same issue I touch on above

", "time": "2025-01-06T17:25:58Z"}, {"author": "Emelia Smith", "text": "

I'd say it's not that we shouldn't use bare https://, but rather, it's recommend you do prefix if you support multiple, otherwise define a default for the https client_id protocol

", "time": "2025-01-06T17:37:07Z"}, {"author": "Joseph Heenan", "text": "

I think for the sake of everyone's sanity we should say don't use https urls for new things. There's no advantage to doing so.

", "time": "2025-01-06T17:39:12Z"}, {"author": "Brian Campbell", "text": "

mixed and matched wasn't the problem

", "time": "2025-01-06T17:39:23Z"}, {"author": "Emelia Smith", "text": "

so if the server has a default for \"what does a https prefix on a client_id mean\" then we'd side step that?

", "time": "2025-01-06T17:39:56Z"}, {"author": "Joseph Heenan", "text": "

For new specifications that want to use https:// based urls as client_ids, yes.

", "time": "2025-01-06T17:40:39Z"}, {"author": "Emelia Smith", "text": "

things that'll never support OpenID Federation can still use bare https:// URIs as client ids because there's no conflict \u2014 it's only if you support a conflict that this scheme is necessary

", "time": "2025-01-06T17:40:53Z"}, {"author": "Brian Campbell", "text": "
\n

no advantage to doing so.

\n
\n

the only advantage is those that squated on it first?

", "time": "2025-01-06T17:40:54Z"}, {"author": "Emelia Smith", "text": "

I think it'd be better to show it as:

\n

metadata:https://....
\nfederation:https://...

\n

etc

", "time": "2025-01-06T17:41:48Z"}, {"author": "Joseph Heenan", "text": "
\n

think it'd be better to show it as:
\nmetadata:https://...

\n
\n

That's what the draft suggests right? Or I'm not sure how your suggestion differs. We're just discussing the fallback case for existing ecosystems?

", "time": "2025-01-06T17:43:54Z"}, {"author": "Emelia Smith", "text": "

no, as far as I can tell it's not

", "time": "2025-01-06T17:44:06Z"}, {"author": "Emelia Smith", "text": "

it's using the https: or did: as the scheme, resulting in the value being everything after the colon

", "time": "2025-01-06T17:44:31Z"}, {"author": "Joseph Heenan", "text": "

https://drafts.aaronpk.com/oauth-client-id-scheme/draft-parecki-oauth-client-id-scheme.html#section-3.4 - the default position for federation is \"Example Client Identifier: federation:https://federation-client.example.com.\u00b6\" for example.

", "time": "2025-01-06T17:45:04Z"}, {"author": "Emelia Smith", "text": "

oh, okay that's really weird

", "time": "2025-01-06T17:45:37Z"}, {"author": "Hannes Tschofenig", "text": "

Yes, very strange

", "time": "2025-01-06T17:46:06Z"}, {"author": "Joseph Heenan", "text": "

This discussion is all about what how to handle existing deployed authorization servers that are already using base https

", "time": "2025-01-06T17:46:21Z"}, {"author": "Emelia Smith", "text": "

like in https://example.com, I'd expect that to be treated as a value without a scheme/type

", "time": "2025-01-06T17:46:33Z"}, {"author": "Daniel Fett", "text": "

The rules in VP are weird indeed, but they represent a compromise that we found specifically for making this change in VP. Our discussion here can lead to a different outcome.

", "time": "2025-01-06T17:47:23Z"}, {"author": "Hannes Tschofenig", "text": "

Is VP already cast in stone?

", "time": "2025-01-06T17:48:00Z"}, {"author": "Pierce Gorman", "text": "

It would seem \"metadata\", \"federation\", and \"URI\" could all be client_id_scheme

", "time": "2025-01-06T17:48:08Z"}, {"author": "Joseph Heenan", "text": "
\n

Is VP already cast in stone?

\n
\n

Not 100%, but it will be within the next few months.

", "time": "2025-01-06T17:48:28Z"}, {"author": "Hannes Tschofenig", "text": "

Maybe it is better not to call it \"scheme\".

", "time": "2025-01-06T17:48:34Z"}, {"author": "Daniel Fett", "text": "

\"Client ID Not-a-Scheme\"

", "time": "2025-01-06T17:48:47Z"}, {"author": "Michael Jones", "text": "

OpenID4VP is on its probably last Implementer's Draft, with plans to take it final within a few months.

", "time": "2025-01-06T17:48:47Z"}, {"author": "Joseph Heenan", "text": "
\n

Maybe it is better not to call it \"scheme\".

\n
\n

That's definitely an option.

", "time": "2025-01-06T17:48:59Z"}, {"author": "Emelia Smith", "text": "

I'd say \"type\" instead of \"scheme\"

", "time": "2025-01-06T17:49:14Z"}, {"author": "Brian Campbell", "text": "

I think I agree with much of what Emelia said

", "time": "2025-01-06T17:49:36Z"}, {"author": "Hannes Tschofenig", "text": "

Makes sense to me as well

", "time": "2025-01-06T17:49:46Z"}, {"author": "Alper Demir", "text": "

I was also confused with the term \"scheme\". It is kind of misleading.

", "time": "2025-01-06T17:52:27Z"}, {"author": "Brian Campbell", "text": "

I think the point is that https/did/http wouldn't be a scheme/type

", "time": "2025-01-06T17:52:58Z"}, {"author": "Joseph Heenan", "text": "

I think \"scheme\" does cause a lot of confusion and I'd likely be in favour of a different term.

", "time": "2025-01-06T17:53:05Z"}, {"author": "Emelia Smith", "text": "

yeah, so, if you needed did:example:1234, you'd actually need something in front of did:example:1234

", "time": "2025-01-06T17:53:36Z"}, {"author": "Emelia Smith", "text": "

e.g., defi:did:example:1234

", "time": "2025-01-06T17:53:52Z"}, {"author": "Pierce Gorman", "text": "

Agree

", "time": "2025-01-06T17:54:03Z"}, {"author": "Emelia Smith", "text": "

because example:1234 isn't a did in itself, and is not a value you can pass to a DID Resolver

", "time": "2025-01-06T17:54:30Z"}, {"author": "Emelia Smith", "text": "

(afaik)

", "time": "2025-01-06T17:54:43Z"}, {"author": "Pieter Kasselman", "text": "

Servers will need to updated in any event no?

", "time": "2025-01-06T17:54:44Z"}, {"author": "Alper Demir", "text": "

Other than http, all others are identifiers. I do not understand why we have http?

", "time": "2025-01-06T17:59:12Z"}, {"author": "Dick Hardt", "text": "

looking at a different query parameter is much simpler than parsing the client_id value

", "time": "2025-01-06T17:59:36Z"}, {"author": "Dmitry Telegin", "text": "

Solid-OIDC still uses https in their latest spec, with a JSON-LD client ID document (and a fallback to DCR)

", "time": "2025-01-06T18:00:27Z"}, {"author": "Brian Campbell", "text": "
\n

looking at a different query parameter is much simpler than parsing the client_id value

\n
\n

experience has shown that not to be the case

", "time": "2025-01-06T18:00:45Z"}, {"author": "Emelia Smith", "text": "

Yeah, client id metadata documents is designed to be backwards compatible with solid OIDC's thing

", "time": "2025-01-06T18:00:55Z"}, {"author": "Pieter Kasselman", "text": "

It is a really interesting idea Dick - perhaps worth hacving it written up as an alternative?

", "time": "2025-01-06T18:01:02Z"}, {"author": "Dick Hardt", "text": "

Elaborate Brian

", "time": "2025-01-06T18:01:04Z"}, {"author": "Emelia Smith", "text": "

they are practically the same thing, we basically lifted what solid did up into the oauth scope

", "time": "2025-01-06T18:01:17Z"}, {"author": "Brian Campbell", "text": "

what several folks have said about attempts with the client_id_scheme

", "time": "2025-01-06T18:02:25Z"}, {"author": "Pieter Kasselman", "text": "

client_metadata then?

", "time": "2025-01-06T18:02:28Z"}, {"author": "Aaron Parecki", "text": "

https://www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-01.html

", "time": "2025-01-06T18:04:13Z"}, {"author": "Emelia Smith", "text": "

hmm, I received an email it expired yesterday

", "time": "2025-01-06T18:04:38Z"}, {"author": "Emelia Smith", "text": "

but now I see I read that wrong

", "time": "2025-01-06T18:05:00Z"}, {"author": "Pierce Gorman", "text": "

Good meeting. Happy New Year everyone.

", "time": "2025-01-06T18:05:27Z"}]