Thanks for your review, Mike. My replies are inline below, prefixed by "mbj>".
The proposed resolutions below are incorporated in https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/57. Please let me know if you'd like to see any changes before we apply them. -----Original Message----- From: Mike Bishop via Datatracker <nore...@ietf.org> Sent: Friday, September 27, 2024 11:33 AM To: ietf-http...@w3.org Cc: draft-ietf-oauth-resource-metadata....@ietf.org; last-c...@ietf.org; oauth@ietf.org Subject: Httpdir telechat review of draft-ietf-oauth-resource-metadata-10 Reviewer: Mike Bishop Review result: Ready with Issues I have only a passing familiarity with the details of OAuth, so some of my questions may be born out of ignorance there. However, I think I understand the general use case for this protocol. The structure itself seems sound -- for any given application URL, there is a defined 1:1 mapping to a metadata URL from which a client can retrieve information about the application. This information includes which authorization server(s) the client could use to retrieve an acceptable authentication token, and by extension retrieve the authorization servers' metadata. I have a few questions, which may or may not warrant changes to the document: It was not entirely clear to me how the client maps an arbitrary URL which may be handled by an application (e.g. https://example.com/library/foo) to the resource identifier URL of the application itself. (This may be handled by the extension of the WWW-Authenticate header, which I have a separate question about later.) mbj> The resource identifier URL *is* the protected resource URL. This is the same URL as used in the "resource=" parameter in the Resource Indicators specification [RFC 8707]. Section 3 describes both a default well-known suffix and describes the possibility of other suffixes as well. I found this confusing on a first read; it might be clearer to simply describe the format and where it is published by default. Application-specific suffixes can state in their registering specification that the same format is to be used; the possibility can be mentioned here as an aside. mbj> The language describing the default suffix and the possibility of application-specific suffixes is intentionally exactly parallel to that in https://www.rfc-editor.org/rfc/rfc8414.html#section-3, which does the same thing for the same reasons. I'd therefore prefer to keep the structure of the exposition the same, if that works for you. Section 3.1 says that the metadata does not provide "general information about the host", which seems potentially incorrect if the path is empty. mbj> This language is also directly parallel to language at https://www.rfc-editor.org/rfc/rfc8414.html#section-3.1. This paragraph is about "Using path components", so the path would not be empty. Section 3.3 is the first mention of the WWW-Authenticate use case; there's no forward reference to Section 5 or mention of it in the introduction. mbj> Good point. I'll plan to add a forward reference to it in the Introduction. I'm thinking something like: "Section 5 describes the use of WWW-Authenticate by protected resources to dynamically inform clients of the URL of their protected resource metadata. This use of WWW-Authenticate indicates that the protected resource metadata MAY have changed." Section 5 defines a way for a WWW-Authenticate header to point to the application's metadata. There appear to be no requirements on where this URL can point. Must it be on the same server? Must it use HTTPS? (The client is required to validate the server certificate, so probably.) Must it be under .well-known or can it be an arbitrary path? mbj> As defined in Section 3, the default location for this metadata is the .well-known path formed from the resource URL and .well-known/oauth-protected-resource. But as you point out, a different URL can be used by the resource. This is enabled by the working group's choice to return the metadata URL directly, rather than the resource identifier. The location cannot be chosen by an attacker because the WWW-Authenticate value cannot be chosen by an attacker. Validation that the metadata is for the correct resource is performed as described in Section 3.3. Throughout Section 5, WWW-Authenticate is referred to as a response. I understand the shorthand, but it's actually a header field which can be included in a response. A reference to Section 3 of RFC6750 might also be useful here, beyond the general reference to the RFC. mbj> Because of your comment, I realized that we failed to cite the definition of WWW-Authenticate in RFC 9110. I'll plan to do that. And I'll describe it as a WWW-Authenticate response header field. Thanks. (I'm a little unclear when the server returns a 401 with WWW-Authenticate versus a 3XX to the authorization server, but that's an OAuth question not specific to this document.) mbj> The use of 401 (Unauthorized) is specified by https://www.rfc-editor.org/rfc/rfc9110#section-11.6.1. Thanks for your useful review! -- Mike _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
