> On Oct 2, 2024, at 11:38 AM, Orie Steele <orie@transmute.industries> wrote: > > Hi Mike, > > Your PR looks good to me. > > My objection is limited to defining http based resource identifiers as "URIs" > that do not contain query, because this contradicts the common interpretation > of http resource identifiers which includes: > > The query component contains non-hierarchical data that, along with > data in the path component (Section 3.3), serves to identify a > resource within the scope of the URI's scheme and naming authority > (if any). > > https://datatracker.ietf.org/doc/html/rfc3986#section-3.4 > > I don't believe you need to describe in any detail how query parameters > interact with well known URIs.
The challenge of course is that there is no canonical representation of a query component, nor is the query component itself required to be in a particular format like query parameters. The various HTTP implementations _may_ restrict themselves to only support query parameters, and may further do so in a way that does not preserve the original escaping or ordering. The resource identifier is meant to be understood by the client, which often is not first party to the AS. This means that unlike Resource Parameters in RFC 8707, allowing query parameters but not answering the question on how such would be handled will have a stronger negative impact on interoperability. Conveying queries in a metadata request also adds the risk that it will share OAuth request information more broadly, e.g. if the well-known logic and the protected resource logic are separated responsibilities. I would propose that a resource identifier is the URI with query and fragment components _removed_, e.g. that all accepted query components amount to a collection with the same metadata. This clarifies that the spec does not attempt to restrict to only resource servers which do not use query components. Otherwise, the protected resource metadata request needs to be modified to include a query component, every possible query will be sent to this endpoint, and we probably should note the potential of sharing request information. -DW
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
