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)
> 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. 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 in 6.1 we could add text like the following: > There is no formal relationship between the `client_id` and the `client_uri`, > however, the Authorization Server may impose a relationship between these two > URIs. Yours, Emelia > On 27 Sep 2025, at 17:01, Dick Hardt <[email protected]> wrote: > > Aaron / Emilia: > > Where in the document is it described what is passed in the authorization > request? I know this is about the metadata document, but it is not clear how > the AS gets the client_id -- is it the client_id or client_uri parameter? > > It seems the URL is the client_id as the metadata document must have > client_id be the URL, but then how is that related to the client_uri which is > mentioned in 6.1? > > I would have expected this section: > > 6.1 Relationship between redirect_uris and client_id or client_uri > > to explain how these are related, but it only describes how the AS may > constrain them. > > Separate point: when fetching the URL, are redirects allowed? > > /Dick > > > On Sat, Sep 27, 2025 at 3:42 PM Dick Hardt <[email protected] > <mailto:[email protected]>> wrote: >> I support adoption of this draft. >> >> On Mon, Sep 22, 2025 at 8:14 PM Rifaat Shekh-Yusef via Datatracker >> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Subject: Call for adoption: >>> draft-parecki-oauth-client-id-metadata-document-03 (Ends 2025-10-06) >>> >>> This message starts a 2-week Call for Adoption for this document. >>> >>> Abstract: >>> This specification defines a mechanism through which an OAuth client >>> can identify itself to authorization servers, without prior dynamic >>> client registration or other existing registration. This is through >>> the usage of a URL as a client_id in an OAuth flow, where the URL >>> refers to a document containing the necessary client metadata, >>> enabling the authorization server to fetch the metadata about the >>> client as needed. >>> >>> File can be retrieved from: >>> https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/ >>> >>> Please reply to this message keeping [email protected] <mailto:[email protected]> >>> in copy by indicating >>> whether you support or not the adoption of this draft as a WG document. >>> Comments to motivate your preference are highly appreciated. >>> >>> Authors, and WG participants in general, are reminded of the Intellectual >>> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. >>> Appropriate IPR disclosures required for full conformance with the >>> provisions >>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >>> Sanctions available for application to violators of IETF IPR Policy can be >>> found at [3]. >>> >>> Thank you. >>> [1] https://datatracker.ietf.org/doc/bcp78/ >>> [2] https://datatracker.ietf.org/doc/bcp79/ >>> [3] https://datatracker.ietf.org/doc/rfc6701/ >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
