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

[Samuel Erdtman <[e-mail]>]

Ping

On Thu, Sep 7, 2017 at 10:11 PM, Samuel Erdtman <[e-mail]> wrote:

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