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

[Brian Campbell <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On Wed, Apr 3, 2024 at 9:52 AM Michael Jones <[e-mail]>
> 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 <[e-mail]> *On Behalf Of *Brian Campbell
>> *Sent:* Tuesday, April 2, 2024 2:45 PM
>> *To:* Vladimir Dzhuvinov <[e-mail]>
>> *Cc:* [e-mail]
>> *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 <
>> [e-mail]> 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
>>
>> [e-mail]
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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._