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

[William Denniss <[e-mail]>]

Benjamin,

On Fri, Aug 3, 2018 at 4:37 PM, Benjamin Kaduk <[e-mail]> wrote:
>
>
> 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?


It might be possible for the server to catch certain types of errors, I
agree, but not all possible errors. For example mis-entering path separator
wouldn't be catchable on the server, such as for the user input:
"device.example.comWDJB-MJHT" or "device.example.com;WDJB-MJHT"

It's also more challenging to implement the error handling, as the URI
could resolve to another valid URI, e.g. "device.example.com/abc" might be
used for something else.

Our opinion on usability is that it's better to break it down into two
steps: get the URI correct, then type the code correctly. In the latter
section, the AS can render helpful instructions, and perform JS validation
during the input without needing a page reload.

Another advantage of having the code separate is that when the QR code
with verification_uri_complete
is used, the code could be re-purposed as pairing code. E.g. after scanning
the QR Code: (e.g. "is your device displaying WDJB-MJHT ?"). That would be
harder to describe with a combined URI + code.  This is something we
explicitly recommend in Section 3.3.1 (third paragraph).

One final point, earlier I said that the user would type the same number of
characters regardless, but that was wrong: in the case of the URI, the user
would need to type an additional character being the path or query
separator. That extra character may not seem like much but it does impact
usability (even with no errors), as they would need to navigate to the
special characters section on the keyboard. I will tweak the text to
reflect this.