Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

William Denniss <> Wed, 30 May 2018 22:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 142FD12D7EF for <>; Wed, 30 May 2018 15:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 0_FJyMPHiQEl for <>; Wed, 30 May 2018 15:32:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C21112E03A for <>; Wed, 30 May 2018 15:32:03 -0700 (PDT)
Received: by with SMTP id i2-v6so13663271uah.0 for <>; Wed, 30 May 2018 15:32:02 -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=D1+I0MXg+bO+65uHCWCEqqdm8iB4RNyoeP3t+gDd35M=; b=q/WR1xdY4gJxbuy1AQ9d+cYG/iWJIXmQvfzjR3BfC9LXfwU9QC5kQ0v0VqVegl24n4 C2eLsWiLJ+NBfz4p7XeCBEA78QTyJHku6f1els3Sf+U8nbgkSZNk4mieEtdHRLqRdMCL uXMXTOMrlLPT3zhzozUru1ZnaY0s7GIutDW6Vr5HZYWTu2xuPvIkDd/Y/2uER8DW9yau hP+OOxsKCEnBqRS4eQIwRtia3TzEFFEUmowmu6j/0lIb13Hkh64q4xWmMimPtmR5cBjE ai8f7/vwIvyF8+3X5d9pny/5vi5XNs3Xo3MZ3UGa6LjLJ6hI42mPvJVkUL12KBO4JBBH mVCg==
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=D1+I0MXg+bO+65uHCWCEqqdm8iB4RNyoeP3t+gDd35M=; b=CSadwwx9gq4Y22yJ38VzZkQJn4IXKSN1XBzY6SySSP1YUTBDsBgSfjxdn5AGdHeGNo 9+ifN0sdsyHJ6HjsEHUZ4a2/7nFKdDaZ6o1UeJYEzgxX+ep4KDERdLawncRlc3kRNQPT FhGpQgeD+A3SgizSadtXEm15RG4rWB1LloOMu2GKxSDCBqAR7ShAYMDv+gIqiVm+qMlB YlJFRaLaBJfN0nQTXeDjESd/zbLCm2ZaEkk83TllLd8v1myi+w4Spa6lYyCPKQUTwIUS V+7QsXMl6Z6mM13fcwwW+iH/T0Cvt6+gQ++ExD58h5zW7HafGchAMbf8eEEMX25bnfh6 Tv+w==
X-Gm-Message-State: ALKqPweCV67rLiOMt+5V+9s3POE6RYcakeWqHoiKDZFfxxtSpPOeVd3Q CiAn/qPegdmGgBO4Vmvs2elM73mfMMDeCtAiWsGOeg==
X-Google-Smtp-Source: ADUXVKL+ocBqoRW9Zj0vDuJo1Ut3PPFwW4ZH5Y7ZCVZ38VsCFWgEUlFa1xYz2C2/uhgsNerWIQdvXcSC9I6P3APymnM=
X-Received: by 2002:a9f:2e0f:: with SMTP id t15-v6mr3246218uaj.114.1527719521545; Wed, 30 May 2018 15:32:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Wed, 30 May 2018 15:31:41 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: William Denniss <>
Date: Wed, 30 May 2018 15:31:41 -0700
Message-ID: <>
To: Brian Campbell <>
Cc:, IETF-Announce <>, oauth <>,,
Content-Type: multipart/alternative; boundary="000000000000669f53056d73ebe7"
Archived-At: <>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-device-flow-09.txt> (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard
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: Wed, 30 May 2018 22:32:06 -0000

Hi Brian,

On Wed, May 30, 2018 at 12:56 PM, Brian Campbell <
> wrote:

> In reading the draft (again) I noticed a couple of things that, while
> maybe not substantive, seemed like they were worth raising here in last
> call:
> 1:
> In Section 3.5
> <>
> a new 'expired_token' error code is defined for when the 'device_code' has
> expired and the client will need to start the flow over. Shortly after the
> new error code definition there is text in that section that says 'If the
> verification codes have expired, the server SHOULD respond with the
> standard OAuth error "invalid_grant".  Clients MAY then choose to start a
> new device authorization session.'
> This reads to me like: here's a new error for expired device code but this
> other code SHOULD be used for expired device code. Am I confused or
> otherwise missing something?
> I kinda suspect that the intent is that expired_token can be returned for
> codes that are known to be expired while invalid_grant is more of a catch
> all for codes that may have expired long enough ago that they have been
> purged from server memory/persistence or are otherwise unknown. That's my
> guess anyway. But the current text seems somewhat contradictory, which I
> think could be clarified/fixed.

I agree that the way it's documented "expired_token" would be for when you
know it's expired, whereas "invalid_grant" is a more generic catch all. I
think this section needs to be revisited to clear up this ambiguity. Before
proposing a solution, I want to investigate a little what the existing
implementations are doing around this case.

> In section 5
> <>
> about security considerations for Non-confidential Clients there's a
> pointer to recommendations from Section 8.9 of [RFC8252]
> <>, which is about using
> the "state" parameter in the authorization request to protect against
> cross-app request forgery.  That doesn't seem right or relevant to the
> device flow, does it? Was it intended to point to section 8.5 in RFC8252
> <>? Or something else?
Good catch.

That text was introduced in 04,
draft-ietf-oauth-device-flow-04#section-5.4 and Section 8.9 of the 07 draft
version of native apps at the time was "Client Authentication
which is now Section 8.5 of RFC8252.  I will update this draft to point to
Section 8.5, per the original intent.

> On Tue, May 29, 2018 at 4:20 PM, The IESG <> wrote:
>> The IESG has received a request from the Web Authorization Protocol WG
>> (oauth) to consider the following document: - 'OAuth 2.0 Device Flow for
>> Browserless and Input Constrained Devices'
>>   <draft-ietf-oauth-device-flow-09.txt> as Proposed Standard
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> mailing lists by 2018-06-12. Exceptionally, comments may be
>> sent to instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>> Abstract
>>    This OAuth 2.0 authorization flow for browserless and input
>>    constrained devices, often referred to as the device flow, enables
>>    OAuth clients to request user authorization from devices that have an
>>    Internet connection, but don't have an easy input method (such as a
>>    smart TV, media console, picture frame, or printer), or lack a
>>    suitable browser for a more traditional OAuth flow.  This
>>    authorization flow instructs the user to perform the authorization
>>    request on a secondary device, such as a smartphone.  There is no
>>    requirement for communication between the constrained device and the
>>    user's secondary device.
>> The file can be obtained via
>> IESG discussion can be tracked via
>> No IPR declarations have been submitted directly on this I-D.
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>>     rfc6819: OAuth 2.0 Threat Model and Security Considerations
>> (Informational - IETF stream)
>>     draft-recordon-oauth-v2-device: OAuth 2.0 Device Profile
>>  (None - )
>>     rfc6755: An IETF URN Sub-Namespace for OAuth (Informational - IETF
>> stream)
>> _______________________________________________
>> OAuth mailing list
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*