Skip to main content

Last Call Review of draft-ietf-oauth-resource-metadata-08
review-ietf-oauth-resource-metadata-08-artart-lc-gulbrandsen-2024-08-14-00

Request Review of draft-ietf-oauth-resource-metadata
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2024-08-26
Requested 2024-08-12
Authors Michael B. Jones , Phil Hunt , Aaron Parecki
I-D last updated 2024-08-14
Completed reviews Artart Last Call review of -08 by Arnt Gulbrandsen
Secdir Last Call review of -08 by David Mandelberg
Opsdir Last Call review of -08 by Bo Wu
Assignment Reviewer Arnt Gulbrandsen
State Completed
Request Last Call review on draft-ietf-oauth-resource-metadata by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/DGX3r0OJ6F1BW0aJPJYrh9yPmdI
Reviewed revision 08
Result Ready w/nits
Completed 2024-08-14
review-ietf-oauth-resource-metadata-08-artart-lc-gulbrandsen-2024-08-14-00
Hi,

I'm the assigned art-art reviewer. The document is ready with nits, I 
think.

As a reviewer, I have worked on software that used oauth, have worked on 
software that used JWT, have implemented dozens of other RFCs, but don't 
know oauth well.

Introduction, third paragraph: the phrase self-asserted confuses me. Self 
is the metadata resource, right? Maybe phrasing along the lines of "can 
either be included directly in the metadata resources".

As an implementer I missed information about default/absent values: 
bearer_meethods_supported and resource_signing_alt_values_supported might 
explain what omission means.

I'm curious about why one might want to not mention some scopes. I liked 
the example for authorization_server, perhaps you could add one here too.

The resource_policy_uri and the tos are human-readable, right? The one 
above explicitly says it is.

Section 3.1 says one MUST query using GET. I couldn't help wondering about 
caching. As a client, is is okay to just cache as given by 
Cache-Control/Expires? As a server, can I stumble into a security problem 
if I serve this with too long/short lifetime? The security consideration 
don't say, I can't think of anything, but the security considerations also 
don't say there's nothing.

I really liked section 7.5.

Section 7.6 says "fixed and enumerable". Don't see why it has to be fixed.

In general I feel that I could implement this easily and well, which is 
really the key to any RFC. Good job. I do wonder what missing values of 
bearer_meethods_supported and resource_signing_alt_values_supported mean, 
though.

Arnt