[OAUTH-WG] Re: Orie Steele's Discuss on draft-ietf-oauth-resource-metadata-10: (with DISCUSS and COMMENT)

[David Waite <[e-mail]>]

This looks acceptable to me as well

-DW

> On Oct 2, 2024, at 3:49 PM, Orie Steele <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On Oct 2, 2024, at 11:38 AM, Orie Steele <[e-mail]> 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/>