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

William Denniss <> Fri, 13 October 2017 22:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89396132811 for <>; Fri, 13 Oct 2017 15:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id odZPgVBvjw3l for <>; Fri, 13 Oct 2017 15:22:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF5FD13219F for <>; Fri, 13 Oct 2017 15:22:12 -0700 (PDT)
Received: by with SMTP id 1so22260407qtn.3 for <>; Fri, 13 Oct 2017 15:22:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YT8BKTYZeYknPGOyEeczfENJGx9PIlNLbz89ZoxrcCc=; b=sVQ663jk9/P1rYSB7hoy1USAimcfKrJmgeUhXTNunxyZO/Q4/727fNNr9mnAXslKvE PeEXknAejhBmwG9iXieMpDpiWfDNpYC93ljRWHfAE+stQy9mVp3MsH6BpozLpl3keM3U 8M5Hy/BnEA9EByke3Pp2GqLImELErfR8JXjyojhO61ehSJcvq98bCduIKG1fXMCFVe6L sXDFU2kEQc7138sZae5V9Z85W2/fWVnxXzAxYNLEwSDregxJ+NgD1Qa/AMGx6LKePGKK lpTx23XG556XBA7LjuRRJWL57qpZrm5bq5kXO49G+ItLf2yx64TQoARh+oqrM2+Ds06f ZAQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YT8BKTYZeYknPGOyEeczfENJGx9PIlNLbz89ZoxrcCc=; b=jnnhJt1gV47UeervdGG95dtzGj9fSkbqiZ0nxo1v6uUXQa3paeAeMNCbgGBe7bmAJQ USh9DQeC3gUhD3HetfMKPCXVzc5omk/gHJEY6ANAHUzyGfBst8rNWPabr3tKjkAdcAOH +KKM6WH5vl1sgDLgzoAwTZLDlbxNrQvsl0RKgJAsc2+ibSZbPN+sznRIR6gOI0M2tbhv lI59jfWe+L6XrVMSLVLaC0TvLWQzfeO0aRPJsH1EqUsj1zBVm33ZpgSZrkCWrX3QRpeU 1pS3DmrD2NzcyQZSgSW34EfpTAzU78PywskhJPgiXdXcy7aTsYDPMQ5VT+bCsFRjqMaJ NmXA==
X-Gm-Message-State: AMCzsaXu3Ze3yzWe5iTWNqb5JA7rUBxAk8Qn/PU2SfjitgeJq6USxxOe 5EWd6ceGrIJgtB3TThVlwtrduqOpUfo53HZmz2dpk/ICiqQ=
X-Google-Smtp-Source: AOwi7QAcQcH0IPatYNh0/UQqKALKL0g0yuvtE/KVh7ks7ViqD8yVQEjW6ZGfXxJfz2bpATm8DVMwLJb/4yfVLTiL9KQ=
X-Received: by with SMTP id f12mr1863900ywk.274.1507933331671; Fri, 13 Oct 2017 15:22:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 13 Oct 2017 15:21:51 -0700 (PDT)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Fri, 13 Oct 2017 15:21:51 -0700
Message-ID: <>
To: Samuel Erdtman <>
Cc:, "<>" <>
Content-Type: multipart/alternative; boundary="f403045e764c94d603055b751663"
Archived-At: <>
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-device-flow-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Oct 2017 22:22:15 -0000

On Thu, Sep 7, 2017 at 1:11 PM, Samuel Erdtman <> wrote:

> Hi Authors
> Thanks for writing this very useful draft.

Hi Samuel,

Thanks for reviewing the 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.

(D) is referenced in (E), I believe it's intentional.

I'll expand the reference to "(step D)" to make that clear.

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

I'll discuss this with my co-authors, could make sense.

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

There is no client authentication as they are public clients. This is
covered in the security consideration "Non-confidential Clients". As draft
is nearly ready to publish, I don't think we should take a reference on an
I-D that would delay our publication.

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

This type of use-case is mentioned in the section "Non-Browser User
Interaction" if you own both the server and the client – you can really do
whatever you like as it doesn't need to be interoperable. If this spec is
useful for that case – great, but I don't think we need to discuss or cater
for this more than we have.

> 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.
> can be used for
programmatic discovery of the token URL (and we add to that in the section
"Discovery Metadata").

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

See above.

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

The next version
clarifies this a bit. PTAL.

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

I'm on the fence about this suggestion, as that paragraph does relate token

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

"Non-confidential Clients" covers that.