This looks acceptable to me as well -DW
> On Oct 2, 2024, at 3:49 PM, Orie Steele <[email protected]> wrote: > > 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://as1.example.com/>", > "https://as2.example.net <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 <[email protected] > <mailto:[email protected]>> wrote: >> >> >>> On Oct 2, 2024, at 11:38 AM, Orie Steele <[email protected]> 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 <http://www.transmute.industries/> > <https://transmute.industries/>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
