idnits 2.17.00 (12 Aug 2021) /tmp/idnits40562/draft-ietf-oauth-device-flow-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2017) is 1815 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-oauth-discovery has been published as RFC 8414 == Outdated reference: draft-ietf-oauth-native-apps has been published as RFC 8252 ** Downref: Normative reference to an Informational RFC: RFC 6755 ** Downref: Normative reference to an Informational RFC: RFC 6819 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth W. Denniss 3 Internet-Draft Google 4 Intended status: Standards Track J. Bradley 5 Expires: December 2, 2017 Ping Identity 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 ARM Limited 10 May 31, 2017 12 OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 13 draft-ietf-oauth-device-flow-06 15 Abstract 17 This OAuth 2.0 authorization flow for browserless and input 18 constrained devices, often referred to as the device flow, enables 19 OAuth clients to request user authorization from devices that have an 20 Internet connection, but don't have an easy input method (such as a 21 smart TV, media console, picture frame, or printer), or lack a 22 suitable browser for a more traditional OAuth flow. This 23 authorization flow instructs the user to perform the authorization 24 request on a secondary device, such as a smartphone. There is no 25 requirement for communication between the constrained device and the 26 user's secondary device. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 2, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Device Authorization Request . . . . . . . . . . . . . . 5 66 3.2. Device Authorization Response . . . . . . . . . . . . . . 6 67 3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 7 68 3.3.1. Optimization for Non-textual Verification URIs . . . 8 69 3.4. Device Access Token Request . . . . . . . . . . . . . . . 8 70 3.5. Device Access Token Response . . . . . . . . . . . . . . 9 71 4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 10 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 11 74 5.2. Device Trustworthiness . . . . . . . . . . . . . . . . . 11 75 5.3. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 11 76 5.4. Non-confidential Clients . . . . . . . . . . . . . . . . 11 77 5.5. Non-Visual Code Transmission . . . . . . . . . . . . . . 12 78 6. Usability Considerations . . . . . . . . . . . . . . . . . . 12 79 6.1. User Code Recommendations . . . . . . . . . . . . . . . . 12 80 6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 12 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 13 83 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 13 84 7.2. OAuth Extensions Error Registration . . . . . . . . . . . 13 85 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 13 86 7.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . . 14 87 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 14 88 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 89 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 90 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 This OAuth 2.0 protocol flow for browserless and input constrained 96 devices, often referred to as the device flow, enables OAuth clients 97 to request user authorization from devices that have an internet 98 connection, but don't have an easy input method (such as a smart TV, 99 media console, picture frame, or printer), or lack a suitable browser 100 for a more traditional OAuth flow. This authorization flow instructs 101 the user to perform the authorization request on a secondary device, 102 such as a smartphone. 104 The device flow is not intended to replace browser-based OAuth in 105 native apps on capable devices (like smartphones). Those apps should 106 follow the practices specified in OAuth 2.0 for Native Apps OAuth 2.0 107 for Native Apps [I-D.ietf-oauth-native-apps]. 109 The only requirements to use this flow are that the device is 110 connected to the Internet, and able to make outbound HTTPS requests, 111 be able to display or otherwise communicate a URI and code sequence 112 to the user, and that the user has a secondary device (e.g., personal 113 computer or smartphone) from which to process the request. There is 114 no requirement for two-way communication between the OAuth client and 115 the user-agent, enabling a broad range of use-cases. 117 Instead of interacting with the end-user's user-agent, the client 118 instructs the end-user to use another computer or device and connect 119 to the authorization server to approve the access request. Since the 120 client cannot receive incoming requests, it polls the authorization 121 server repeatedly until the end-user completes the approval process. 123 +----------+ +----------------+ 124 | |>---(A)-- Client Identifier --->| | 125 | | | | 126 | |<---(B)-- Verification Code, --<| | 127 | | User Code, | | 128 | | & Verification URI | | 129 | Device | | | 130 | Client | Client Identifier & | | 131 | |>---(E)-- Verification Code --->| | 132 | | polling... | | 133 | |>---(E)-- Verification Code --->| | 134 | | | Authorization | 135 | |<---(F)-- Access Token --------<| Server | 136 +----------+ (w/ Optional Refresh Token) | | 137 v | | 138 : | | 139 (C) User Code & Verification URI | | 140 : | | 141 v | | 142 +----------+ | | 143 | End-user | | | 144 | at |<---(D)-- User authenticates -->| | 145 | Browser | | | 146 +----------+ +----------------+ 148 Figure 1: Device Flow. 150 The device flow illustrated in Figure 1 includes the following steps: 152 (A) The client requests access from the authorization server and 153 includes its client identifier in the request. 155 (B) The authorization server issues a verification code, an end- 156 user code, and provides the end-user verification URI. 158 (C) The client instructs the end-user to use its user-agent 159 (elsewhere) and visit the provided end-user verification URI. The 160 client provides the end-user with the end-user code to enter in 161 order to grant access. 163 (D) The authorization server authenticates the end-user (via the 164 user-agent) and prompts the end-user to grant the client's access 165 request. If the end-user agrees to the client's access request, 166 the end-user enters the end-user code provided by the client. The 167 authorization server validates the end-user code provided by the 168 end-user. 170 (E) While the end-user authorizes (or denies) the client's request 171 (D), the client repeatedly polls the authorization server to find 172 out if the end-user completed the end-user authorization step. 173 The client includes the verification code and its client 174 identifier. 176 (F) Assuming the end-user granted access, the authorization server 177 validates the verification code provided by the client and 178 responds back with the access token. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in 185 [RFC2119]. 187 Device Authorization Endpoint: 188 The authorization server's endpoint capable of issuing device 189 verification codes, user codes, and verification URLs. 191 Device Verification Code: 192 A short-lived token representing an authorization session. 194 End-User Verification Code: 195 A short-lived token which the device displays to the end user, is 196 entered by the end-user on the authorization server, and is thus 197 used to bind the device to the end-user. 199 3. Protocol 201 3.1. Device Authorization Request 203 The client initiates the flow by requesting a set of verification 204 codes from the authorization server by making an HTTP "POST" request 205 to the device authorization endpoint. The client constructs the 206 request with the following parameters, encoded with the "application/ 207 x-www-form-urlencoded" content type: 209 client_id 210 REQUIRED. The client identifier as described in Section 2.2 of 211 [RFC6749]. 213 scope 214 OPTIONAL. The scope of the access request as described by 215 Section 3.3 of [RFC6749]. 217 For example, the client makes the following HTTPS request (line 218 breaks are for display purposes only): 220 POST /device_authorization HTTP/1.1 221 Host: server.example.com 222 Content-Type: application/x-www-form-urlencoded 224 client_id=459691054427 226 Parameters sent without a value MUST be treated as if they were 227 omitted from the request. The authorization server MUST ignore 228 unrecognized request parameters. Request and response parameters 229 MUST NOT be included more than once. 231 3.2. Device Authorization Response 233 In response, the authorization server generates a device verification 234 code and an end-user code that are valid for a limited time, and 235 includes them in the HTTP response body using the "application/json" 236 format with a 200 (OK) status code. The response contains the 237 following parameters: 239 device_code 240 REQUIRED. The device verification code. 242 user_code 243 REQUIRED. The end-user verification code. 245 verification_uri 246 REQUIRED. The end-user verification URI on the authorization 247 server. The URI should be short and easy to remember as end- 248 users will be asked to manually type it into their user-agent. 250 expires_in 251 OPTIONAL. The lifetime in seconds of the "device_code" and 252 "user_code". 254 interval 255 OPTIONAL. The minimum amount of time in seconds that the client 256 SHOULD wait between polling requests to the token endpoint. 258 For example: 260 HTTP/1.1 200 OK 261 Content-Type: application/json 262 Cache-Control: no-store 264 { 265 "device_code":"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", 266 "user_code":"WDJB-MJHT", 267 "verification_uri":"https://www.example.com/device", 268 "expires_in" : 1800, 269 "interval": 5 270 } 272 3.3. User Interaction 274 After receiving a successful Authorization Response, the client 275 displays or otherwise communicates the "user_code" and the 276 "verification_uri" to the end-user, and instructs them to visit the 277 URI in a user agent on a secondary device (for example, in a browser 278 on their mobile phone), and enter the user code. 280 +-----------------------------------------------+ 281 | | 282 | Using a browser on another device, visit: | 283 | https://example.com/device | 284 | | 285 | And enter the code: | 286 | WDJB-MJHT | 287 | | 288 +-----------------------------------------------+ 290 Figure 2: Example User Instruction 292 The authorizing user navigates to the "verification_uri" and 293 authenticates with the authorization server in a secure TLS-protected 294 session. The authorization server prompts the end-user to identify 295 the device authorization session by entering the "user_code" provided 296 by the client. The authorization server should then inform the user 297 about the action they are undertaking, and ask them to approve or 298 deny the request. Once the user interaction is complete, the server 299 informs the user to return to their device. 301 During the user interaction, the device continuously polls the token 302 endpoint with the "device_code", as detailed in Section 3.4, until 303 the user completes the interaction, the code expires, or another 304 error occurs. 306 Authorization servers supporting this specification MUST implement a 307 user interaction sequence that starts with the user navigating to 308 "verification_uri" and continues with them supplying the "user_code" 309 at some stage during the interaction. Other than that, the exact 310 sequence and implementation of the user interaction is up to the 311 authorization server, and is out of scope of this specification. 313 3.3.1. Optimization for Non-textual Verification URIs 315 Clients MAY present the verification URI in a non-textual manner 316 using any method that results in the browser being opened with the 317 URI, such as with QR codes, or NFC, to save the user typing the URI. 318 For usability reasons, it is RECOMMENDED for clients to still display 319 the unmodified verification URI for users not able to use such a 320 shortcut. 322 To optimize the user interaction for such non-textual verification 323 URI transmission, clients MAY include the user code as part of the 324 verification URI using the URI parameter "user_code". 326 An example verification URI with the user code included: 328 https://example.com/device?user_code=WDJB-MJHT 330 When the user code is included in the verification URI in this way, 331 it is considered as a hint to the authorization server to enable 332 potential optimizations. The authorization server MAY use this hint 333 to optimize the user interaction (such as by removing the need for 334 the user to type the code), it MAY also ignore it completely. The 335 client MUST still display the user code textually, for authorization 336 servers that require users to input the user code manually, or 337 otherwise use the user code as part of a visual confirmation step. 339 This optimization is intended for non-textual transmission of the 340 verification URI, it is NOT RECOMMENDED to include the user code in 341 verification URIs shown textually, as this increases the length and 342 complexity of the URI that the user must type. 344 3.4. Device Access Token Request 346 After displaying instructions to the user, the client makes an Access 347 Token Request to the token endpoint with a "grant_type" of 348 "urn:ietf:params:oauth:grant-type:device_code". This is an extension 349 grant type (as defined by Section 4.5 of [RFC6749]) with the 350 following parameters: 352 grant_type 353 REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant- 354 type:device_code". 356 device_code 357 REQUIRED. The device verification code, "device_code" from the 358 Device Authorization Response, defined in Section 3.2. 360 client_id 361 REQUIRED, if the client is not authenticating with the 362 authorization server as described in Section 3.2.1. of [RFC6749]. 364 For example, the client makes the following HTTPS request (line 365 breaks are for display purposes only): 367 POST /token HTTP/1.1 368 Host: server.example.com 369 Content-Type: application/x-www-form-urlencoded 371 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code 372 &device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8 373 &client_id=459691054427 375 If the client was issued client credentials (or assigned other 376 authentication requirements), the client MUST authenticate with the 377 authorization server as described in Section 3.2.1 of [RFC6749]. 378 Note that there are security implications of statically distributed 379 client credentials, see Section 5.4. 381 The response to this request is defined in Section 3.5. Unlike other 382 OAuth grant types, it is expected for the client to try the Access 383 Token Request repeatedly in a polling fashion, based on the error 384 code in the response. 386 3.5. Device Access Token Response 388 If the user has approved the grant, the token endpoint responds with 389 a success response defined in Section 5.1 of [RFC6749]; otherwise it 390 responds with an error, as defined in Section 5.2 of [RFC6749]. 392 In addition to the error codes defined in Section 5.2 of [RFC6749], 393 the following error codes are specific for the device flow: 395 authorization_pending 396 The authorization request is still pending as the end-user hasn't 397 yet completed the user interaction steps (Section 3.3). The 398 client should repeat the Access Token Request to the token 399 endpoint. 401 slow_down 402 The client is polling too quickly and should back off at a 403 reasonable rate. 405 expired_token 406 The "device_code" has expired. The client will need to make a new 407 Device Authorization Request. 409 The error codes "authorization_pending" and "slow_down" are 410 considered soft errors. The client should continue to poll the token 411 endpoint by repeating the Device Token Request (Section 3.4) when 412 receiving soft errors, increasing the time between polls if a 413 "slow_down" error is received. Other error codes are considered hard 414 errors; the client should stop polling and react accordingly, for 415 example, by displaying an error to the user. 417 If the verification codes have expired, the server SHOULD respond 418 with the standard OAuth error "invalid_grant". Clients MAY then 419 choose to start a new device authorization session. 421 The interval at which the client polls MUST NOT be more frequent than 422 the "interval" parameter returned in the Device Authorization 423 Response (see Section 3.2). 425 The assumption of this specification is that the secondary device the 426 user is authorizing the request on does not have a way to communicate 427 back to the OAuth client. Only a one-way channel is required to make 428 this flow useful in many scenarios. For example, an HTML application 429 on a TV that can only make outbound requests. If a return channel 430 were to exist for the chosen user interaction interface, then the 431 device MAY wait until notified on that channel that the user has 432 completed the action before initiating the token request. Such 433 behavior is, however, outside the scope of this specification. 435 4. Discovery Metadata 437 Support for the device flow MAY be declared in the OAuth 2.0 438 Authorization Server Metadata [I-D.ietf-oauth-discovery] with the 439 following metadata: 441 device_authorization_endpoint 442 OPTIONAL. URL of the authorization server's device authorization 443 endpoint defined in Section 3.1. 445 5. Security Considerations 446 5.1. User Code Brute Forcing 448 Since the user code is typed by the user, the entropy is typically 449 less than would be used for the device code or other OAuth bearer 450 token types. It is therefore recommended that the server rate-limit 451 user code attempts. The user code SHOULD have enough entropy that 452 when combined with rate limiting makes a brute-force attack 453 infeasible. 455 5.2. Device Trustworthiness 457 Unlike other native application OAuth 2.0 flows, the device 458 requesting the authorization is not the same as the device that the 459 user grants access from. Thus, signals from the approving user's 460 session and device are not relevant to the trustworthiness of the 461 client device. 463 5.3. Remote Phishing 465 It is possible for the device flow to be initiated on a device in an 466 attacker's possession. For example, the attacker might send an email 467 instructing the target user to visit the verification URL and enter 468 the user code. To mitigate such an attack, it is RECOMMENDED to 469 inform the user that they are authorizing a device during the user 470 interaction step (see Section 3.3), and to confirm that the device is 471 in their possession. 473 For authorization servers that support the option specified in 474 Section 3.3.1 for the client to append the user code to the 475 authorization URI, it is particularly important to confirm that the 476 device is in the user's possession, as the user no longer has to type 477 the code manually. One possibility is to display the code during the 478 authorization flow, and asking the user to verify that the same code 479 is being displayed on the device they are setting up. 481 The user code needs to have a long enough lifetime to be useable 482 (allowing the user to retrieve their secondary device, navigate to 483 the verification URI, login, etc.), but should be sufficiently short 484 to limit the usability of a code obtained for phishing. This doesn't 485 prevent a phisher presenting a fresh token, particularly in the case 486 they are interacting with the user in real time, but it does limit 487 the viability of codes sent over email or SMS. 489 5.4. Non-confidential Clients 491 Most device clients are incapable of being confidential clients, as 492 secrets that are statically included as part of an app distributed to 493 multiple users cannot be considered confidential. For such clients, 494 the recommendations of Section 5.3.1 of [RFC6819] and Section 8.9 of 495 [I-D.ietf-oauth-native-apps] apply. 497 5.5. Non-Visual Code Transmission 499 There is no requirement that the user code be displayed by the device 500 visually. Other methods of one-way communication can potentially be 501 used, such as text-to-speech audio, or Bluetooth Low Energy. To 502 mitigate an attack in which a malicious user can bootstrap their 503 credentials on a device not in their control, it is RECOMMENDED that 504 any chosen communication channel only be accessible by people in 505 close proximity. E.g., users who can see, or hear the device, or 506 within range of a short-range wireless signal. 508 6. Usability Considerations 510 This section is a non-normative discussion of usability 511 considerations. 513 6.1. User Code Recommendations 515 For many users, their nearest Internet-connected device will be their 516 mobile phone, and typically these devices offer input methods that 517 are more time consuming than a computer keyboard to change the case 518 or input numbers. To improve usability (improving entry speed, and 519 reducing retries), these limitations should be taken into account 520 when selecting the user-code character set. 522 One way to improve input speed is to restrict the character set to 523 case-insensitive A-Z characters, with no digits. These characters 524 can typically be entered on a mobile keyboard without using modifier 525 keys. Further removing vowels to avoid randomly creation valid words 526 results in the base-20 character set: "BCDFGHJKLMNPQRSTVWXZ". Dashes 527 or other punctuation may be included for readability. 529 An example user code following this guideline, with an entropy of 530 20^8, is "WDJB-MJHT". 532 The server should ignore any characters like punctuation that are not 533 in the user-code character set. Provided that the character set 534 doesn't include characters of different case, the comparison should 535 be case insensitive. 537 6.2. Non-Browser User Interaction 539 Devices and authorization servers MAY negotiate an alternative code 540 transmission and user interaction method in addition to the one 541 described in Section 3.3. Such an alternative user interaction flow 542 could obviate the need for a browser and manual input of the code, 543 for example, by using Bluetooth to transmit the code to the 544 authorization server's companion app. Such interaction methods can 545 utilize this protocol, as ultimately, the user just needs to identify 546 the authorization session to the authorization server; however, user 547 interaction other than via the "verification_uri" is outside the 548 scope of this specification. 550 7. IANA Considerations 552 7.1. OAuth URI Registration 554 This specification registers the following values in the IANA "OAuth 555 URI" registry [IANA.OAuth.Parameters] established by [RFC6755]. 557 7.1.1. Registry Contents 559 o URN: urn:ietf:params:oauth:grant-type:device_code 560 o Common Name: Device flow grant type for OAuth 2.0 561 o Change controller: IESG 562 o Specification Document: Section 3.1 of [[ this specification ]] 564 7.2. OAuth Extensions Error Registration 566 This specification registers the following values in the IANA "OAuth 567 Extensions Error Registry" registry [IANA.OAuth.Parameters] 568 established by [RFC6749]. 570 7.2.1. Registry Contents 572 o Error name: authorization_pending 573 o Error usage location: Token endpoint response 574 o Related protocol extension: [[ this specification ]] 575 o Change controller: IETF 576 o Specification Document: Section 3.5 of [[ this specification ]] 578 o Error name: slow_down 579 o Error usage location: Token endpoint response 580 o Related protocol extension: [[ this specification ]] 581 o Change controller: IETF 582 o Specification Document: Section 3.5 of [[ this specification ]] 584 o Error name: expired_token 585 o Error usage location: Token endpoint response 586 o Related protocol extension: [[ this specification ]] 587 o Change controller: IETF 588 o Specification Document: Section 3.5 of [[ this specification ]] 590 7.3. OAuth 2.0 Authorization Server Metadata 592 This specification registers the following values in the IANA "OAuth 593 2.0 Authorization Server Metadata" registry [IANA.OAuth.Parameters] 594 established by [I-D.ietf-oauth-discovery]. 596 7.3.1. Registry Contents 598 o Metadata name: device_authorization_endpoint 599 o Metadata Description: The Device Authorization Endpoint. 600 o Change controller: IESG 601 o Specification Document: Section 4 of [[ this specification ]] 603 8. Normative References 605 [I-D.ietf-oauth-discovery] 606 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 607 Authorization Server Metadata", draft-ietf-oauth- 608 discovery-05 (work in progress), January 2017. 610 [I-D.ietf-oauth-native-apps] 611 Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 612 draft-ietf-oauth-native-apps-07 (work in progress), 613 January 2017. 615 [IANA.OAuth.Parameters] 616 IANA, "OAuth Parameters", 617 . 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, 621 DOI 10.17487/RFC2119, March 1997, 622 . 624 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 625 RFC 6749, DOI 10.17487/RFC6749, October 2012, 626 . 628 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 629 for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, 630 . 632 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 633 Threat Model and Security Considerations", RFC 6819, 634 DOI 10.17487/RFC6819, January 2013, 635 . 637 Appendix A. Acknowledgements 639 The -00 version of this document was based on draft-recordon-oauth- 640 v2-device edited by David Recordon and Brent Goldman. The content of 641 that document was initially part of the OAuth 2.0 protocol 642 specification but was later removed due to the lack of sufficient 643 deployment expertise at that time. We would therefore also like to 644 thank the OAuth working group for their work on the initial content 645 of this specification through 2010. 647 The following individuals contributed ideas, feedback, and wording 648 that shaped and formed the final specification: 650 Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein 651 Myrseth, Simon Moffatt, Brian Campbell, James Manger, and Justin 652 Richer. 654 Appendix B. Document History 656 [[ to be removed by the RFC Editor before publication as an RFC ]] 658 -06 660 o Clarified usage of the "user_code" URI parameter optimization 661 following the IETF98 working group discussion. 663 -05 665 o response_type parameter removed from authorization request. 666 o Added option for clients to include the user_code on the 667 verification URI. 668 o Clarified token expiry, and other nits. 670 -04 672 o Security & Usability sections. OAuth Discovery Metadata. 674 -03 676 o device_code is now a URN. Added IANA Considerations 678 -02 680 o Added token request & response specification. 682 -01 683 o Applied spelling and grammar corrections and added the Document 684 History appendix. 686 -00 688 o Initial working group draft based on draft-recordon-oauth- 689 v2-device. 691 Authors' Addresses 693 William Denniss 694 Google 695 1600 Amphitheatre Pkwy 696 Mountain View, CA 94043 697 USA 699 Email: wdenniss@google.com 700 URI: http://wdenniss.com/device-flow 702 John Bradley 703 Ping Identity 705 Email: ve7jtb@ve7jtb.com 706 URI: http://www.thread-safe.com/ 708 Michael B. Jones 709 Microsoft 711 Email: mbj@microsoft.com 712 URI: http://self-issued.info/ 714 Hannes Tschofenig 715 ARM Limited 716 Austria 718 Email: Hannes.Tschofenig@gmx.net 719 URI: http://www.tschofenig.priv.at