This certainly isn't a comprehensive review or endorsement necessarily but I read though the latest draft and had a couple of off-the-cuff* comments/questions:
The abstract and intro talk only about enabling clients to obtain information needed to interact with a protected resource. However, the jwks_uri protected resource metadata parameter mentions that it might contain encryption key(s) that are used to encrypt access tokens to the protected resource, which would be something the AS does. It seems like the abstract and/or intro text should be adjusted or augmented a bit so as not to suggest that an AS is precluded from using the protected resource metadata. I'm struggling to see how the resource_signing_alg_values_supported, resource_encryption_alg_values_supported, and resource_encryption_enc_values_supported parameters would be used in a meaningful or interoperability improving way. What "content" is being signed or encrypted and by whom? These parameters seem to me to clutter/confuse the draft more than providing actual useful information. If you know (well-known), you know. The way it's done here makes a lot of sense for the context but might raise some eyebrows down the road, if this draft progresses. * Actually, I may have had some of these same thoughts in 2017 when -01 was presented to the WG but didn't get around to mentioning them back then :) On Mon, Jul 10, 2023 at 6:34 PM Michael Jones <[email protected]> wrote: > In collaboration with Aaron Parecki <https://twitter.com/aaronpk>, the > ability for OAuth 2.0 protected resource servers to return their resource > identifiers via WWW-Authenticate has been added to the OAuth 2.0 > Protected Resource Metadata specification. This enables clients to > dynamically learn about and use protected resources they may have no prior > knowledge of, including learning what authorization servers can be used > with them. > > > > This incorporates functionality originally incubated in > draft-parecki-oauth-authorization-server-discovery-00 > <https://www.ietf.org/archive/id/draft-parecki-oauth-authorization-server-discovery-00.html>. > Aaron and I had been asked to merge the functionality of our two drafts > during an OAuth working group session at IETF 116. We’re both happy with > the result! > > > > The specification is available at: > > · > https://www.ietf.org/archive/id/draft-jones-oauth-resource-metadata-04.html > > > > -- Mike > > > > P.S. This notice was also posted at https://self-issued.info/?p=2377 and > was referenced from > https://twitter.com/selfissued/status/1677471513023508481. > > > _______________________________________________ > OAuth mailing list > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
