Hi David, I am clearing my discuss based on https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/59
For the sake of clarity, let's look at an example: http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick This would become: http://www.example.com/.well-known/oauth-protected-metadata/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick And would resolve to: HTTP/1.1 200 OK Content-Type: application/json { "resource": "http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick";, "authorization_servers": ["https://as1.example.com";, "https://as2.example.net";], "bearer_methods_supported": ["header", "body"], "scopes_supported": ["profile", "email", "phone"], "resource_documentation": "https://resource.example.com/resource_documentation.html"; } See also: - https://datatracker.ietf.org/doc/html/rfc7320#section-2.4 - https://datatracker.ietf.org/doc/html/rfc8820#name-uri-queries You might constrain the query for .well-known/oauth-protected-metadata (for example, you could forbid common oauth query params) ... but you cannot constrain the query for the original protected resource URLs, without limiting the applicability of your proposed standard... it's possible I am incorrectly interpreting RFC7320 and RFC8820, but the spirit of what I am trying to say is: Do not tell applications that their resource identifiers that use query parameters are not resource identifiers. It's fine to warn them of the consequences of their design decisions on deploying oauth-protected-metadata, which you are already doing with the "SHOULD NOT" in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-11#section-1.2-3.2 . Regards, OS On Wed, Oct 2, 2024 at 1:27 PM David Waite <da...@alkaline-solutions.com> wrote: > > > 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 > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
