[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 ```
- [OAUTH-WG] Orie Steele's Discuss on draft-ietf-oa… Orie Steele via Datatracker
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Michael Jones
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Michael Jones
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Orie Steele
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… David Waite
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… Orie Steele
- [OAUTH-WG] Re: Orie Steele's Discuss on draft-iet… David Waite