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

[Emelia Smith <[e-mail]>]

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)

Whilst we could add guidance I'm not sure it'd add any value given the sheer unlikely probability of creating a valid URI across 20-40 random bytes (fairly common sizes I've seen)

If you allow a user to select a client_id, then you should absolutely validate that that input isn't going to cause confusion with the other specifications implemented & that it won't cause security issues.

Also, thanks for the early feedback Dick!

Yours,

Emelia Smith

On 8. Jul 2024, at 18:06, 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.

> 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" rel="nofollow">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.

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

> 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" rel="nofollow">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" rel="nofollow">https://www.ietf.org/archive/id/draft-barnes-oauth-pika-00.html

Aaron

On Sat, Jul 6, 2024 at 4:09 PM Dick Hardt <[e-mail]> wrote:

Hey Aaron / Emelia

I stumbled across https://www.ietf.org/id/draft-parecki-oauth-client-id-metadata-document-00.html" target="_blank" rel="nofollow">https://www.ietf.org/id/draft-parecki-oauth-client-id-metadata-document-00.html

(was any info posted to the list?)

I like the general concept. Questions:

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

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. What is the use case for an array of redirect URIs? Why not just have each of those be a different client_id? Perhaps you could just have a redirect_path that is appended to the client_id URL? 

3. A number of the parameters in dynamic client registration are a negotiation between the client and the AS. For example from 7591 token_endpoint_auth_method, grant_types, response_types.scope. while including token_endpoint_auth_method = private_key_jwt is useful, the client is not getting a direct response back from the AS. How are you envisioning a mismatch between what is in these values and the response from the AS? In dynamic client registration the AS is returning what it will support. The only mechanism I can think of currently if the request is not supported is to return an invalid client error to the authorization request.

4. Along those lines, why are you pointing at 7591 rather than the list in IANA? 
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata" target="_blank" rel="nofollow">https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata

A useful property there to call out would be initiate_login_uri.

5. Along those lines, it may be useful to recommend which of those properties are useful and why. For example, should I have a contact property? I think there should be a minimum to implement so there is interoperability -- otherwise it is hit or miss if it will work. The one bit of client_id_metadata_document_supported will unlikely not be enough to have a successful flow unless there is a MTI.

6. Did you consider signing the metadata as a JWT as being one of the content types that could be returned?

That's all for now! Thanks for writing this up!

/Dick