Hi William,
> On Aug 2, 2018, at 2:41 PM, William Denniss <wdenn...@google.com> wrote:
>
> Alissa,
>
> Thank you for your review. Replies inline:
>
> On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <ali...@cooperw.in
> <mailto:ali...@cooperw.in>> 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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
