Thanks David. My replies are inline below, prefixed by "Mike>".
-----Original Message-----
From: David Mandelberg via Datatracker <nore...@ietf.org>
Sent: Friday, August 16, 2024 3:42 PM
To: sec...@ietf.org
Cc: draft-ietf-oauth-resource-metadata....@ietf.org; last-c...@ietf.org;
oauth@ietf.org
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
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
