Hi Deb We addressed all raised issues and published an update to Datatracker earlier today [1].
Cheers Pieter [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/ On Fri, Nov 28, 2025 at 7:16 PM Pieter Kasselman <[email protected]> wrote: > Thanks for the review and feedback Deb, especially for getting this out on > Thanksgiving. Much appreciated. > > I have created issues for all the comments and will open PRs to address > them. I'll drop you a note once that is done. > > Cheers > > Pieter > > On Fri, Nov 28, 2025 at 11:36 AM Deb Cooley <[email protected]> wrote: > >> Thanks for this work. It is clear, readable, and compelling. I was >> already leery about QR codes, and now? >> >> Here are some minor comments followed by a list of nits: >> >> I did a quick idnits check (I used the v3 experimental one) and a couple >> of things popped up which you need to fix. Both Security Considerations >> and IANA Considerations are required sections. For IANA Con you should >> say: “This document has no IANA actions.” For Security Considerations you >> can do something similar, or you can do something different (maybe modify >> the Conclusion?). The other thing that popped up were some 'SHOULD not' >> type language. Obviously these should be 'SHOULD NOT'. >> >> Section 3, para 1, last sentence: [this is very minor] I had trouble >> understanding the last phrase of this sentence. Does 'before potentially >> passing control between the two devices' mean the same thing? The rest of >> the para discusses transferring the session from device 1 to device 2, but >> the last phrase of the last sentence reads like passing control from device >> 2 back to device 1. Or make it more clear that there are two >> use cases. >> >> Section 6.1.1, physical connectivity (and others), last sentence: This >> appears to be tacked on to the end of this paragraph and it appears in more >> than one section on proximity (not necessarily in the same form). Can we >> move it up into the first paragraph of Section 6.1.1 (perhaps adding a >> paragraph there - before the mitigations)? Maybe as a note, since this >> section/set of mitigations are about the channel between Consumption Device >> and Authorization Device (not the Authentication server). >> >> Section 6.1.15: Isn't there a limitation where the Consumption Device >> does not have sufficient input capabilities to support phishing resistant >> auth mechanisms? (this is stated in the first paragraph, but it is also >> (?) a limitation. >> >> Nits: >> Section 2, sentence 1: protools/protocols >> Section 2, para 1, last sentence: writing/this specification (or this >> writing) >> Section 4, sentence 1: typicaly/typically >> Section 5, last para: SHOULD not/SHOULD NOT >> Section 6.1.7, para 2: intractive/interactive >> >> Deb Cooley >> Sec AD >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
