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

[David Waite <[e-mail]>]

> On Jul 8, 2024, at 10:06 AM, Aaron Parecki <aaron=[e-mail]> wrote:
> 
> Thanks Dick, I hadn't gotten to post this to the list yet, but thanks for kicking off the discussion!
> 
> FYI there are already a few live implementations of this, and some additional in-progress implementations. There is also some overlap between this and an application of FedCM, which is where some of the initial implementation work has begun. I'll share more details on this and the FedCM work at IETF 120.
> 
> > 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.

There are multiple resolution methods; consider locally administered metadata, dynamic client registration, this, and OpenID federation to be four such examples. OpenID4VP has several additional examples.

One wants to make sure that the four cannot conflict, such as someone overriding Client ID metadata via OpenID Federation metadata, or attempting to override statically configured metadata via any dynamic mechanism. In OpenID4VP, this is done by adding an additional  client_id_scheme - the client is then known by the pair of scheme and identifier, and two identifiers with the same scheme are considered unrelated.  Solves the issue of how to distinguish several different dynamic schemes with possibly expensive resolution processes.

> > 2. From a security perspective, I worry about the redirect URIs being any arbitrary URL -- perhaps that they need to start with the client_id? Is localhost supported as a redirect URI.
> 
> There will likely be some special handling for localhost client IDs and redirect URIs, particularly for development clients. There is some discussion about this happening on GitHub here: https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/12 
> 
> For the non-development use cases, I think we should further discuss whether the limitation of the redirect URI starting with the client ID is helpful or not. Another set of use cases is native apps using custom URI schemes or even app-claimed HTTPS URLs which might have some more edge cases to consider.

Would this be any different from considerations around using OAuth DCR?

All the metadata is self-asserted - you have to assume that from the standpoint of phishing user access, every value is potentially malicious. You do not want to display the given client name, or given logo, or have links to the TOS or other content which may link to the legitimate party to provide an air of legitimacy..

<snip>

-DW