Skip to main content

IETF Last Call Review of draft-ietf-oauth-cross-device-security-13
review-ietf-oauth-cross-device-security-13-genart-lc-kyzivat-2025-12-12-00

Request Review of draft-ietf-oauth-cross-device-security
Requested revision No specific revision (document currently at 16)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2025-12-16
Requested 2025-12-02
Authors Pieter Kasselman , Daniel Fett , Filip Skokan
I-D last updated 2026-08-11 (Latest revision 2026-03-02)
Completed reviews Genart IETF Last Call review of -13 by Paul Kyzivat (diff)
Artart IETF Last Call review of -13 by Jim Fenton (diff)
Opsdir IETF Last Call review of -13 by Bing Liu (diff)
Secdir IETF Last Call review of -13 by David Mandelberg (diff)
Secdir Telechat review of -14 by David Mandelberg (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request IETF Last Call review on draft-ietf-oauth-cross-device-security by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/PD8QA9jWWLcxQP89e-TPOPzO5oY/
Reviewed revision 13 (document currently at 16)
Result Ready w/issues
Completed 2025-12-12
review-ietf-oauth-cross-device-security-13-genart-lc-kyzivat-2025-12-12-00
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.

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.

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.

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.