> On Jul 8, 2024, at 10:06 AM, Aaron Parecki
> <aaron=40parecki....@dmarc.ietf.org> 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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
