[OAUTH-WG] Re: Secdir last call review of draft-ietf-oauth-resource-metadata-08

[Michael Jones <[e-mail]>]

David, your review comments are addressed in https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51/commits/5677b2477853df607e61a2ff9ab6bdc663f7048a, which is part of https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51.

				Thanks again!
				-- Mike

-----Original Message-----
From: Michael Jones <[e-mail]> 
Sent: Tuesday, September 10, 2024 7:23 PM
To: David Mandelberg <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Arnt Gulbrandsen <[e-mail]>; Deb Cooley <[e-mail]>
Subject: RE: Secdir last call review of draft-ietf-oauth-resource-metadata-08

Thanks David.  My replies are inline below, prefixed by "Mike>".

-----Original Message-----
From: David Mandelberg via Datatracker <[e-mail]> 
Sent: Friday, August 16, 2024 3:42 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Secdir last call review of draft-ietf-oauth-resource-metadata-08

Reviewer: David Mandelberg
Review result: Has Nits

Overall, looks good. I just have a couple of questions that might not need any changes to the doc.

Section 5.2 says "SHOULD retrieve the updated protected resource metadata and use the new metadata values obtained" which makes sense for the values included directly in the metadata.

Mike> How about if we make this change to 5.2?  Change "and use the new metadata values obtained" to "and use the new metadata values obtained after validating them as described in Section 3.3"

For the URLs like jwks_uri though, is the client expected to retrieve those again even if the URL itself didn't change? Or does that not need to be specified?

Mike> URLs such as jwks_uri are governed by HTTP caching rules, as is the primary metadata itself.  I'd already told Arnt Gulbrandsen in my reply to his ART review that I'd add something about caching lifetimes in the Security Considerations.

What do you think about adding something to section 5.2 about redoing all validation (like checking the resource field and validating the signature in
signed_metadata) before using new values? I'd hope that any implementations would do that without it being specified, but I could see some bugs if the code path for fetching initial values is different than the code path for updating values.

Mike> Your comment about signature validation made me realize that we don't say anything about validating the signature of signed metadata!  I propose to add something like this:  "The recipient MUST validate the signature of the signed metadata using a key belonging to the issuer.  If the signature does not validate or the issuer is not trusted, the recipient SHOULD consider this an error condition."

Thanks for your useful review!

				-- Mike