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

[Alissa Cooper <[e-mail]>]

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] <mailto:[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.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.

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
>