OAuth                                                         W. Denniss
Internet-Draft                                                    Google
Intended status: Standards Track                              S. Myrseth
Expires: January 19, 2017                                      ForgeRock                              J. Bradley
Expires: August 31, 2017                                   Ping Identity
                                                                M. Jones
                                                               Microsoft
                                                           H. Tschofenig
                                                             ARM Limited
                                                           July 18, 2016
                                                       February 27, 2017

  OAuth 2.0 Device Flow
                    draft-ietf-oauth-device-flow-03 for Browserless and Input Constrained Devices
                    draft-ietf-oauth-device-flow-04

Abstract

   The device

   This OAuth 2.0 authorization flow is suitable for browserless and input
   constrained devices, often referred to as the device flow, enables
   OAuth 2.0 clients executing on to request user authorization from devices that do not have an
   Internet connection, but don't have an easy data-entry input method (e.g., game
   consoles, TVs, picture frames, and (such as a
   smart TV, media hubs), but where console, picture frame, or printer), or lack a
   suitable browser for a more traditional OAuth flow.  This
   authorization flow instructs the end- user has separate access to a user-agent perform the authorization
   request on another computer or
   device (e.g., desktop computer, a laptop, a smart phone, or secondary device, such as a
   tablet). smartphone.  There is no
   requirement for communication between the constrained device and the
   user's secondary device.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 19, August 31, 2017.

Copyright Notice

   Copyright (c) 2016 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   3.  Specification  Protocol  . . . . . . . . . . . . . . . . . . . . . . . .   4 . .   5
     3.1.  Device Authorization Request  . . . . . . . . . . . . . .   4   5
     3.2.  Device Authorization Response . . . . . . . . . . . . . .   5   6
     3.3.  User Instruction  . . . . . . . . . . . . . . . . . . . .   6   7
     3.4.  Device Access Token Request . . . . . . . . . . . . . . . . . .   6   7
     3.5.  Device Access Token Response  . . . . . . . . . . . . . .   8
   4.  Discovery Metadata  . . . . .   7
   4.  IANA . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     5.1.  User Code Brute Forcing . .   8
     4.1.  OAuth URI Registration . . . . . . . . . . . . . . .  10
     5.2.  Device Trustworthiness  . .   8
       4.1.1.  Registry Contents . . . . . . . . . . . . . . .  10
     5.3.  Remote Phishing . . .   8
     4.2.  OAuth Extensions Error Registration . . . . . . . . . . .   8
       4.2.1.  Registry Contents . . . . . . .  10
     5.4.  Non-confidential Clients  . . . . . . . . . . .   8
   5.  Security Considerations . . . . .  10
     5.5.  Non-Visual Code Transmission  . . . . . . . . . . . . . .   9  10
   6.  Normative References  Usability Considerations  . . . . . . . . . . . . . . . . . .  11
     6.1.  User Code Recommendations . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . .   9
   Appendix B.  Document History . . . . . . . . . . . . . . . . .  11
     7.1.  OAuth URI Registration  .   9
   Authors' Addresses . . . . . . . . . . . . . . . .  11
       7.1.1.  Registry Contents . . . . . . .  10

1.  Introduction

   The device flow is suitable for clients executing on devices that do
   not have an easy data-entry method and where the client is incapable
   of receiving incoming requests from the authorization server
   (incapable of acting as an HTTP server).

   Instead of interacting with the end-user's user-agent, the client
   instructs the end-user to use another computer or device and connect
   to the authorization server to approve the access request.  Since the
   client cannot receive incoming requests, it polls the . . . . . . . . . . .  11
     7.2.  OAuth Extensions Error Registration . . . . . . . . . . .  12
       7.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  12
     7.3.  OAuth 2.0 Authorization Server Metadata . . . . . . . . .  12
       7.3.1.  Registry Contents . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This OAuth 2.0 protocol 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.

   The device flow is not intended to replace browser-based OAuth in
   native apps on capable devices (like smartphones).  Those apps should
   follow the practices specified in OAuth 2.0 for Native Apps OAuth 2.0
   for Native Apps [I-D.ietf-oauth-native-apps].

   The only requirements to use this flow are that the device is
   connected to the Internet, and able to make outbound HTTPS requests,
   be able to display or otherwise communicate a URI and code sequence
   to the user, and that the user has a secondary device (e.g., personal
   computer or smartphone) from which to process the request.  There is
   no requirement for two-way communication between the OAuth client and
   the user-agent, enabling a broad range of use-cases.

   Instead of interacting with the end-user's user-agent, the client
   instructs the end-user to use another computer or device and connect
   to the authorization server to approve the access request.  Since the
   client cannot receive incoming requests, it polls the authorization
   server repeatedly until the end-user completes the approval process.

      +----------+                                +----------------+
      |          |>---(A)-- Client Identifier --->|                |
      |          |                                |                |
      |          |<---(B)-- Verification Code, --<|                |
      |          |              User Code,        |                |
      |          |         & Verification URI     |                |
      |  Device  |                                |                |
      |  Client  |         Client Identifier &    |                |
      |          |>---(E)-- Verification Code --->|                |
      |          |    polling...                  |                |
      |          |>---(E)-- Verification Code --->|                |
      |          |                                |  Authorization |
      |          |<---(F)-- Access Token --------<|     Server     |
      +----------+  (w/ Optional Refresh Token)   |                |
            v                                     |                |
            :                                     |                |
           (C) User Code & Verification URI       |                |
            :                                     |                |
            v                                     |                |
      +----------+                                |                |
      | End-user |                                |                |
      |    at    |<---(D)-- User authenticates -->|                |
      |  Browser |                                |                |
      +----------+                                +----------------+

                          Figure 1: Device Flow.

   The device flow illustrated in Figure 1 includes the following steps:

      (A) The client requests access from the authorization server and
      includes its client identifier in the request.

      (B) The authorization server issues a verification code, an end-
      user code, and provides the end-user verification URI.

      (C) The client instructs the end-user to use its user-agent
      (elsewhere) and visit the provided end-user verification URI.  The
      client provides the end-user with the end-user code to enter in
      order to grant access.

      (D) The authorization server authenticates the end-user (via the
      user-agent) and prompts the end-user to grant the client's access
      request.  If the end-user agrees to the client's access request,
      the end-user enters the end-user code provided by the client.  The
      authorization server validates the end-user code provided by the
      end-user.

      (E) While the end-user authorizes (or denies) the client's request
      (D), the client repeatedly until polls the authorization server to find
      out if the end-user completed the end-user authorization step.
      The client includes the verification code and its client
      identifier.

      (F) Assuming the end-user granted access, the end-user completes authorization server
      validates the approval process.

   Note that this device flow does not utilize verification code provided by the client secret.

      +----------+                                +----------------+
      |          |>---(A)-- Client Identifier --->|                |
      |          |                                |                |
      |          |<---(B)-- Verification Code, --<|                |
      |          |              User Code,        |                |
      |          |         & Verification URI     |                |
      | and
      responds back with the access token.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Device Endpoint:
      The authorization server's endpoint capable of issuing
      verification codes, user codes, and verification URLs.

   Device  |                                |                |
      |  Client  |         Client Identifier &    |                |
      |          |>---(E)-- Verification Code --->|                |
      |          |    polling...                  |                |
      |          |>---(E)-- Verification Code --->|                |
      |          |                                |  Authorization |
      |          |<---(F)-- Access Token --------<|     Server     |
      +----------+  (w/ Optional Refresh Token)   |                |
            v                                     |                |
            :                                     |                |
           (C) User Code & Code:
      A short-lived token representing an authorization session.

   End-User Verification URI       |                |
            :                                     |                |
            v                                     |                |
      +----------+                                |                |
      | End-user |                                |                |
      |    at    |<---(D)-- User authenticates -->|                |
      |  Browser |                                |                |
      +----------+                                +----------------+

                          Figure 1: Code:
      A short-lived token which the device displays to the end user, is
      entered by the end-user on the authorization server, and is thus
      used to bind the device to the end-user.

3.  Protocol

3.1.  Device Flow. Authorization Request

   The client initiates the flow by requesting a set of verification
   codes from the authorization server by making an HTTP "POST" request
   to the device flow illustrated in Figure 1 includes endpoint.  The client constructs a request URI by
   adding the following steps:

      (A) parameters to the request:

   response_type
      REQUIRED.  The parameter value MUST be set to "device_code".

   client_id
      REQUIRED.  The client requests identifier as described in Section 2.2 of
      [RFC6749].

   scope
      OPTIONAL.  The scope of the access from request as described by
      Section 3.3 of [RFC6749].

   For example, the authorization server and
      includes its client identifier in makes the following HTTPS request (line
   breaks are for display purposes only):

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded

      response_type=device_code&client_id=459691054427

3.2.  Device Authorization Response

   In response, the request.

      (B) The authorization server issues generates a verification code, code
   and an end-
      user code, end-user code and provides includes them in the HTTP response body
   using the "application/json" format with a 200 (OK) status code.  The
   response contains the following parameters:

   device_code
      REQUIRED.  The verification code.

   user_code
      REQUIRED.  The end-user verification URI.

      (C) code.

   verification_uri
      REQUIRED.  The end-user verification URI on the authorization
      server.  The URI should be short and easy to remember as end-
      users will be asked to manually type it into their user-agent.

   expires_in
      OPTIONAL.  The duration in seconds of the verification code
      lifetime.

   interval
      OPTIONAL.  The minimum amount of time in seconds that the client instructs
      SHOULD wait between polling requests to the end-user token endpoint.

   For example:

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
        "device_code":"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
        "user_code":"WDJB-MJHT",
        "verification_uri":"https://www.example.com/device",
        "expires_in" : 1800,
        "interval": 5
      }

3.3.  User Instruction

   After receiving a successful Authorization Response, the client
   displays or otherwise communicates the "user_code" and the
   "verification_uri" to use its user-agent
      (elsewhere) the end-user, and instructs them to visit the
   URI in a user agent on a secondary device (for example, in a browser
   on their mobile phone), and visit enter the provided end-user verification URI. user code.

   The
      client provides the end-user navigates to the "verification_uri" and authenticates
   with the end-user code to enter in
      order to grant access.

      (D) authorization server.  The authorization server authenticates the end-user (via the
      user-agent) and prompts the
   end-user to grant the client's access
      request.  If the end-user agrees to the client's access request, identify the end-user enters device authorization session by entering the end-user code
   "user_code" provided by the client.  The authorization server validates the end-user code provided by should
   then inform the
      end-user.

      (E) While user about the end-user authorizes (or denies) action they are undertaking, and ask
   them to approve or deny the client's request
      (D), request.  Once the client repeatedly polls user interaction is
   complete, the authorization server informs the user to find
      out if return to their device.

   During this user interaction, the end-user completed device continuously polls the end-user authorization step.
      The client includes token
   endpoint with the verification code and its client
      identifier.

      (F) Assuming "device_code", as detailed in Section 3.4, until
   the end-user granted access, user completes the authorization server
      validates interaction, the verification code provided by expires, or another
   error occurs.

   Authorization servers supporting this specification MUST implement a
   user interaction sequence that starts with the client user navigating to
   "verification_uri" and
      responds back continues with them supplying the access token.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "user_code"
   at some stage during the interaction.  Other than that, the exact
   sequence and
   "OPTIONAL" in this document are implementation of the user interaction is up to be interpreted as described in
   [RFC2119].

   Device Endpoint:

      The the
   authorization server's endpoint capable server, and is out of issuing
      verification codes, user codes, scope of this specification.

   Devices and verification URLs.

   Device Verification Code:

      A short-lived token representing an authorization session.

   End-User Verification Code:

      A short-lived token which the device displays servers MAY negotiate an alternative code
   transmission and user interaction method in addition to the end user, is
      entered one
   described here.  Such an alternative user interaction flow could
   obviate the need for a browser and manual input of the code, for
   example, by using Bluetooth to transmit the end-user on code to the authorization server, and is thus
      used
   server's companion app.  Such interaction methods can utilize this
   protocol, as ultimately, the user just needs to bind identify the device
   authorization session to the end-user.

3.  Specification

3.1. authorization server, however user
   interaction other than via the "verification_uri" is outside the
   scope of this specification.

3.4.  Device Authorization Access Token Request

   The client initiates

   After displaying instructions to the flow by requesting a set of verification
   codes from user, the authorization server by making client makes an HTTP "POST" request Access
   Token Request to the device endpoint.  The client constructs token endpoint with a request URI "grant_type" of
   "urn:ietf:params:oauth:grant-type:device_code".  This is an extension
   grant type (as defined by
   adding Section 4.5 of [RFC6749]) with the
   following parameters to the request:

   response_type: parameters:

   grant_type
      REQUIRED.  The parameter value  Value MUST be set to "device_code".

   client_id: "urn:ietf:params:oauth:grant-
      type:device_code".

   device_code
      REQUIRED.  The client identifier as described device verification code, "device_code" from the
      Device Authorization Response, defined in Section 2.2 of
      [RFC6749].

   scope:

      OPTIONAL.  The scope of 3.2.

   client_id
      REQUIRED, if the access request client is not authenticating with the
      authorization server as described by in Section 3.3 3.2.1. of [RFC6749].

   For example, the client makes the following HTTPS request (line
   breaks are for display purposes only):

      POST /token HTTP/1.1
      Host: server.example.com
      Content-Type: application/x-www-form-urlencoded

      response_type=device_code&client_id=s6BhdRkqt3

3.2.  Device Authorization Response

   In response, the authorization server generates a verification code
   and an end-user code and includes them in

      grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
      &device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8
      &client_id=459691054427

   If the HTTP response body
   using client was issued client credentials (or assigned other
   authentication requirements), the "application/json" format client MUST authenticate with a 200 status code (OK).  The
   response contains the following parameters:

   device_code

      REQUIRED.  The verification code.

   user_code

      REQUIRED.  The end-user verification code.

   verification_uri

      REQUIRED.  The end-user verification URI on the
   authorization
      server.  The URI should be short and easy to remember server as end-
      users will be asked to manually type it into their user-agent.

   expires_in

      OPTIONAL.  The duration described in seconds Section 3.2.1 of [RFC6749].
   Note that there are security implications of the verification code
      lifetime.

   interval

      OPTIONAL. statically distributed
   client credentials, see Section 5.4.

   The minimum amount of time response to this request is defined in seconds that Section 3.5.  Unlike other
   OAuth grant types, it is expected for the client
      SHOULD wait between polling requests to try the token endpoint.

   For example:

      HTTP/1.1 200 OK
      Content-Type: application/json
      Cache-Control: no-store

      {
        "device_code":"74tq5miHKB",
        "user_code":"94248",
        "verification_uri":"http://www.example.com/device",
        "interval"=5
      }

3.3.  User Instruction

   After receiving Access
   Token Request repeatedly in a successful Authorization Response, the client
   displays polling fashion, based on the end-user error
   code and in the end-user verification URI to response.

3.5.  Device Access Token Response

   If the
   end-user, and instructs user has approved the end-user to visit grant, the URI using token endpoint responds with
   a user-
   agent and enter success response defined in Section 5.1 of [RFC6749]; otherwise it
   responds with an error, as defined in Section 5.2 of [RFC6749].

   In addition to the end-user code.

   The end-user manually types error codes defined in Section 5.2 of [RFC6749],
   the provided verification URI and
   authenticates with following error codes are specific for the authorization server. device flow:

   authorization_pending
      The authorization
   server prompts request is still pending as the end-user hasn't
      yet completed the user interaction steps (Section 3.3).  The
      client should repeat the Access Token Request to authorize the client's request token
      endpoint.

   slow_down
      The client is polling too quickly and should back off at a
      reasonable rate.

   expired_token
      The "device_code" has expired.  The client will need to make a new
      Device Authorization Request.

   The error codes "authorization_pending" and "slow_down" are
   considered soft errors.  The client should continue to poll the token
   endpoint by
   entering repeating the end-user code provided Device Token Request (Section 3.4) when
   receiving soft errors, increasing the time between polls if a
   "slow_down" error is received.  Other error codes are considered hard
   errors; the client should stop polling and react accordingly, for
   example, by displaying an error to the client.  Once the end-user
   approves or denies user.

   The interval at which the request, client polls MUST NOT be more frequent than
   the authorization server informs "interval" parameter returned in the
   end-user to return to Device Authorization
   Response (see Section 3.2).

   The assumption of this specification is that the secondary device for further instructions.

3.4.  Device Token Request

   As the
   user is authorizing the request on secondary device which may does not have a way to communicate
   back to the original device, OAuth client.  Only a one-way channel is required to make
   this flow useful in many scenarios.  For example, an HTML application
   on a TV that can only make outbound requests.  If a return channel
   were to exist for the client
   polls chosen user interaction interface, then the token endpoint
   device MAY wait until notified on that channel that the end-user grants or denies user has
   completed the
   request, or action before initiating the token request.  Such
   behavior is, however, outside the scope of this specification.

4.  Discovery Metadata

   Support for the device code expires.

   The client polls at reasonable interval which MUST NOT exceed flow MAY be declared in the
   minimum interval provided by OAuth 2.0
   Authorization Server Metadata [I-D.ietf-oauth-discovery] with the
   following metadata:

   device_authorization_endpoint
      OPTIONAL.  URL of the authorization server via server's device authorization
      endpoint defined in Section 3.1.

5.  Security Considerations
5.1.  User Code Brute Forcing

   Since the
   "interval" parameter (if provided). user code is typed by the user, the entropy is typically
   less than would be used for the device code or other OAuth bearer
   token types.  It is therefore recommended that the server rate-limit
   user code attempts.  The client user code SHOULD have enough entropy that
   when combined with rate limiting makes a request to brute-force attack
   infeasible.

5.2.  Device Trustworthiness

   Unlike other native application OAuth 2.0 flows, the token endpoint by sending device
   requesting the
   following parameters using authorization is not the "application/x-www-form-urlencoded"
   format per Appendix B with a character encoding of UTF-8 in same as the HTTP
   request entity-body:

   grant_type

      REQUIRED.  Value MUST be set to "urn:ietf:params:oauth:grant-
      type:device_code".

   device_code

      REQUIRED.  The device verification code, "device_code" that the
   user grants access from.  Thus, signals from the
      Device Authorization Response, defined in Section 3.2.

   client_id

      REQUIRED, if approving user's
   session and device are not relevant to the trustworthiness of the
   client device.

5.3.  Remote Phishing

   It is not authenticating with possible for the
      authorization server as described device flow to be initiated on a device in Section 3.2.1. of [RFC6749] an
   attacker's possession.  For example, the client makes the following HTTPS request (line
   breaks are for display purposes only):

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded

   grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code&device_code=pxDoJ3Bt9WVMTXfDATLkxJ9u
   &client_id=459691054427

   Note that unlike attacker they might send an
   email instructing the Access Token Request for target user to visit the authorization_code
   grant type defined in Section 4.1.3 of [RFC6749] verification URL and
   enter the "redirect_uri"
   parameter user code.  To mitigate such an attack, it is NOT REQUIRED as part of this request.

   If RECOMMENDED
   to inform the client was issued client credentials (or assigned other
   authentication requirements), user that they are authorizing a device during the client MUST authenticate with user
   interaction step (see Section 3.3), and to confirm that the
   authorization server as described device is
   in Section 3.2.1 of [RFC6749].

3.5.  Device Token Response

   If their possession.

   The user code needs to have a long enough lifetime to be useable
   (allowing the user has approved to retrieve their secondary device, navigate to
   the grant, verification URI, login, etc.), but should be sufficiently short
   to limit the token endpoint responds with usability of a success response defined code obtained for phishing.  This doesn't
   prevent a phisher presenting a fresh token, particularly in Section 5.1 of [RFC6749] otherwise, it
   responds the case
   they are interacting with an error, as defined the user in Section 5.2 real time, but it does limit
   the viability of [RFC6749].

   In addition codes sent over email or SMS.

5.4.  Non-confidential Clients

   Most device clients are incapable of being confidential clients, as
   secrets that are statically included as part of an app distributed to
   multiple users cannot be considered confidential.  For such clients,
   the error codes defined in recommendations of Section 5.2 5.3.1 of [RFC6749], [RFC6819] and Section 8.9 of
   [I-D.ietf-oauth-native-apps] apply.

5.5.  Non-Visual Code Transmission

   There is no requirement that the following error codes are specific for user code be displayed by the device flow:

   authorization_pending

      The authorization request is still pending
   visually.  Other methods of one-way communication can potentially be
   used, such as the end-user hasn't
      yet visited the authorization server and entered text-to-speech audio, or Bluetooth Low Energy.  To
   mitigate an attack in which a malicious user can bootstrap their
      verification code.

   slow_down
      The client
   credentials on a device not in their control, it is RECOMMENDED that
   any chosen communication channel only be accessible by people in
   close proximity.  E.g., users who can see, or hear the device, or
   within range of a short-range wireless signal.

6.  Usability Considerations

   This section is polling too quickly and should back off at a
      reasonable rate.

   expired_token

      The device_code has expired.  The client non-normative discussion of usability
   considerations.

6.1.  User Code Recommendations

   For many users, their nearest Internet-connected device will need to make a new
      Device Authorization Request.

   The error code "authorization_pending" be their
   mobile phone, and "slow_down" typically these devices offer input methods that
   are considered
   soft errors.  The more time consuming than a computer keyboard to change the client case
   or input numbers.  To improve usability (improving entry speed, and
   reducing retries), these limitations should continue to poll be taken into account
   when receiving
   "authorization_pending" errors, reducing selecting the interval if a
   "slow_down" error user-code character set.

   One way to improve input speed is received.  Other error codes are considered hard
   errors, to restrict the client should stop polling character set to
   case-insensitive A-Z characters, with no digits.  These characters
   can typically be entered on a mobile keyboard without using modifier
   keys.  Further removing the I and react accordingly, for
   example, by displaying an error O characters due to potential
   confusion with numbers results in the user.

4. base-24 character set:
   "ABCDEFGHJKLMNPQRSTUVWXYZ".  Dashes or other punctuation may be
   included for readability.

   An example user code following this guideline, with 24^8 bits of
   entropy, is "WDJB-MJHT".

   The server should ignore any characters like punctuation that are not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.

7.  IANA Considerations

4.1.

7.1.  OAuth URI Registration

   This specification registers the following values in the IANA "OAuth
   URI" registry [IANA.OAuth.Parameters] established by [RFC6755].

4.1.1.

7.1.1.  Registry Contents

   o  URN: urn:ietf:params:oauth:grant-type:device_code
   o  Common Name: Device flow grant type for OAuth 2.0
   o  Change controller: IESG
   o  Specification Document: Section 3.1 of [[ this specification ]]

4.2.

7.2.  OAuth Extensions Error Registration

   This specification registers the following values in the IANA "OAuth
   Extensions Error Registry" registry [IANA.OAuth.Parameters]
   established by [RFC6749].

4.2.1.

7.2.1.  Registry Contents

   o  Error name: authorization_pending
   o  Error usage location: Token endpoint response
   o  Related protocol extension: [[ this specification ]]
   o  Change controller: IETF
   o  Specification Document: Section 3.5 of [[ this specification ]]

   o  Error name: slow_down
   o  Error usage location: Token endpoint response
   o  Related protocol extension: [[ this specification ]]
   o  Change controller: IETF
   o  Specification Document: Section 3.5 of [[ this specification ]]

   o  Error name: expired_token
   o  Error usage location: Token endpoint response
   o  Related protocol extension: [[ this specification ]]
   o  Change controller: IETF
   o  Specification Document: Section 3.5 of [[ this specification ]]

5.  Security Considerations

   TBD

6.

7.3.  OAuth 2.0 Authorization Server Metadata

   This specification registers the following values in the IANA "OAuth
   2.0 Authorization Server Metadata" registry [IANA.OAuth.Parameters]
   established by [I-D.ietf-oauth-discovery].

7.3.1.  Registry Contents

   o  Metadata name: device_authorization_endpoint
   o  Metadata Description: The Device Authorization Endpoint.
   o  Change controller: IESG
   o  Specification Document: Section 4 of [[ this specification ]]

8.  Normative References

   [I-D.ietf-oauth-discovery]
              Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", draft-ietf-oauth-
              discovery-05 (work in progress), January 2017.

   [I-D.ietf-oauth-native-apps]
              Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
              draft-ietf-oauth-native-apps-07 (work in progress),
              January 2017.

   [IANA.OAuth.Parameters]
              IANA, "OAuth Parameters",
              <http://www.iana.org/assignments/oauth-parameters>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <http://www.rfc-editor.org/info/rfc6749>.

   [RFC6755]  Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
              for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
              <http://www.rfc-editor.org/info/rfc6755>.

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              DOI 10.17487/RFC6819, January 2013,
              <http://www.rfc-editor.org/info/rfc6819>.

Appendix A.  Acknowledgements

   The -00 version of this document was based on draft-recordon-oauth-
   v2-device edited by David Recordon and Brent Goldman.  The content of
   that document was initially part of the OAuth 2.0 protocol
   specification but was later removed due to the lack of sufficient
   deployment expertise at that time.  We would therefore also like to
   thank the OAuth working group for their work on the initial content
   of this specification through 2010.

   The following individuals contributed ideas, feedback, and wording
   that shaped and formed the final specification:

   Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein
   Myrseth, and Simon Moffatt.

Appendix B.  Document History

   [[ to be removed by the RFC Editor before publication as an RFC ]]

   -04
   o  Security & Usability sections.  OAuth Discovery Metadata.

   -03

   o  device_code is now a URN.  Added IANA Considerations

   -02

   o  Added token request & response specification.

   -01

   o  Applied spelling and grammar corrections and added the Document
      History appendix.

   -00

   o  Initial working group draft based on draft-recordon-oauth-
      v2-device.

Authors' Addresses

   William Denniss
   Google
   1600 Amphitheatre Pkwy
   Mountain View, CA  94043
   USA

   Phone: +1 650-253-0000

   Email: wdenniss@google.com
   URI:   http://google.com/

   Stein Myrseth
   ForgeRock
   Lysaker torg 2
   Lysaker  1366
   NORWAY

   Email: stein.myrseth@forgerock.com   http://wdenniss.com/device-flow

   John Bradley
   Ping Identity

   Email: ve7jtb@ve7jtb.com
   URI:   http://www.thread-safe.com/

   Michael B. Jones
   Microsoft

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/
   Hannes Tschofenig
   ARM Limited
   Austria

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at