David, the newly published version of
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/
incorporates the changes to address your review comments.
Thanks again!
-- Mike
-----Original Message-----
From: David Mandelberg <[email protected]>
Sent: Thursday, September 12, 2024 4:42 PM
To: Michael Jones <[email protected]>; [email protected]
Cc: [email protected]; [email protected];
[email protected]; Arnt Gulbrandsen <[email protected]>; Deb Cooley
<[email protected]>
Subject: Re: Secdir last call review of draft-ietf-oauth-resource-metadata-08
Those changes sound good, thanks!
Op 2024-09-10 om 22:22 schreef Michael Jones:
> Thanks David. My replies are inline below, prefixed by "Mike>".
>
> -----Original Message-----
> From: David Mandelberg via Datatracker <[email protected]>
> Sent: Friday, August 16, 2024 3:42 PM
> To: [email protected]
> Cc: [email protected]; [email protected];
> [email protected]
> 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 -- [email protected]
To unsubscribe send an email to [email protected]
