LGTM! Deb
On Tue, Dec 2, 2025 at 9:29 AM Pieter Kasselman <[email protected]> wrote: > 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]
