[art] Re: art-art review of draft-ietf-oauth-resource-metadata

[Michael Jones <[e-mail]>]

Arnt, your review comments are addressed in https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata/pull/51/commits/c3b7cc68eb4f223a89fc928690b1905a129b4be4, 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:22 PM
To: Arnt Gulbrandsen <[e-mail]>; [e-mail]
Cc: Deb Cooley <[e-mail]>
Subject: [art] Re: art-art review of draft-ietf-oauth-resource-metadata

Thanks for the review, Arnt.  Replies are inline below, prefixed by "Mike>".

-----Original Message-----
From: Arnt Gulbrandsen <[e-mail]>
Sent: Wednesday, August 14, 2024 8:18 AM
To: [e-mail]
Subject: [art] art-art review of draft-ietf-oauth-resource-metadata

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".

Mike> Yes, the metadata resource is vouching for its own metadata when it is self-asserted.  I'm reluctant change the "self-asserted" phrasing, because it's the same wording used for the same thing in the introduction to the other two OAuth metadata specs.  You can find it at https://www.rfc-editor.org/rfc/rfc7591.html#section-1 and https://www.rfc-editor.org/rfc/rfc8414.html#section-1.  Is it OK with you to leave it as-is for consistency sake?

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

Mike> resource_signing_alg_values_supported includes this text about there being no default: "No default algorithms are implied if this entry is omitted.", so I think that one's already covered.

Mike> For bearer_methods_supported, given we now have DPoP in which no bearer token methods are used, defaults (other than possibly none) don't make sense.  However, you comment caused me to think about it and I plan to add this text:  "The empty array [] can be used to indicate that no Bearer methods are supported.  If this entry is omitted, no default Bearer methods supported are implied, nor does absence indicate that they are not supported."

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.

Mike> The "MAY choose not to advertise some scope values supported" language is also found in both RFC 7591 and RFC 8414.  One reason for not listing all scopes is that some OAuth implementations use "structured scopes with parameters", where part of the scope name is a parameter value.  For instance, such a scope name might be "you-can-use!https://example.com/use-this-thing".  There may also be privacy reasons not to list them.

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

Mike> In both cases, I'll borrow the applicable "human-readable" language from the corresponding entries in RFC 7591 and apply it here.

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.

Mike> Again, I looked at the parallel specs and https://www.rfc-editor.org/rfc/rfc8414.html#section-1 uses GET in the same way.  I'd be glad to add a Security Considerations section on this is we can come up with something meaningful to say.  Probably something about being aware of HTTP caching lifetimes?

I really liked section 7.5.

Mike> Thanks!  When we wrote this at https://www.rfc-editor.org/rfc/rfc8414.html#section-6.3, there really were people making the security-by-obscurity argument that publishing the information in an easily accessible manner was bad!  That's why this section is there.

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

Mike> Good point.  I'll delete "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

Thanks for the useful review and positive feedback!

                                -- Mike
_______________________________________________
art mailing list -- [e-mail]
To unsubscribe send an email to [e-mail] _______________________________________________
art mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]