Thanks for the thoughful feedback Paul, much appreciated, comments/follow-up inline below:
On Fri, Dec 12, 2025 at 9:47 PM Paul Kyzivat <pkyzivat= [email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-oauth-cross-device-security-13 > Reviewer: Paul Kyzivat > Review Date: 2025-12-16 > IETF LC End Date: 2025-12-16 > IESG Telechat date: ? > > Summary: > > This draft is on the right track but has open issues, described in the > review. > > Major issues: (1) > > 1) ISSUE: Confusing diagrams > > Sect1ons 3.1.*, 3.2.1, 4.n.* contain flow diagrams that support the > text. I found the text to be clearer than the diagrams. Particularly, I > found the bidirectional arrows confusing; and also the looping arrows > (User Start Flow). If I read the text description first, and use the > diagram as support, then it seems ok. But, because the diagrams appear > before the text description, I first spent time trying to understand the > diagrams, and being confused by them, before reading the description. > > Also, as an example, in 3.1.1, step (C) involves two actions by separate > actors: (C1) consumption device displays the QR code, and (C2) User uses > the authentication device to scan the QR code. The diagram doesn't show > the user involvement in this step. > > I won't try here to enumerate all such problems. I'll leave that for > you. But I'm willing to do a more detailed analysis if you wish. > > I do think it is important for the reader to understand these, so I > think it is worth some effort to make these diagrams clearer. > Thanks for pointing this out. When you are steeped in a document, it is easy to become blind to the diagrams or text. The diagrams were meant to be "read" in conjunction with the text to convey the flows and the subsequent exploits. They were derived from pre-existing diagram and conventions in the original specification to help readers familiar with those documents. I will review the diagrams, focusing especially on the confusing elements you helpfully called out (double arrows and looping arrows), and compare these with the original diagrams in the referenced specifications to identify areas for improvement. I opened an issue to track this and will prepare a PR ( https://github.com/oauth-wg/oauth-cross-device-security/issues/208). If there are additional suggestions, please add them there. > Nits/editorial comments: 3 > > 1) NIT: Missing definitions: phishing & social engineering > > The terms "phishing" and *social engineering* are used extensively in > this document. They are in common use, and most readers of this document > can be expected to have some understanding of them. But they might not > all have the same definitions. I think it would be a good idea for you > to provide your own definitions, or cite some. > Defining phishing or soccial engineering is out of scope for this document. Instead, I will add a reference to the NIST Computer Security Resource Center glossary instead (see issue: https://github.com/oauth-wg/oauth-cross-device-security/issues/207) > 2) NIT: Possible downrefs > > IdNits reports several possible downrefs to normative non-RFC documents: > [CIBA], [CAEP], [SSF], [W3CWebAuthn], [FIDOCTAP22], [IEEE802154] > > These are probably fine. But I'm not sure that any of these need to be > *normative* references, as they are all used as examples. Consider > making them non-normative. > > The few other things reported by IdNits are bogus. > The normative/non-normative split of references arose during shepherd review. The references were made normative because they either reference the actual protocols being exploited (CIBA), or describe technologies and capabilities that act as mitigations or alternatives. For example, if you want to replace device authorization code flows with the authorization code flow using FIDO2/WebAuthn and have a cross device capability, you have to use [FIDOCTAP22] (e.g.. FIDO2/WebAuthn SHOULD be used for cross-device authentication scenarios whenever the devices are capable of doing so and a suitable FIDO credential is not available on the Consumption Device.) > 3) Comment: > > (I don't think this is an issue or a nit, but do want to make the point.) > > Throughout the document QR codes and PIN codes are discussed as roughly > equivalent. But QR codes carry much more potential risk, because > dereferencing the URL in a QR code can cause almost anything to happen, > without the user knowing. So a cross-device flow that is designed to use > a QR code can have the effect of desensitizing the user to the potential > risk of scanning a QR code that is received in the context of a fishing > attackg. > > I'm not sure what, if anything, this document should do about this. > Perhaps there should be another document: QR Code Security Best Practices. > I think the general treatment of QR code security is out of scope of this document. I agree it may be a topic for a future document. > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
