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

[Orie Steele <[e-mail]>]

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.

That is already covered in
https://datatracker.ietf.org/doc/html/rfc8615#section-3

See webfinger for an example of an RFC that supports well known URIs that
contain queries:

https://www.rfc-editor.org/rfc/rfc7033.html#section-3.1

I suppose this represents another interesting edge case, how do you handle
a https resource identifier which is already a well known URI, such as
webfinger?

I assume:

   GET /.well-known/webfinger?
            resource=acct%3Acarol%40example.com&
            rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
            HTTP/1.1
     Host: example.com

Becomes:

    GET /.well-known/oauth-protected-resource/.well-known/webfinger?
            resource=acct%3Acarol%40example.com&
            rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
            HTTP/1.1
     Host: example.com

Thanks for addressing my comments.

Regards,

OS

On Tue, Oct 1, 2024 at 11:15 PM Michael Jones <[e-mail]>
wrote:

> Hi Orie,
>
> Per our discussion, I've created
> https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/59,
> which is intended to satisfy your DISCUSS by allowing resource identifiers
> to contain query parameters.  It also applies the other changes that I
> agreed to below.
>
> My apologies that the PR is also somewhat littered with language changes
> to consistently use the term "metadata parameter" instead of other terms
> that were sometimes used for the same thing.
>
> Please let me know if you'd like any changes before it's merged.
>
>                                 Thanks again,
>                                 -- Mike
>
> -----Original Message-----
> From: Michael Jones
> Sent: Tuesday, October 1, 2024 3:49 PM
> To: Orie Steele <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Orie Steele's Discuss on
> draft-ietf-oauth-resource-metadata-10: (with DISCUSS and COMMENT)
>
> Hi Orie,
>
> Thanks for your review.  My replies are inline below, prefixed by "Mike>".
>
> -----Original Message-----
> From: Orie Steele via Datatracker <[e-mail]>
> Sent: Tuesday, October 1, 2024 12:11 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Orie Steele's Discuss on draft-ietf-oauth-resource-metadata-10:
> (with DISCUSS and COMMENT)
>
> Orie Steele has entered the following ballot position for
> draft-ietf-oauth-resource-metadata-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to
> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/
> for more information about how to handle DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ## Discuss
>
> ### Forbidden Query & Fragment
>
> ```
> 175           The Protected resource's resource identifier, which is a URL
> that
> 176           uses the https scheme and has no query or fragment
> components.
> ```
>
> I can understand the decision to keep fragment off, per:
>
> https://url.spec.whatwg.org/#url-equivalence
>
> But I don't understand why query is forbidden, especially considering:
>
> https://datatracker.ietf.org/doc/html/rfc3986#section-3.4
>
> I would expect query to be allowed, and for some comment about canonical
> URI encoding based on query ordering to be made.
>
> I assume query is omitted to make processing rules described in Section 3
> simpler... This also restricts the set of existing resources which this
> specification could apply to... and implies that resource identifiers that
> are URLs do not contain queries.
>
> It seems like a specification should be able to describe transformation
> rules that use query or hostname rewriting, even if the current spec sees
> no need to use query or hostname structures, why should other
> specifications be forbidden from doing so?
>
> For an example:
>
> https://example.com/oauth-protected-resource
> https://example.com/.well-known/oauth-protected-resource
>
> vs
>
> https://oauth-protected.example.com/.well-known/fancy-index?key=value
> https://example.com/.well-known/oauth-protected?key=value...
>
> I searched github and the mailing list to see if there was discussion
> regarding this, please point it out if I somehow missed it.
>
> Mike> I know of no examples of .well-known URIs being combined with query
> parameters in practice.  That seems like a theoretical possibility that's
> best avoided for complexity reasons in the real world.  The same
> restriction in the sister specification RFC 8414 has stood up well in
> practice.  https://www.rfc-editor.org/rfc/rfc8414.html#section-2
> prohibits query parameters in issuer identifier.  I'm reluctant to diverge
> from this OAuth identifier precedent without a compelling reason to do so.
>
> Mike> For completeness, yes,
> https://www.rfc-editor.org/rfc/rfc8615#section-3 does say that
> "Registrations MAY also contain additional information, such as the syntax
> of additional path components, query strings, and/or fragment identifiers
> to be appended to the well-known URI, or protocol- specific details".
> However, the general treatment of query parameters with .well-known URIs
> you're asking about wouldn't result in a registration defining the syntax
> of specific query strings.  Rather, it would require a .well-known
> registration allowing *any* query parameters, which seems beyond the scope
> for what was intended in RFC 8615.
>
> Mike> For these reasons, I'd ask that you please withdraw your DISCUSS on
> this basis.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Orie Steele, ART AD, comments for draft-ietf-oauth-resource-metadata-10
> CC @OR13
>
> * line numbers:
>   -
>
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-10.txt&submitcheck=True
>
> * comment syntax:
>   - https://github.com/mnot/ietf-comments/blob/main/format.md
>
> * "Handling Ballot Positions":
>   -
> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
> ## Comments
>
> Thanks to Arnt Gulbrandsen for the ART ART review.
>
> ### JSON Serialization Forbidden?
>
> ```
> 158        Compact Serialization or the JWE Compact Serialization; the JWS
> JSON
> 159        Serialization and the JWE JSON Serialization are not used.
> ```
>
> This is descriptive, but I wonder if there is an intention to enable
> better interoperability by explicitly forbidding JSON Serialization.
>
> Mike> This is the same language as in
> https://www.rfc-editor.org/rfc/rfc8414.html#section-1.1.  Yes, the intent
> is to facilitate interoperability by making choices.  Let us know if you'd
> like us to say that explicitly, going beyond the parallel RFC 8414 language.
>
> ### signed_metadata in JWT claims
>
> ```
> 346           JWT.  A signed_metadata metadata value SHOULD NOT appear as a
> 347           claim in the JWT.
> ```
>
> When this should is ignored what happens? Raise and error or ignore?
>
> Mike> Roman raised the same question.  Text is added in
> https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/58 to
> answer it.  The addition recommends rejecting the metadata when this occurs.
>
> ### media type of response
>
> ```
> 425        configuration.  A successful response MUST use the 200 OK HTTP
> status
> 426        code and return a JSON object using the application/json
> content type
> 427        that contains a set of claims as its members that are a subset
> of the
> 428        metadata values defined in Section 2.  Other claims MAY also be
> 429        returned.
> ```
>
> Based on the last sentence, it seems like the metadata resource is
> intended to be extended, should it be possible to negotiate its extended
> representations?
>
> Mike> This is the standard OAuth extensibility mechanism that has stood
> the test of time by enabling non-breaking extensibility.  The pattern is
> that additional parameter values MAY be used and MUST be ignored if not
> understood.  That means that when a new extension is deployed by one party
> it doesn't break deployments of other parties that it interacts with that
> don't understand the extension.  It's just ignored.
>
> Mike> Imagine the opposite behavior where not-understood parameters cause
> an error.  That would mean that any extension using a new parameter would
> break deployments.  That means no OpenID Connect, FAPI, PKCE, or RAR on top
> of OAuth.  Allowing non-breaking extensions is essential.
>
> Mike> https://www.rfc-editor.org/rfc/rfc8414.html#section-3.2 also uses
> exactly the same language.  That said, I'd be glad to expand the exposition
> to say that not-understood metadata parameters MUST be ignored.
>
> Why restrict the media type to "application/json" ?
>
> Mike> This is the same media type as used for other OAuth metadata data
> structures, for instance, it is used in
> https://www.rfc-editor.org/rfc/rfc8414.html#section-3.2 and
> https://www.rfc-editor.org/rfc/rfc7591.html#section-3.2.  It makes sense
> to do the same here.
>
> ### Identical URIs
>
> ```
> 460        metadata.  If these values are not identical, the data
> contained in
> 461        the response MUST NOT be used.
> ```
>
> Consider being more precise regarding what "identical" means here, see the
> URL equivalence section of WHATWG URL spec for example:
>
> https://url.spec.whatwg.org/#url-equivalence
>
> I also wonder if URL patterns are useful here...
>
> https://urlpattern.spec.whatwg.org/
>
> You might also consider calling out Section 6 here.
>
> Mike> This is the same language as used in
> https://www.rfc-editor.org/rfc/rfc8414.html#section-3.3.  I'm truly
> reluctant to introduce the notion of requiring URL canonicalization, as is
> implied by https://url.spec.whatwg.org/#url-equivalence.  No harm is done
> when rejecting values that are not byte-for-byte equivalent.  To me, the
> existing OAuth language is already sufficient.
>
> ## Nits
>
> ### Missing owner?
>
> ```
> 627        At any point, for any reason determined by the protected
> resource,
> 628        the protected resource MAY respond with a new WWW-Authenticate
> ```
>
> Mike> Actually, I think it would be better to change "protected resource"
> to "resource server" rather than "protected resource owner".  The resource
> owner is unlikely to be involved.
>
> Thanks for your useful review!
>
>                                 -- Mike
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>