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