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 <orie@transmute.industries>; The IESG <i...@ietf.org>
Cc: draft-ietf-oauth-resource-metad...@ietf.org; oauth-cha...@ietf.org;
oauth@ietf.org; rifaat.s.i...@gmail.com
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 <nore...@ietf.org>
Sent: Tuesday, October 1, 2024 12:11 PM
To: The IESG <i...@ietf.org>
Cc: draft-ietf-oauth-resource-metad...@ietf.org; oauth-cha...@ietf.org;
oauth@ietf.org; rifaat.s.i...@gmail.com; rifaat.s.i...@gmail.com
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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
