Inline .. On Mon, Jul 8, 2024 at 9:06 AM Aaron Parecki <aa...@parecki.com> 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
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
