I volunteered to review the OAuth 2.0 Protected Resource Metadata (https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html) at the IETF 119 meeting.
First, I would like to thank the authors, Mike, Phil and Aaron, for creating this draft. It solves an important problem and I believe this will find wide adoption. We are already referencing it in the OAuth Identity and Authorization Chaining Across Domains (https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/01/) draft for example. Below are my comments, feedback, questions and the occasional suggestion. I tried to scrub items that were already brought up elsewhere in this thread, but may have missed one or two. Once again thanks for doing this important work. Section 2 1. jwks_uri - The text only requires the "public key use" parameter if both signing and encryption keys are included. It was not clear to me what the assumed usage is if only a single key type is present (are they assumed to all be signing keys or all encryption keys). To avoid any possible confusion, why not make the "public key use" parameter mandatory even when only encryption or signature keys are included. 2. bearer_methods_supported - Reading the parameter name created a different expectation and only after reading the text was it clear that this was about the way in which the bearer token is presented, rather than different types or formats of tokens. Consider renaming this parameter to be a bit more descriptive. For example bearer_presentation_methods. 3. resource_signing_alg_values_supported - I was unsure whether this parameter was meant to describe signatures types that the resource server could verify, or whether this was for signature types it could generate (and presumably held keys for signature generation). * Does it cover algorithms for both verification and generation? * Given that this is an optional value, is it necessary to allow the value of "none". If no signing algorithms are supported, is a better approach to just not include this parameter (I reflect on security issues that may arise from alg:none type parameters)? If it has to be included, are there security considerations that can be called out regarding this parameter set to none? 1. Parameter names suggest URIs (jwks_uri, resource_policy_uri, resource_tos_uri), but the description always scopes this down to URLs. I suspect there is some history behind these parameter name choices, but was curious if there are ever a case when the parameter value is expected to not be a URL? If this parameter value is always a URL, should the parameter name be changes to reflect this (again, I suspect there are reasons for the current choices, but curious about the inconsistency)? Section 3 1. I found paragraphs 1-3 of this section hard to parse. I think the intent here is to say that an application may be composed of different protected resources, and each of those may have their own protected resource metadata and then specify how that might be done. * Although paragraph 2 describes the way to do it, and illustrates it with an example, it does not show the final result of such a construction. Would it be possible to include the final result of what the path would look like when inserting the "/.well-known/example-protected-resource" between the host and path components of the protected resource's resource identifier just to remove opportunity for misinterpretation (is this the same as the second example given in Section 3.1, if so, perhaps refer to that example)? 1. I was unsure how to interpret this sentence in paragraph 3: "An OAuth 2.0 application using this specification MUST specify what well-known URI string it will use for this purpose." * Is this meant to refer to the IANA registration in paragraph 1, or is there some other specification mechanism an OAuth application should use that consumers of the metadata can use to determine where to find the resource metadata? * Is this related to the inclusion of the URL for the protected resource metadata as described in Section 5? 1. It looks like the validation rules in section 3.3 is intended as a mitigation for the attack described in section 7.3 (Impersonation Attacks). Perhaps add a sentence at the start of Section 3.3 to establish this connection for implementors less familiar with different types of attacks. For example: "The following validation rules mitigate against impersonation attacks described in section 7.3." Section 4 1. Consider changing the first sentence to make it clear that the "protected_resources" metadata value is used as part of the Authorization Server Metadata. * For example: "To support use cases in which the set of legitimate protected resources to use with the authorization server is fixed and enumerable, this specification defines the protected_resources metadata value, which enables the authorization server to explicitly list them as part of the authorization server metadata" Section 5 1. For step 5 in the end-to-end flow, add a reference to the validation steps described in Section 2.1 (validation of signed resource metadata if it applies) and Section 3.3 2. Representing this as fishbone diagram or flow-diagram showing the interaction between the three parties may be helpful, perhaps even earlier in the document, similar to other drafts. 3. Section 5.2: Perhaps rephrase the following sentence: "If the client receives such a WWW-Authenticate response, it is expected retrieve the protected resource metadata again, and SHOULD use the new metadata values obtained." as "If the client receives such a WWW-Authenticate response, it SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained." Section 6 1. I was unsure on how to interpret the reference to Section 8.3 in RFC 8259. The way it is written creates the impression that all three string validation rules in Section 6 is represented in section 8.3 of RFC 8259, but I could not find any reference to removal of JSON escaping or prohibitions on normalization. Section 8.3 seems to only refer to code point to code point comparison (the third validation rule). * Should the reference to RFC 8259 be limited to validation rule 3? * It may be helpful to adopt the same language RFC 8259. RFC 8529 talks about comparing code units, while the draft refers to code points. I assume they are the same, but perhaps just cleaner to use the same description if they are. Section 7 1. Section 7.3: Similar to an earlier comment, if these attacks, especially the attack in paragraph 2 is mitigated (fully or partially) by the validation rules in section 3.3, it may be good to reference back to that section. 2. Section 7.5: It is good to call out that the resource metadata could be used by an attacker (its information they did not have before), however the guidance to use "the same defenses against attacks that might be mounted that use this information should be applied" feels a bit vague. Is there a resource or a reference that describe those "same defenses"? 3. Section 7.6: The readability of this section may be improved by first stating clearly what use cases are supported (as described in paragraph 3) and then calling out that all other use cases are not supported and why (paragraph 1 and 2). 4. Section 7.8: Not sure if this falls under phishing or if there needs to be a separate section on malicious resource servers that uses resource metadata to direct users to an authorization server under their control in order to collect credentials (it is kind of hinted at, but not explicitly stated). Defences would be similar to those typically deployed against phishing sites as outlined in the last sentence of section 7.8 Cheers Pieter From: OAuth <oauth-boun...@ietf.org> On Behalf Of Rifaat Shekh-Yusef Sent: Wednesday, March 27, 2024 12:53 PM To: oauth <oauth@ietf.org> Subject: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata All, This is a WG Last Call for the OAuth 2.0 Protected Resource Metadata document. https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-resource-metadata-03.html&data=05%7C02%7Cpieter.kasselman%40microsoft.com%7C357b9c804c444b4a873d08dc4e5cfea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638471408549324339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l3qRXme8ywpfuSzOCxZR3VX5WbBzoLNqZJA9KrQ8r7I%3D&reserved=0> Please, review this document and reply on the mailing list if you have any comments or concerns, by April 12. Regards, Rifaat & Hannes
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
