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]
