Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Michael Jones]

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 
consumers of the metadata can use to determine where to find the 

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Michael Jones]

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 use that 
consumers of the metadata can use to determine 

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Michael Jones]

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].

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
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 

[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-metadata-04.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-resource-metadata-04.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth 2.0 Protected Resource Metadata
   Authors: Michael B. Jones
Phil Hunt
Aaron Parecki
   Name:draft-ietf-oauth-resource-metadata-04.txt
   Pages:   25
   Dates:   2024-04-26

Abstract:

   This specification defines a metadata format that an OAuth 2.0 client
   or authorization server can use to obtain the information needed to
   interact with an OAuth 2.0 protected resource.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-04

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-resource-metadata-04

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth