Re: Genart last call review of draft-ietf-oauth-device-flow-10

Robert Sparks <rjsparks@xxxxxxxxxxx> · Wed, 1 Aug 2018 19:55:45 -0500



    Answering your question inline:

    
    On 8/1/18 6:55 PM, William Denniss
      wrote:

    
      Robert,
        

        Thank you for your valuable feedback. Version 12
          incorporates your feedback. Replies inline:

          
            On Mon, Jun 11, 2018 at 9:20 AM,
              Robert Sparks <rjsparks@xxxxxxxxxxx>
              wrote:

              Reviewer:
                Robert Sparks

                Review result: Ready with Nits

                
                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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

                
                Document: draft-ietf-oauth-device-flow-10

                Reviewer: Robert Sparks

                Review Date: 2018-06-11

                IETF LC End Date: 2018-06-12

                IESG Telechat date: Not scheduled for a telechat

                
                Summary: Ready for publication as a Proposed Standard
                RFC, but with nits to

                consider

                
                Nits/editorial comments:

                
                In 3.5 "the client MUST use a reasonable default polling
                interval" is not

                testable. Who determines "reasonable"? At the very
                least, you should add some

                text about how to determine what "reasonable" is for a
                given device, and add

                some text that says don't poll faster than earlier
                responses limited you to.

                For example, if the response at step B in the
                introductory diagram had an

                explicit interval of 15, but a slow-down response to an
                E message didn't have

                an explicit interval, you don't want them to default to,
                say 5 seconds (because

                that's what the example in section 3.2 said, so it must
                be reasonable).

              
              Thanks for the feedback, version 12 specifies a
                default of 5s.
               
              
                In 3.3, you say the device_code MUST NOT be displayed or
                communicated. Is there

                a security property that's lost if there is? Or is this
                just saying "Don't

                waste space or the user's time"?

              
              It's just a waste of the user's time. This text has
                been modified.
               
              
                The last paragraph of section 6.1 feels like a recipe
                for false positives, and

                for bug-entrenched code. Please reconsider it.

              
              I've reworded it a bit, but it's actually an
                important usability consideration so I do want to keep
                it in some form.
               
               
                You need line-folding in the example in section 3.2

              
              Can you clarify what you mean by this? 

              
    There was a line in a previous version (I thought I saw it in -10,
    but right now I only see it in -09) that was too long to be
    published as-is in an RFC. It looks like it's fixed in -12.

    
        Best,
        William