All, Hannes and I discussed the status of this document.
We believe that this document received significant feedback and a new updated document is needed. Because of that, after a new version is issued, we will start a *second WGCL* on this document. Regards, Rifaat On Fri, Apr 5, 2024 at 7:50 AM Pieter Kasselman < pieter.kassel...@microsoft.com> wrote: > 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). > > > 1. Does it cover algorithms for both verification and generation? > 2. 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? > > > 4. 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. > > > 1. 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)? > > > 2. 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." > > > 1. 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? > 2. Is this related to the inclusion of the URL for the protected > resource metadata as described in Section 5? > > > 3. 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. > > > 1. 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). > > > 1. Should the reference to RFC 8259 be limited to validation rule 3? > 2. 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
