Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-04.html has been published addressing the WGLC feedback received. Thanks all for the thorough reviews! Rifaat and/or Hannes, can you please start the second WGLC at your convenience? Thanks, -- Mike From: OAuth On Behalf Of Rifaat Shekh-Yusef Sent: Monday, April 22, 2024 7:55 AM To: Pieter Kasselman Cc: oauth Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata 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 mailto: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). * 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 cons
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Hi Pieter, As you know, Aaron and I worked through your comments, filing issues at https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/ and creating PRs addressing them. Thanks for your engagement via the issue tracker as we worked through the issues. https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-04.html has been published incorporating those resolutions. Per our in-person conversation at the OAuth Security Workshop, Aaron and I tried to strike a balance between keeping the text as consistent with RFC 8414 as possible, while also incorporating clarifications and wording improvements suggested. Thanks again for your detailed review! It improved the specification. -- Mike & Aaron From: OAuth On Behalf Of Pieter Kasselman Sent: Friday, April 5, 2024 4:51 AM To: rifaat.s.ietf ; oauth Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata 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 us
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Hi Vladimir and Brian, https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-04.html clarifies the purpose of resource_signing_alg_values_supported, as requested. It also removes resource_encryption_alg_values_supported and resource_encryption_enc_values_supported, since there wasn’t an immediate need for them. They, or similar parameters, can always be registered by another specification when there is a need for them. Thanks again for your thoughtful reviews. -- Mike & Aaron From: Brian Campbell Sent: Thursday, April 4, 2024 2:42 PM To: Michael Jones Cc: Vladimir Dzhuvinov ; oauth@ietf.org Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata Apologies, I just noticed an unfinished sentence in my prior message (embarrassing but I guess I started to write it and then changed my mind but neglected to remove it). Anyway, "And FWIW the jwks_uri metadata parameter seems well en" should have been deleted or just gone on to say something like that jwks_uri metadata parameter seems well enough defined and isn't being questioned in this thread anyway so needn't be defended or explained. On Wed, Apr 3, 2024 at 3:00 PM Brian Campbell mailto:bcampb...@pingidentity.com>> wrote: On Wed, Apr 3, 2024 at 9:52 AM Michael Jones mailto:michael_b_jo...@hotmail.com>> wrote: In October 2023, we added this text describing signing resource responses: These values may be used by other specifications, such as the jwks_uri used to publish public keys the resource server uses to sign resource responses, as described in Section 5.6.2 of [FAPI.MessageSigning<https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#FAPI.MessageSigning>]. This uses the jwks_uri and resource_signing_alg_values_supported metadata parameters. That text about signing resource responses only uses the jwks_uri metadata parameter. And FWIW the jwks_uri metadata parameter seems well en How resource_signing_alg_values_supported comes into play is maybe implied but is not stated anywhere. Would it list the algs the RS can sign with (which would be largely redundant info from what can be learned at the jwks_uri)? Or the algs the RS can accept? And if that, for access tokens or signed requests or both or something else? All the draft says is "for signed content" and content could mean many things. In fact, Vladimir's question that started this discussion was about how to interpret "content". Sorry, I'm not trying to be difficult or dense here but honestly asking questions that aren't addressed in the current draft text. Admittedly, we’re not describing use cases for resource_encryption_alg_values_supported and resource_encryption_enc_values_supported at present. If people feel strongly about it, I’d be willing to remove the encryption parameters since they’re more speculative, but I believe there’s a solid use case for the key set and supported signing algorithms. What do others think? I'm not necessarily arguing for removal at this point but I think the three *_values_supported parameters need additional definition or clarification for them to be useful in a meaningful or interoperability improving way. Absent that though, I guess I would argue for their removal. -- Mike From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Brian Campbell Sent: Tuesday, April 2, 2024 2:45 PM To: Vladimir Dzhuvinov mailto:vladi...@connect2id.com>> Cc: oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata I've had questions similar to Vladimir's* and do still think that some additional context or clarification or something in the document would be helpful. * https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov mailto:vladi...@connect2id.com>> wrote: I have a question about the parameters: resource_signing_alg_values_supported, resource_encryption_alg_values_supported, resource_encryption_enc_values_supported. I'm not sure how to interpret "content". Where the algorithms, if advertised, get to apply. Is this something that resources / applications will define, depending on the resource characteristics? If we take JWE for instance, it could be used for 3 things at least. To encrypt bearer JWTs to access the resource, in addition to encrypting request and response payloads. Vladimir On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: 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 Please, review this document and reply on the mailing list if you have any comments or concerns, by April 12. Regar
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
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 *On Behalf Of *Rifaat Shekh-Yusef > *Sent:* Wednesday, March 27, 2024 12:53 PM > *To:* oauth > *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=05%7C02%7Cpieter.kasselman%40microsoft.com%7C357b9c804c444b4a873d08dc4e5cfea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638471408549324339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=l3qRXme8ywpfuSzOCxZR3VX5WbBzoLNqZJA9KrQ8r7I%3D=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
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
, 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 On Behalf Of Rifaat Shekh-Yusef Sent: Wednesday, March 27, 2024 12:53 PM To: oauth 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=05%7C02%7Cpieter.kasselman%40microsoft.com%7C357b9c804c444b4a873d08dc4e5cfea1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638471408549324339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=l3qRXme8ywpfuSzOCxZR3VX5WbBzoLNqZJA9KrQ8r7I%3D=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
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Apologies, I just noticed an unfinished sentence in my prior message (embarrassing but I guess I started to write it and then changed my mind but neglected to remove it). Anyway, "And FWIW the jwks_uri metadata parameter seems well en" should have been deleted or just gone on to say something like that jwks_uri metadata parameter seems well enough defined and isn't being questioned in this thread anyway so needn't be defended or explained. On Wed, Apr 3, 2024 at 3:00 PM Brian Campbell wrote: > > > On Wed, Apr 3, 2024 at 9:52 AM Michael Jones > wrote: > >> In October 2023, we added this text describing signing resource responses: >> >> >> >> These values may be used by other specifications, such as the jwks_uri used >> to publish public keys the resource server uses to sign resource responses, >> as described in Section 5.6.2 of [FAPI.MessageSigning >> <https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#FAPI.MessageSigning> >> ]. >> >> >> >> This uses the jwks_uri and resource_signing_alg_values_supported metadata >> parameters. >> > > That text about signing resource responses only uses the jwks_uri metadata > parameter. And FWIW the jwks_uri metadata parameter seems well en > > How resource_signing_alg_values_supported comes into play is maybe implied > but is not stated anywhere. Would it list the algs the RS can sign with > (which would be largely redundant info from what can be learned at the > jwks_uri)? Or the algs the RS can accept? And if that, for access tokens or > signed requests or both or something else? All the draft says is "for > signed content" and content could mean many things. In fact, Vladimir's > question that started this discussion was about how to interpret "content". > > Sorry, I'm not trying to be difficult or dense here but honestly asking > questions that aren't addressed in the current draft text. > > > >> Admittedly, we’re not describing use cases for >> resource_encryption_alg_values_supported and >> resource_encryption_enc_values_supported at present. If people feel >> strongly about it, I’d be willing to remove the encryption parameters since >> they’re more speculative, but I believe there’s a solid use case for the >> key set and supported signing algorithms. >> >> >> >> What do others think? >> > > I'm not necessarily arguing for removal at this point but I think the > three *_values_supported parameters need additional definition or > clarification for them to be useful in a meaningful or interoperability > improving way. Absent that though, I guess I would argue for their removal. > > > >> >> -- Mike >> >> >> >> *From:* OAuth *On Behalf Of *Brian Campbell >> *Sent:* Tuesday, April 2, 2024 2:45 PM >> *To:* Vladimir Dzhuvinov >> *Cc:* oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata >> >> >> >> I've had questions similar to Vladimir's* and do still think that some >> additional context or clarification or something in the document would be >> helpful. >> >> >> >> * >> https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ >> >> >> >> On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov < >> vladi...@connect2id.com> wrote: >> >> I have a question about the parameters: >> resource_signing_alg_values_supported, >> resource_encryption_alg_values_supported, >> resource_encryption_enc_values_supported. >> >> I'm not sure how to interpret "content". Where the algorithms, if >> advertised, get to apply. Is this something that resources / applications >> will define, depending on the resource characteristics? If we take JWE for >> instance, it could be used for 3 things at least. To encrypt bearer JWTs to >> access the resource, in addition to encrypting request and response >> payloads. >> >> Vladimir >> >> On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: >> >> 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 >> >> Please, review this document and reply on the mailing list if you have >> any comments or concerns, by *April 12*. >> >> Regards, >> Rifaat & Hannes >> >> >> >> ___
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
On Wed, Apr 3, 2024 at 9:52 AM Michael Jones wrote: > In October 2023, we added this text describing signing resource responses: > > > > These values may be used by other specifications, such as the jwks_uri used > to publish public keys the resource server uses to sign resource responses, > as described in Section 5.6.2 of [FAPI.MessageSigning > <https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#FAPI.MessageSigning> > ]. > > > > This uses the jwks_uri and resource_signing_alg_values_supported metadata > parameters. > That text about signing resource responses only uses the jwks_uri metadata parameter. And FWIW the jwks_uri metadata parameter seems well en How resource_signing_alg_values_supported comes into play is maybe implied but is not stated anywhere. Would it list the algs the RS can sign with (which would be largely redundant info from what can be learned at the jwks_uri)? Or the algs the RS can accept? And if that, for access tokens or signed requests or both or something else? All the draft says is "for signed content" and content could mean many things. In fact, Vladimir's question that started this discussion was about how to interpret "content". Sorry, I'm not trying to be difficult or dense here but honestly asking questions that aren't addressed in the current draft text. > Admittedly, we’re not describing use cases for > resource_encryption_alg_values_supported and > resource_encryption_enc_values_supported at present. If people feel > strongly about it, I’d be willing to remove the encryption parameters since > they’re more speculative, but I believe there’s a solid use case for the > key set and supported signing algorithms. > > > > What do others think? > I'm not necessarily arguing for removal at this point but I think the three *_values_supported parameters need additional definition or clarification for them to be useful in a meaningful or interoperability improving way. Absent that though, I guess I would argue for their removal. > > -- Mike > > > > *From:* OAuth *On Behalf Of *Brian Campbell > *Sent:* Tuesday, April 2, 2024 2:45 PM > *To:* Vladimir Dzhuvinov > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata > > > > I've had questions similar to Vladimir's* and do still think that some > additional context or clarification or something in the document would be > helpful. > > > > * https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ > > > > On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov < > vladi...@connect2id.com> wrote: > > I have a question about the parameters: > resource_signing_alg_values_supported, > resource_encryption_alg_values_supported, > resource_encryption_enc_values_supported. > > I'm not sure how to interpret "content". Where the algorithms, if > advertised, get to apply. Is this something that resources / applications > will define, depending on the resource characteristics? If we take JWE for > instance, it could be used for 3 things at least. To encrypt bearer JWTs to > access the resource, in addition to encrypting request and response > payloads. > > Vladimir > > On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: > > 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 > > 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 > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
In October 2023, we added this text describing signing resource responses: These values may be used by other specifications, such as the jwks_uri used to publish public keys the resource server uses to sign resource responses, as described in Section 5.6.2 of [FAPI.MessageSigning<https://drafts.oauth.net/draft-ietf-oauth-resource-metadata/draft-ietf-oauth-resource-metadata.html#FAPI.MessageSigning>]. This uses the jwks_uri and resource_signing_alg_values_supported metadata parameters. Admittedly, we’re not describing use cases for resource_encryption_alg_values_supported and resource_encryption_enc_values_supported at present. If people feel strongly about it, I’d be willing to remove the encryption parameters since they’re more speculative, but I believe there’s a solid use case for the key set and supported signing algorithms. What do others think? -- Mike From: OAuth On Behalf Of Brian Campbell Sent: Tuesday, April 2, 2024 2:45 PM To: Vladimir Dzhuvinov Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata I've had questions similar to Vladimir's* and do still think that some additional context or clarification or something in the document would be helpful. * https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov mailto:vladi...@connect2id.com>> wrote: I have a question about the parameters: resource_signing_alg_values_supported, resource_encryption_alg_values_supported, resource_encryption_enc_values_supported. I'm not sure how to interpret "content". Where the algorithms, if advertised, get to apply. Is this something that resources / applications will define, depending on the resource characteristics? If we take JWE for instance, it could be used for 3 things at least. To encrypt bearer JWTs to access the resource, in addition to encrypting request and response payloads. Vladimir On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: 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 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
I've had questions similar to Vladimir's* and do still think that some additional context or clarification or something in the document would be helpful. * https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/ On Thu, Mar 28, 2024 at 2:57 PM Vladimir Dzhuvinov wrote: > I have a question about the parameters: > resource_signing_alg_values_supported, > resource_encryption_alg_values_supported, > resource_encryption_enc_values_supported. > > I'm not sure how to interpret "content". Where the algorithms, if > advertised, get to apply. Is this something that resources / applications > will define, depending on the resource characteristics? If we take JWE for > instance, it could be used for 3 things at least. To encrypt bearer JWTs to > access the resource, in addition to encrypting request and response > payloads. > > Vladimir > > On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: > > 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 > > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
On Fri, Mar 29, 2024 at 10:46 PM Michael Jones wrote: > Thanks again for the detailed review, Atul! I’ve updated the PR > accordingly. Responses are inline below… > > > > *From:* OAuth *On Behalf Of *Atul Tulshibagwale > *Sent:* Friday, March 29, 2024 6:31 PM > *To:* Rifaat Shekh-Yusef ; oauth > *Subject:* Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata > > > >6. Section 5.1: Does this introduce any IANA consideration? How would >we know if some other spec is not using "resource_metadata" in some other >way in the WWW-Authenticate response header? (Unlikely, but if there is a >way to reserve it, we should) > > The IANA registrations will occur once the spec has completed WGLC and > publication is requested. That said, I’m not aware of a registry for > WWW-Authenticate values. (If anyone is aware of such a registry, please > let me know and I’ll add a registration.) > To my knowledge (having looked into it some during working on RFCs 9449 & 9470) there's no registry for WWW-Authenticate auth-param values. You could potentially somewhat follow what Step Up did in https://www.rfc-editor.org/rfc/rfc9470.html#section-3 which was to say that the auth-param value being introduced is applicable only to OAuth related authentication schemes. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Thanks again for the detailed review, Atul! I’ve updated the PR accordingly. Responses are inline below… From: OAuth On Behalf Of Atul Tulshibagwale Sent: Friday, March 29, 2024 6:31 PM To: Rifaat Shekh-Yusef ; oauth Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata Continuing my review notes from section 3.2: 1. Section 3.2 paragraph 2 says "Claims that return multiple values are represented as JSON arrays." should this be "MUST be represented as JSON arrays"? "Are" is probably OK because it is a statement of fact, but since this spec will be used by implementers, "MUST be" is more prescriptive An IETF veteran explained to me a long time ago that declarative English sentences are just as normative as those using RFC 2119 terms such as MUST. In fact, it’s possible to write an RFC using none of them! And this is language also present in RFC 8414. 1. Section 3.2: Is there any ordering condition to multi-valued claims? I.e. A client MUST / SHOULD try to use the smallest indexed value of a multi-valued claim and if that is unsuccessful, then use the next smallest indexed value? I don't know if this matters. If not, should we clarify that clients MAY use any subset of values? The semantics of metadata values are specific to the metadata parameter definition. We would be overreaching to intrude into the semantics defined for the parameters. 1. Section 3.2 example: Not having "scopes_supported" in the example is a miss I think, although it does not affect the correctness of the document I’ve added scopes_supported to the example. Thanks for the suggestion. 1. Section 4 protected_resources: "would not be used" is ambiguous. Can we say "MUST NOT be present in the Authorization Server Metadata"? I’ve updated the language to “will not be present”. 1. Section 5. Step 4 should read "The resource server responds with..." Corrected 1. Section 5.1: Does this introduce any IANA consideration? How would we know if some other spec is not using "resource_metadata" in some other way in the WWW-Authenticate response header? (Unlikely, but if there is a way to reserve it, we should) The IANA registrations will occur once the spec has completed WGLC and publication is requested. That said, I’m not aware of a registry for WWW-Authenticate values. (If anyone is aware of such a registry, please let me know and I’ll add a registration.) 1. Section 5.2: "...it is expected retrieve..." has a typo, should be "expected to retrieve". The language can also be more normative: "...The client SHOULD retrieve..." Updated 1. Section 5.3: Do we need this section? The spec doesn't use "Client Identifier" anywhere, so the section may not be needed in this spec. It’s a fair question. But as I see it, this section goes to the heart of the use cases that Aaron brought to the table – where client has no prior knowledge about the resource server. Unless you believe that it’s incorrect in some way, it seems prudent to retain it. -- Review completed. Atul Thanks so much again, -- Mike On Wed, Mar 27, 2024 at 12:00 PM Atul Tulshibagwale mailto:a...@sgnl.ai>> wrote: Hi all, I'd committed to reviewing the draft at IETF 119, so here is my feedback up to section 3.1: 1. Section 1: The sentence "Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location rooted at the protect resource's URL, even when the resource server implements multiple protected resources." has two issues: * Typo: "protected resource's URL" instead of "protect resource's URL" * This contradicts the statement in section 3, which states the "well-known" should be inserted between the host and path components 1. Section 1: The sentence "The means by which the client obtains the location of the protected resource metadata document is out of scope" conflicts with Section 3, which says "Protected resources MUST make ... (it) available at a path ...". 2. Section 2, "authorization_servers": since this is normative language, instead of saying "Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used.", should we say "the list of OAuth authorization servers MAY be a subset of the authorization servers supported by the protected resource." 3. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit confusing. Should it say something like "If not using the default well-known URI, suc
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Continuing my review notes from section 3.2: 1. Section 3.2 paragraph 2 says "Claims that return multiple values are represented as JSON arrays." should this be "MUST be represented as JSON arrays"? "Are" is probably OK because it is a statement of fact, but since this spec will be used by implementers, "MUST be" is more prescriptive 2. Section 3.2: Is there any ordering condition to multi-valued claims? I.e. A client MUST / SHOULD try to use the smallest indexed value of a multi-valued claim and if that is unsuccessful, then use the next smallest indexed value? I don't know if this matters. If not, should we clarify that clients MAY use any subset of values? 3. Section 3.2 example: Not having "scopes_supported" in the example is a miss I think, although it does not affect the correctness of the document 4. Section 4 protected_resources: "would not be used" is ambiguous. Can we say "MUST NOT be present in the Authorization Server Metadata"? 5. Section 5. Step 4 should read "The resource server responds with..." 6. Section 5.1: Does this introduce any IANA consideration? How would we know if some other spec is not using "resource_metadata" in some other way in the WWW-Authenticate response header? (Unlikely, but if there is a way to reserve it, we should) 7. Section 5.2: "...it is expected retrieve..." has a typo, should be "expected to retrieve". The language can also be more normative: "...The client SHOULD retrieve..." 8. Section 5.3: Do we need this section? The spec doesn't use "Client Identifier" anywhere, so the section may not be needed in this spec. -- Review completed. Atul On Wed, Mar 27, 2024 at 12:00 PM Atul Tulshibagwale wrote: > Hi all, > I'd committed to reviewing the draft at IETF 119, so here is my feedback > up to section 3.1: > >1. Section 1: The sentence "Each protected resource publishing >metadata about itself makes its own metadata document available at a >well-known location rooted at the protect resource's URL, even when the >resource server implements multiple protected resources." has two issues: > 1. Typo: "protected resource's URL" instead of "protect > resource's URL" > 2. This contradicts the statement in section 3, which states the > "well-known" should be inserted between the host and path components >2. Section 1: The sentence "The means by which the client obtains the >location of the protected resource metadata document is out of scope" >conflicts with Section 3, which says "Protected resources MUST make ... >(it) available at a path ...". >3. Section 2, "authorization_servers": since this is normative >language, instead of saying "Protected resources MAY choose not to >advertise some supported authorization servers even when this parameter is >used.", should we say "the list of OAuth authorization servers MAY be a >subset of the authorization servers supported by the protected resource." >4. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI >path suffix used MUST be registered in the IANA "Well-Known URIs" registry" >is a bit confusing. Should it say something like "If not using the default >well-known URI, such URI path suffix MUST be registered..." This last >sentence of paragraph 1 can actually be dropped, and the first sentence in >the 2nd paragraph can be updated to refer to the IANA well-known registry. >5. Section 3, paragraph 2: The first sentence should capitalize "MAY" >in "...application-specific ways may define and register..." >6. Section 3, paragraph 2: The first sentence can drop the word "used" >here: "...URI path suffixes used to publish..." The sentence will make more >sense with that word dropped. >7. Section 3, paragraph 2: The last sentence is additional >non-normative language, and could be removed, or could be moved to the >"IANA Considerations" section >8. Section 3, paragraph 3: "...specify what well-known URI string..." >should be changed to "...specify what well-known URI path-suffix..." >9. Section 3, paragraph 3: Instead of saying "...publish its metadata >at multiple well-known locations'', should we say "...publish its metadata >using multiple well-known path-suffixes''? >10. Section 3.1, last paragraph: The sentence "This is required in >some multi-tenant hosting configurations" may be removed as it is not the >only situation in which a host may have multiple OPRM documents. > > I will continue the review but I wanted to update the WG on my review so > far. > > Atul > > On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> 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 >> >> Please, review this document and reply on the
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Ciao Rifaat and everybody, In Italy, I've come across two national guidelines[1][2] that utilize OAuth 2.0 for protecting resources. These were implemented two years ago when the draft was still an individual draft and not as mature as it is today. Reflecting on the Italian implementation experience, the most significant insights can be distilled into two main points: 1. The core components outlined in the Italian guidelines remain consistent with those in the current OAuth specification, demonstrating that this specification was already consistent, durable and relevant. 2. Despite its status as an I-D at the time, the specification met our needs perfectly. It provided the necessary framework that, in its absence, would have likely led to the development of a similar solution. For these reasons, I am convinced that OAuth 2.0 for protected resources should be standardized. My gratitude goes out to the authors for their foundational work and to everyone involved for their valuable revisions. Regards, Giuseppe De Marco [1] https://italia.github.io/spid-cie-oidc-docs/en/metadata_aa.html [2] https://www.agid.gov.it/sites/default/files/repository_files/llgg_attribute_authorities_0.pdf Il giorno mer 27 mar 2024 alle ore 13:54 Rifaat Shekh-Yusef < rifaat.s.i...@gmail.com> ha scritto: > 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 > > 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
I have a question about the parameters: resource_signing_alg_values_supported, resource_encryption_alg_values_supported, resource_encryption_enc_values_supported. I'm not sure how to interpret "content". Where the algorithms, if advertised, get to apply. Is this something that resources / applications will define, depending on the resource characteristics? If we take JWE for instance, it could be used for 3 things at least. To encrypt bearer JWTs to access the resource, in addition to encrypting request and response payloads. Vladimir On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote: 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 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 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Hi Atul, I’ve created https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/23 addressing many of your comments. Dispositions of all the comments are described inline below. Thanks again, -- Mike From: OAuth On Behalf Of Atul Tulshibagwale Sent: Wednesday, March 27, 2024 12:01 PM To: Rifaat Shekh-Yusef Cc: oauth Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata Hi all, I'd committed to reviewing the draft at IETF 119, so here is my feedback up to section 3.1: 1. Section 1: The sentence "Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location rooted at the protect resource's URL, even when the resource server implements multiple protected resources." has two issues: * Typo: "protected resource's URL" instead of "protect resource's URL" Corrected * This contradicts the statement in section 3, which states the "well-known" should be inserted between the host and path components Corrected 1. Section 1: The sentence "The means by which the client obtains the location of the protected resource metadata document is out of scope" conflicts with Section 3, which says "Protected resources MUST make ... (it) available at a path ...". This was actually about locating the resource – not its metadata. Corrected. 1. Section 2, "authorization_servers": since this is normative language, instead of saying "Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used.", should we say "the list of OAuth authorization servers MAY be a subset of the authorization servers supported by the protected resource." The “MAY choose not to advertise” language comes from RFC 8414 (OAuth 2.0 Authorization Server Metadata), where it is used in the “scopes_supported” description. It’s likewise used in this specification’s “scopes_supported” description and the “authorization_servers” description. I’m reluctant to use different language than RFC 8414 does for expressing the same concept unless you believe the current language is in some way factually wrong. 1. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit confusing. Should it say something like "If not using the default well-known URI, such URI path suffix MUST be registered..." This last sentence of paragraph 1 can actually be dropped, and the first sentence in the 2nd paragraph can be updated to refer to the IANA well-known registry. This language comes from RFC 8414 and therefore I’m reluctant to change it. 1. Section 3, paragraph 2: The first sentence should capitalize "MAY" in "...application-specific ways may define and register..." Corrected 1. Section 3, paragraph 2: The first sentence can drop the word "used" here: "...URI path suffixes used to publish..." The sentence will make more sense with that word dropped. Corrected 1. Section 3, paragraph 2: The last sentence is additional non-normative language, and could be removed, or could be moved to the "IANA Considerations" section Again, this parallels language in RFC 8414. 1. Section 3, paragraph 3: "...specify what well-known URI string..." should be changed to "...specify what well-known URI path-suffix..." Corrected. Note that the correction also makes the language parallel to the corresponding language RFC 8414. 1. Section 3, paragraph 3: Instead of saying "...publish its metadata at multiple well-known locations'', should we say "...publish its metadata using multiple well-known path-suffixes''? Again, this parallels language in RFC 8414. 1. Section 3.1, last paragraph: The sentence "This is required in some multi-tenant hosting configurations" may be removed as it is not the only situation in which a host may have multiple OPRM documents. Again, this parallels language in RFC 8414. I will continue the review but I wanted to update the WG on my review so far. Atul On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: 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 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Thanks for the detailed read, Atul. We’ll create a PR addressing these suggestions. Separately, while it may seem obvious with me being an editor, for the record, I support publication of this specification as an RFC. -- Mike From: OAuth On Behalf Of Atul Tulshibagwale Sent: Wednesday, March 27, 2024 12:01 PM To: Rifaat Shekh-Yusef Cc: oauth Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata Hi all, I'd committed to reviewing the draft at IETF 119, so here is my feedback up to section 3.1: 1. Section 1: The sentence "Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location rooted at the protect resource's URL, even when the resource server implements multiple protected resources." has two issues: * Typo: "protected resource's URL" instead of "protect resource's URL" * This contradicts the statement in section 3, which states the "well-known" should be inserted between the host and path components 1. Section 1: The sentence "The means by which the client obtains the location of the protected resource metadata document is out of scope" conflicts with Section 3, which says "Protected resources MUST make ... (it) available at a path ...". 2. Section 2, "authorization_servers": since this is normative language, instead of saying "Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used.", should we say "the list of OAuth authorization servers MAY be a subset of the authorization servers supported by the protected resource." 3. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit confusing. Should it say something like "If not using the default well-known URI, such URI path suffix MUST be registered..." This last sentence of paragraph 1 can actually be dropped, and the first sentence in the 2nd paragraph can be updated to refer to the IANA well-known registry. 4. Section 3, paragraph 2: The first sentence should capitalize "MAY" in "...application-specific ways may define and register..." 5. Section 3, paragraph 2: The first sentence can drop the word "used" here: "...URI path suffixes used to publish..." The sentence will make more sense with that word dropped. 6. Section 3, paragraph 2: The last sentence is additional non-normative language, and could be removed, or could be moved to the "IANA Considerations" section 7. Section 3, paragraph 3: "...specify what well-known URI string..." should be changed to "...specify what well-known URI path-suffix..." 8. Section 3, paragraph 3: Instead of saying "...publish its metadata at multiple well-known locations'', should we say "...publish its metadata using multiple well-known path-suffixes''? 9. Section 3.1, last paragraph: The sentence "This is required in some multi-tenant hosting configurations" may be removed as it is not the only situation in which a host may have multiple OPRM documents. I will continue the review but I wanted to update the WG on my review so far. Atul On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: 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 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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata
Hi all, I'd committed to reviewing the draft at IETF 119, so here is my feedback up to section 3.1: 1. Section 1: The sentence "Each protected resource publishing metadata about itself makes its own metadata document available at a well-known location rooted at the protect resource's URL, even when the resource server implements multiple protected resources." has two issues: 1. Typo: "protected resource's URL" instead of "protect resource's URL" 2. This contradicts the statement in section 3, which states the "well-known" should be inserted between the host and path components 2. Section 1: The sentence "The means by which the client obtains the location of the protected resource metadata document is out of scope" conflicts with Section 3, which says "Protected resources MUST make ... (it) available at a path ...". 3. Section 2, "authorization_servers": since this is normative language, instead of saying "Protected resources MAY choose not to advertise some supported authorization servers even when this parameter is used.", should we say "the list of OAuth authorization servers MAY be a subset of the authorization servers supported by the protected resource." 4. Section 3, paragraph 1: The last sentence, i.e. "The well-known URI path suffix used MUST be registered in the IANA "Well-Known URIs" registry" is a bit confusing. Should it say something like "If not using the default well-known URI, such URI path suffix MUST be registered..." This last sentence of paragraph 1 can actually be dropped, and the first sentence in the 2nd paragraph can be updated to refer to the IANA well-known registry. 5. Section 3, paragraph 2: The first sentence should capitalize "MAY" in "...application-specific ways may define and register..." 6. Section 3, paragraph 2: The first sentence can drop the word "used" here: "...URI path suffixes used to publish..." The sentence will make more sense with that word dropped. 7. Section 3, paragraph 2: The last sentence is additional non-normative language, and could be removed, or could be moved to the "IANA Considerations" section 8. Section 3, paragraph 3: "...specify what well-known URI string..." should be changed to "...specify what well-known URI path-suffix..." 9. Section 3, paragraph 3: Instead of saying "...publish its metadata at multiple well-known locations'', should we say "...publish its metadata using multiple well-known path-suffixes''? 10. Section 3.1, last paragraph: The sentence "This is required in some multi-tenant hosting configurations" may be removed as it is not the only situation in which a host may have multiple OPRM documents. I will continue the review but I wanted to update the WG on my review so far. Atul On Wed, Mar 27, 2024 at 5:54 AM Rifaat Shekh-Yusef wrote: > 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 > > 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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 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
