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 <bcampb...@pingidentity.com>
Sent: Thursday, April 4, 2024 2:42 PM
To: Michael Jones <michael_b_jo...@hotmail.com>
Cc: Vladimir Dzhuvinov <vladi...@connect2id.com>; 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
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> wrote:
On Wed, Apr 3, 2024 at 9:52 AM Michael Jones
<michael_b_jo...@hotmail.com<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 <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On Behalf
Of Brian Campbell
Sent: Tuesday, April 2, 2024 2:45 PM
To: Vladimir Dzhuvinov <vladi...@connect2id.com<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
<vladi...@connect2id.com<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.
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
