HI Everyone, I support the adoption.
I also echo a need to describe in more detail AS behaviour and how the client_id and metadata are delivered to the AS. Some examples would be ideal. I also share some of Neil’s concerns. What’s the relation of this draft to the Client ID Prefix and are there any plans for incorporating it? Now, this draft says in the intro about the use of the "URL as the Client ID,” while I remember discussions from a couple of months ago related to preventing a situation where a single spec becomes the default for the https scheme, leading to a need for, as I suppose, being explicit about use of prefixes everywhere. Aaron, could you shed some light on it? Regards Lukasz Jaromin Head of Standards and Product Strategy [email protected]<mailto:[email protected]> On 30 Sep 2025, at 17:50, Lombardo, Jeff <[email protected]> wrote: Digressing on the formulation of the fetching and the notion of cache at the AS: | You don't need normative language on exactly how the AS | received the client_id -- perhaps: | | When the AS receives a client_id either through an authorization | request, a pushed authorization request, or similar flow, the AS | fetches the document indicated by the client_id if it is not | available in cache. We need to be careful of the influence of the cache over the logic applied by the AS by not applying the latest and greatest of the information as defined inhttps://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/45. Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité Principal Solution Architect, Security Specialist Montréal, Canada Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. From: Dick Hardt <[email protected]<mailto:[email protected]>> Sent: September 30, 2025 11:16 AM To: Emelia S. <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [EXT] [OAUTH-WG] Re: Call for adoption: draft-parecki-oauth-client-id-metadata-document-03 (Ends 2025-10-06) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. Thanks for the response Emelia, my comments inline On Mon, Sep 29, 2025 at 7:28 PM Emelia S. <[email protected]<mailto:[email protected]>> wrote: Hi Dick, I've addressed the issue with redirects by prohibiting them in https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/pull/46 (I don't think there's a case where a Client ID Metadata Document URI being a redirect would be valid, since the document URI would likely not match the `client_id` value then) lgtm -- thanks Where in the document is it described what is passed in the authorization request? Is this not covered in Sections 3 and 4 by specifying it is a Client Identifier and the following: > The authorization server SHOULD fetch the document indicated by the client_id > to retrieve the client registration information. Perhaps we could add in there the words "fetch the document indicated by the client_id during the authorization request", though a concern here is that this may limit compatibility with PARs and similar flows that aren't just the usual authorization endpoint flow. You don't need normative language on exactly how the AS received the client_id -- perhaps: When the AS receives a client_id either through an authorization request, a pushed authorization request, or similar flow, the AS fetches the document indicated by the client_id if it is not available in cache. Something to help the reader tie together how the client_id was acquired and that it is the value of the client_id parameter (and not client_uri) that is being used to fetch the document There is actually no relationship between `client_id` and `client_uri` though an AS may choose to impose restrictions or a relationship here for added security (e.g., an AS could request the `client_uri` and assert that it links back to the `client_id` document via link relations). The `client_uri` is the website of the Client, which may be the client itself, or may just be an informational website about the client. Perhaps rename the title of 6.1 Authorization Server Restrictions on client_id, client_uri, and redirect_uri Values _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
