Thank you for your work on this specification, here are my comments on this draft. Apologies for the delay (IETF 125 and recovery from the same takes time). I don't think any of these comments are especially difficult, most are process related:
Deb Sec AD --------------------------------------- General: Consider using *.*.example.org for example domains (currently this draft uses as.*.org). See: https://authors.ietf.org/example-addresses for more information. Long line: Line 416, is 75 characters long, according to idnits (experimental). I did not go looking for this (which is why I've put it up front). Section 2.1, Appendix B: Using steps (A), (B), (C) could be confusing in light of the pre-existing domain enumerations of Domain A, Domain B. I'd suggest using some other enumeration for the steps, maybe (1), (2), (3) to disambiguate. Section 2.2: Since this 'MAY' does not enable/disable interoperability (the goal of BCP 14), consider changing it to 'may' or even 'could'. Section 2.3, bullet 1: 'MUST deny' or 'MUST NOT approve'? Which will be more obvious to the implementer? Section 2.4.3: There is an assumption here that the previous rules/steps/checks have been validated without error. Perhaps consider adding a phrase like, 'When the authorization grant has been validated, the....' Section 5: BCP14 language or not? Please see: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ . While BCP 14 words in Security Considerations is completely appropriate, it should still be used sparingly. The word 'must' is just as normative as 'MUST', but carries less baggage. I would suggest going back through Section 5, and consider which of the BCP 14 words are there for 'interoperability' or to 'prevent harm'. Please pay special attention to section on 'SHOULD' and 'RECOMMENDED'. I'm making some comments within Section 5 to emphasize my point of view. Section 5.1: Naked 'SHOULD's need to have a 'what are the consequences of violating the should' that goes with it. An alternative is to state under what reasonable circumstances the should isn't possible (maybe that is the public client part of this section?). Section 5.4: I'm guessing that there was confusion at some point about issuance of refresh tokens by AS domain A to clients in domain A? My suggestion to make this a tiny bit clearer in para 1 is to add 'domain A' when you mention 'client' -> 'client in domain A'. It does make it wordier and longer, but way more obvious that the refresh tokens across domains are the issue. Section 5.4: It is also not clear why one might choose to violate the sequence of 'SHOULD NOT', 'SHOULD', 'SHOULD'... Why not 'MUST NOT', 'MUST', 'MUST'? Sadly, RFC 7521 doesn't specify why/when 'SHOULD NOT' could be ignored (unless I read it incorrectly). Section 5.5: Why not 'MUST'? Seems reasonable to say that one MUST evaluate the risk and since there is no definition of 'appropriate', then any mitigations will do, no? IANA Considerations: Add this, see: https://authors.ietf.org/en/iana-considerations . It *might* be possible to remove it prior to publication. IANA will know (and tell you) for sure. Acknowledgements (Appendix C): I would remove the parenthetical and just state a generic 'and others for their valuable input....'. Naming everyone who had input is not actually required. [rationale: the () won't age well]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
