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

[Dick Hardt <[e-mail]>]

Inline ..

On Mon, Jul 8, 2024 at 9:06 AM Aaron Parecki <[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.
>

We (Hellō) will do both presuming this approach resonates with developers.


>
> > 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
>
>

I added a comment there.


>
> 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.
>

An app-claimed HTTPS URL seems to be the secure path going forward for
native apps. What would be edge cases around that?


>
> > 3. A number of the parameters in dynamic client registration are a
> negotiation between the client and the AS.
>
> Correct, this is not a negotiation anymore, this is a statement from the
> client about its properties, which the AS can either accept or reject
> during an authorization.
>

Which means a bad use experience if it is rejected.


>
> > 4. Along those lines, why are you pointing at 7591 rather than the list
> in IANA?
>
> Good call, we should update this to point to the IANA registry.
>
> > 5. Along those lines, it may be useful to recommend which of those
> properties are useful and why. ... The one bit of client_id_metadata_document_supported
> will unlikely not be enough to have a successful flow unless there is a MTI.
>
> I think it would be a good exercise to see if there is a MTI subset for
> interoperability. I'll track this on GitHub for further discussion:
> https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/15
>
> > 6. Did you consider signing the metadata as a JWT as being one of the
> content types that could be returned?
>
> It occurred to me, but I am not sure how valuable that actually is. The
> metadata is fetched over HTTPS, so signing it doesn't provide any
> additional integrity there. It could provide non-repudiation of the
> metadata, except that in order to do so it would have to be signed with a
> key that could later be proven to be from the client as well. Since this is
> primarily designed to be used by clients with no prior relationship with
> the AS, it is unclear how the provenance of the public key would be proven.
> I think this would require PIKA to be useful:
> https://www.ietf.org/archive/id/draft-barnes-oauth-pika-00.html
>

I don't have a good use case for it. Was wondering if you had given the
text about different content-types.

/Dick