[OAUTH-WG] Review of draft-ietf-oauth-device-flow-06

[Samuel Erdtman <[e-mail]>]

Hi Authors

Thanks for writing this very useful draft.

I have some review comments that I hope will be useful.

As a general comment, has it been considered to include CoAP mappings too?
it might be good to reach even more constrained devices (maybe another
draft).


1.  Introduction
Missing newline between Step E and D

1.  Introduction
The bullet list with the polling of the client and the user authorisation
is a bit hard to read, step D comes again after E. Maybe it would be easier
to read if using decimal numbers.

‘1.  Introduction’ and ‘3.  Protocol’
I would like to move the ascii art and the corresponding list of steps from
‘1.  Introduction’ to ‘3.  Protocol’ and use the terminology explained in
‘2.  Terminology’

3.1.  Device Authorization Request
Is there no authentication? e.g. use of client secret? (or Pre-Shared Key
or Raw Public key as described in draft-erdtman-ace-rpcc)
I don’t think client identification is enough I think it should
authenticate, at least as the recommendation.

3.2.  Device Authorization Response
I would like to change verification_uri be optional. If for example the
device vendor has a companion app that app could easily have the
verification_uri, that would simplify for the user that would only have to
enter the code. (and it could save some bytes).

3.2.  Device Authorization Response
I think it would make sense to add an optional parameter with the token
endpoint uri, in that way it does not have to be hardcoded in the client
(or discovered) but the AS can tell the client where to get the token. Or
it could be done with a redirect to the token URL or the Device
Verification Code could be a the URL to poll instead.

3.4.  Device Access Token Request
client_id, it says REQUIRED but then it states that it is to be used only
if “client is not authenticating with the authorization server as described
in Section 3.2.1. of [RFC6749].”
I think the parameter should be optional and authentication required.

3.2.  Device Authorization Response and  3.5.  Device Access Token Response
“The interval at which the client polls MUST NOT be more frequent than
   the "interval" parameter returned in the Device Authorization
   Response (see Section 3.2).”
“OPTIONAL.  The minimum amount of time in seconds that the client
      SHOULD wait between polling requests to the token endpoint.”
Feels like a contradiction between the parameter description and token
endpoint response. I would like to have MUST in both cases.

3.5.  Device Access Token Response
I think last paragraph is better suited in the introduction section.

5.2.  Device Trustworthiness
I think device authentication should/could be mentioned here