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

Orie Steele via Datatracker <noreply@ietf.org> Tue, 01 October 2024 19:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from [10.244.8.155] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 603BBC151997; Tue, 1 Oct 2024 12:11:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Orie Steele via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172780986106.795146.3754827883737941273@dt-datatracker-7bbd96684-zjf54>
Date: Tue, 01 Oct 2024 12:11:01 -0700
Message-ID-Hash: W72J7CMBWTVF5MA2WN6YKXDQVHPD76XZ
X-Message-ID-Hash: W72J7CMBWTVF5MA2WN6YKXDQVHPD76XZ
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-oauth-resource-metadata@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Orie Steele <orie@transmute.industries>
Subject: [OAUTH-WG] Orie Steele's Discuss on draft-ietf-oauth-resource-metadata-10: (with DISCUSS and COMMENT)
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/b1RfMU1_jBqc1sLCmmVUYbQiiYs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
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.


----------------------------------------------------------------------
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.

### 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?

### 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?

Why restrict the media type to "application/json" ?

### 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.

## 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
```