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

From: William Denniss <[email-masked]>
Date: Thu, 2 Aug 2018 11:41:05 -0700

Alissa,

Thank you for your review. Replies inline:

On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <[email-masked]> 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…"

> 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.

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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 3 Aug 2018 09:22:09 -0400

Hi William,

> On Aug 2, 2018, at 2:41 PM, William Denniss <[email-masked]> wrote:
> 
> Alissa,
> 
> On Tue, Jul 31, 2018 at 8:58 AM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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
> 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.

> 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 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

> 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:
> 
> included here? If the point is to illustrate the UI it seems like those should
> be included too.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Aug 2018 18:37:11 -0500

> there rather than get browser errors if they typed the user-code part of

I am hardly a URI expert, so salt as appropriate, but if the user code was
in the query string, would the server still be able to generate a useful
error page if the user code was typed incorrectly?

-Benjamin