Re: [OAUTH-WG] Alissa Cooper's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

[William Denniss <[e-mail]>]

Hi Alissa,

Version -13 contains both these improvements, thank you for your feedback!

Detailed response inline below:

Best,
William

On Fri, Aug 3, 2018 at 6:22 AM, Alissa Cooper <[e-mail]> wrote:

> Hi William,
>
> On Aug 2, 2018, at 2:41 PM, William Denniss <[e-mail]> wrote:
>
> Alissa,
>
> Thank you for your review. Replies inline:
>
> On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <[e-mail]> wrote:
>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I support Mirja's DISCUSS point #3 which was also raised by the Gen-ART
>> reviewer. The Gen-ART review also included a number of other useful
>> comments.
>> Please address them.
>>
>
> We're working through the comments, some were addressed in -12, and the
> work continues.
>
>
>>
>> Perhaps this is implicit, but I found it a little odd that there is no
>> mention
>> of whether the device codes and user codes are expected to be unique to
>> individual devices.
>>
>
> The are definitely expected to be unique.
>
> Section 3.2 currently states "the authorization server generates a device
> verification code and an end-user code that are valid for a limited time"
>
> The assumption was that the "generated" codes would be unique. I will add
> the word unique in future version (13), so it will read "generates a unique
> device verification code…”
>
>
> Great.
>

Section 3.2 of version 13 reads in part:

the authorization server generates a *unique* device
   verification code and an end-user code that are valid for a limited
   time




>
>
>
>
>> Section 3.3:
>>
>> "It is NOT RECOMMENDED for authorization servers to include the user
>>    code in the verification URI ("verification_uri"), as this increases
>>    the length and complexity of the URI that the user must type."
>>
>> I don't fully understand the justification for the normative requirement
>> here.
>> The user ultimately ends up typing in both strings, right? Is it so much
>> more
>> complex to type them both into a browser bar contiguously than to type
>> the uri
>> into the browser bar and the code into some form field on the page such
>> that
>> the normative requirement is warranted?
>>
>
> Yes, the user will need to type both strings regardless.
>
> The main reason for the recommended separation is that the URI can't be
> validated/corrected – either they type it correctly and they get to the
> page, or they don't. But for the user-code, the page can display an error
> if the user types it wrong. The belief is that it's a better user
> experience that they get to the page, and then continue the input from
> there rather than get browser errors if they typed the user-code part of
> the URI wrong.
>
>
> Got it. I think it would help to add this explanation to the document.
>
>
Added an explanation to Section 3.3 in version 13:

   It is NOT RECOMMENDED for authorization servers to include the user
   code in the verification URI ("verification_uri"), as this increases
   the length and complexity of the URI that the user must type.  *While
   the user must still type the same number of characters with the
   user_code separated, once they successfully navigate to the
   verification_uri, any errors in entering the code can be highlighted
   by the authorization server to improve the user experience.*  The next
   section documents user interaction with "verification_uri_complete",
   which is designed to carry *both pieces of* information.




> Thanks,
> Alissa
>
>
> This is also how every implementation I've seen has actually implemented
> it.
>
> As written, if the authorization server were to include the code in the
> URI, this would then raise the question of what should be in the user_code
> (e.g. would it be the empty string?) and how the device client should
> render the instructions in that case. I think the spec is simpler if we
> recommend one preferred approach based on the usability best-practices
> derived from the implementation experience of earlier drafts.
>
> Section 3.3.1:
>>
>> Wouldn't there be textual instructions about how to use the QR code also
>> included here? If the point is to illustrate the UI it seems like those
>> should
>> be included too.
>>
>
> Good point! Figure 3 was updated to include QR scanning instructions.
>
> Best,
> William
>
>
>