[OAUTH-WG] Re: OAuth Client ID Metadata Document

["Emelia S." <[e-mail]>]

I would suggest that if an AS were to implement to competing specifications for what a client_id means, then it'd be up to the implementor to decide what is used when. E.g., it'd be difficult to support both OpenID Federation and this I-D simultaneously without some degree of work on the implementors' behalf to try to decide which specification should be used (both have client_id's as URIs, but operate very differently)

The only real mechanism for "claim" here would be through some sort of DNS proof, but that requires either some sort of binding between the client identifier metadata document and the DNS record, or some pre-existing relationship with the AS where the AS provides the value for the proof. I'd be inclined to consider this out of scope, and just allow AS's to provide access to resources as they see fit (no different to dynamic client registration)

> Thanks for this work Emelia! Will you be in Vancouver IETF?

Unfortunately I won't be in Vancouver for it, but do intend to attend remotely where possible. (I'm an independent developer, so don't typically have budget for travel)

Yours,
Emelia Smith

> On 8 Jul 2024, at 20:07, Dick Hardt <[e-mail]> wrote:
> 
> On Mon, Jul 8, 2024 at 10:15 AM Emelia Smith <[e-mail] <mailto:[e-mail]>> wrote:
>> Just to follow up on this, further:
>> > > 1. If an AS supports both registered, and unregistered clients, is there any guidance or requirements on differentiating between them such as NOT issuing other identifiers that start with 'https"? 
>> >
>> > This is probably a good call-out. I am unsure about how many AS's would actually support both types of clients in practice though.
>> 
>> In practice you're not checking for "https" but "https://", furthermore most implementations use random bytes, often base64url or hex encoded, so they simply don't have the character set necessary to generate client_id's that are also valid URIs (or at least, the probability of this is incredibly small)
> 
> Agree on the "https://" -- that was what I intended.
> 
> There may be ASes that use URLs as identifiers. I don't know of any.
> 
> Not having thought it all through, I might allow a developer to "claim" a "https://" client_id so that they could have more functionality, for example to enable localhost or access to more sensitive data. 
> 
> Thanks for this work Emelia! Will you be in Vancouver IETF?
> 
> /Dick