idnits 2.17.00 (12 Aug 2021) /tmp/idnits39848/draft-ietf-oauth-device-flow-05.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 (March 13, 2017) is 1894 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: September 14, 2017 Ping Identity 6 M. Jones 7 Microsoft 8 H. Tschofenig 9 ARM Limited 10 March 13, 2017 12 OAuth 2.0 Device Flow for Browserless and Input Constrained Devices 13 draft-ietf-oauth-device-flow-05 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 September 14, 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 Instruction . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Device Access Token Request . . . . . . . . . . . . . . . 8 69 3.5. Device Access Token Response . . . . . . . . . . . . . . 9 70 4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 10 73 5.2. Device Trustworthiness . . . . . . . . . . . . . . . . . 10 74 5.3. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. Non-confidential Clients . . . . . . . . . . . . . . . . 11 76 5.5. Non-Visual Code Transmission . . . . . . . . . . . . . . 11 77 6. Usability Considerations . . . . . . . . . . . . . . . . . . 11 78 6.1. User Code Recommendations . . . . . . . . . . . . . . . . 11 79 6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 12 82 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 83 7.2. OAuth Extensions Error Registration . . . . . . . . . . . 12 84 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 85 7.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . . 13 86 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 13 87 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 89 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 This OAuth 2.0 protocol flow for browserless and input constrained 95 devices, often referred to as the device flow, enables OAuth clients 96 to request user authorization from devices that have an internet 97 connection, but don't have an easy input method (such as a smart TV, 98 media console, picture frame, or printer), or lack a suitable browser 99 for a more traditional OAuth flow. This authorization flow instructs 100 the user to perform the authorization request on a secondary device, 101 such as a smartphone. 103 The device flow is not intended to replace browser-based OAuth in 104 native apps on capable devices (like smartphones). Those apps should 105 follow the practices specified in OAuth 2.0 for Native Apps OAuth 2.0 106 for Native Apps [I-D.ietf-oauth-native-apps]. 108 The only requirements to use this flow are that the device is 109 connected to the Internet, and able to make outbound HTTPS requests, 110 be able to display or otherwise communicate a URI and code sequence 111 to the user, and that the user has a secondary device (e.g., personal 112 computer or smartphone) from which to process the request. There is 113 no requirement for two-way communication between the OAuth client and 114 the user-agent, enabling a broad range of use-cases. 116 Instead of interacting with the end-user's user-agent, the client 117 instructs the end-user to use another computer or device and connect 118 to the authorization server to approve the access request. Since the 119 client cannot receive incoming requests, it polls the authorization 120 server repeatedly until the end-user completes the approval process. 122 +----------+ +----------------+ 123 | |>---(A)-- Client Identifier --->| | 124 | | | | 125 | |<---(B)-- Verification Code, --<| | 126 | | User Code, | | 127 | | & Verification URI | | 128 | Device | | | 129 | Client | Client Identifier & | | 130 | |>---(E)-- Verification Code --->| | 131 | | polling... | | 132 | |>---(E)-- Verification Code --->| | 133 | | | Authorization | 134 | |<---(F)-- Access Token --------<| Server | 135 +----------+ (w/ Optional Refresh Token) | | 136 v | | 137 : | | 138 (C) User Code & Verification URI | | 139 : | | 140 v | | 141 +----------+ | | 142 | End-user | | | 143 | at |<---(D)-- User authenticates -->| | 144 | Browser | | | 145 +----------+ +----------------+ 147 Figure 1: Device Flow. 149 The device flow illustrated in Figure 1 includes the following steps: 151 (A) The client requests access from the authorization server and 152 includes its client identifier in the request. 154 (B) The authorization server issues a verification code, an end- 155 user code, and provides the end-user verification URI. 157 (C) The client instructs the end-user to use its user-agent 158 (elsewhere) and visit the provided end-user verification URI. The 159 client provides the end-user with the end-user code to enter in 160 order to grant access. 162 (D) The authorization server authenticates the end-user (via the 163 user-agent) and prompts the end-user to grant the client's access 164 request. If the end-user agrees to the client's access request, 165 the end-user enters the end-user code provided by the client. The 166 authorization server validates the end-user code provided by the 167 end-user. 169 (E) While the end-user authorizes (or denies) the client's request 170 (D), the client repeatedly polls the authorization server to find 171 out if the end-user completed the end-user authorization step. 172 The client includes the verification code and its client 173 identifier. 175 (F) Assuming the end-user granted access, the authorization server 176 validates the verification code provided by the client and 177 responds back with the access token. 179 2. Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 [RFC2119]. 186 Device Authorization Endpoint: 187 The authorization server's endpoint capable of issuing device 188 verification codes, user codes, and verification URLs. 190 Device Verification Code: 191 A short-lived token representing an authorization session. 193 End-User Verification Code: 194 A short-lived token which the device displays to the end user, is 195 entered by the end-user on the authorization server, and is thus 196 used to bind the device to the end-user. 198 3. Protocol 200 3.1. Device Authorization Request 202 The client initiates the flow by requesting a set of verification 203 codes from the authorization server by making an HTTP "POST" request 204 to the device authorization endpoint. The client constructs the 205 request with the following parameters, encoded with the "application/ 206 x-www-form-urlencoded" content type: 208 client_id 209 REQUIRED. The client identifier as described in Section 2.2 of 210 [RFC6749]. 212 scope 213 OPTIONAL. The scope of the access request as described by 214 Section 3.3 of [RFC6749]. 216 For example, the client makes the following HTTPS request (line 217 breaks are for display purposes only): 219 POST /device_authorization HTTP/1.1 220 Host: server.example.com 221 Content-Type: application/x-www-form-urlencoded 223 client_id=459691054427 225 Parameters sent without a value MUST be treated as if they were 226 omitted from the request. The authorization server MUST ignore 227 unrecognized request parameters. Request and response parameters 228 MUST NOT be included more than once. 230 3.2. Device Authorization Response 232 In response, the authorization server generates a device verification 233 code and an end-user code that are valid for a limited time, and 234 includes them in the HTTP response body using the "application/json" 235 format with a 200 (OK) status code. The response contains the 236 following parameters: 238 device_code 239 REQUIRED. The device verification code. 241 user_code 242 REQUIRED. The end-user verification code. 244 verification_uri 245 REQUIRED. The end-user verification URI on the authorization 246 server. The URI should be short and easy to remember as end- 247 users will be asked to manually type it into their user-agent. 249 expires_in 250 OPTIONAL. The lifetime in seconds of the "device_code" and 251 "user_code". 253 interval 254 OPTIONAL. The minimum amount of time in seconds that the client 255 SHOULD wait between polling requests to the token endpoint. 257 For example: 259 HTTP/1.1 200 OK 260 Content-Type: application/json 261 Cache-Control: no-store 263 { 264 "device_code":"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", 265 "user_code":"WDJB-MJHT", 266 "verification_uri":"https://www.example.com/device", 267 "expires_in" : 1800, 268 "interval": 5 269 } 271 3.3. User Instruction 273 After receiving a successful Authorization Response, the client 274 displays or otherwise communicates the "user_code" and the 275 "verification_uri" to the end-user, and instructs them to visit the 276 URI in a user agent on a secondary device (for example, in a browser 277 on their mobile phone), and enter the user code. 279 The end-user navigates to the "verification_uri" and authenticates 280 with the authorization server. The authorization server prompts the 281 end-user to identify the device authorization session by entering the 282 "user_code" provided by the client. The authorization server should 283 then inform the user about the action they are undertaking, and ask 284 them to approve or deny the request. Once the user interaction is 285 complete, the server informs the user to return to their device. 287 Clients MAY additionally present the verification URI in a non- 288 textual manner using any method that results in a the browser being 289 opened with the URI, like QR codes, or NFC, to save the user typing 290 the URI. For such shortcuts, the client MAY include the user code 291 with the parameter "user_code" on the verification URI, as a hint for 292 the authorization server. The server MAY accept this hint, and skip 293 the user code input step, however the client MUST still display the 294 user code, as the server MAY also ignore the hint or require visual 295 confirmation. Clients SHOULD still display the unmodified 296 verification URI for users not able to use such a shortcut. 298 During the user interaction, the device continuously polls the token 299 endpoint with the "device_code", as detailed in Section 3.4, until 300 the user completes the interaction, the code expires, or another 301 error occurs. 303 Authorization servers supporting this specification MUST implement a 304 user interaction sequence that starts with the user navigating to 305 "verification_uri" and continues with them supplying the "user_code" 306 at some stage during the interaction. Other than that, the exact 307 sequence and implementation of the user interaction is up to the 308 authorization server, and is out of scope of this specification. 310 3.4. Device Access Token Request 312 After displaying instructions to the user, the client makes an Access 313 Token Request to the token endpoint with a "grant_type" of 314 "urn:ietf:params:oauth:grant-type:device_code". This is an extension 315 grant type (as defined by Section 4.5 of [RFC6749]) with the 316 following parameters: 318 grant_type 319 REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant- 320 type:device_code". 322 device_code 323 REQUIRED. The device verification code, "device_code" from the 324 Device Authorization Response, defined in Section 3.2. 326 client_id 327 REQUIRED, if the client is not authenticating with the 328 authorization server as described in Section 3.2.1. of [RFC6749]. 330 For example, the client makes the following HTTPS request (line 331 breaks are for display purposes only): 333 POST /token HTTP/1.1 334 Host: server.example.com 335 Content-Type: application/x-www-form-urlencoded 337 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code 338 &device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8 339 &client_id=459691054427 341 If the client was issued client credentials (or assigned other 342 authentication requirements), the client MUST authenticate with the 343 authorization server as described in Section 3.2.1 of [RFC6749]. 344 Note that there are security implications of statically distributed 345 client credentials, see Section 5.4. 347 The response to this request is defined in Section 3.5. Unlike other 348 OAuth grant types, it is expected for the client to try the Access 349 Token Request repeatedly in a polling fashion, based on the error 350 code in the response. 352 3.5. Device Access Token Response 354 If the user has approved the grant, the token endpoint responds with 355 a success response defined in Section 5.1 of [RFC6749]; otherwise it 356 responds with an error, as defined in Section 5.2 of [RFC6749]. 358 In addition to the error codes defined in Section 5.2 of [RFC6749], 359 the following error codes are specific for the device flow: 361 authorization_pending 362 The authorization request is still pending as the end-user hasn't 363 yet completed the user interaction steps (Section 3.3). The 364 client should repeat the Access Token Request to the token 365 endpoint. 367 slow_down 368 The client is polling too quickly and should back off at a 369 reasonable rate. 371 expired_token 372 The "device_code" has expired. The client will need to make a new 373 Device Authorization Request. 375 The error codes "authorization_pending" and "slow_down" are 376 considered soft errors. The client should continue to poll the token 377 endpoint by repeating the Device Token Request (Section 3.4) when 378 receiving soft errors, increasing the time between polls if a 379 "slow_down" error is received. Other error codes are considered hard 380 errors; the client should stop polling and react accordingly, for 381 example, by displaying an error to the user. 383 If the verification codes have expired, the server SHOULD respond 384 with the standard OAuth error "invalid_grant". Clients MAY then 385 choose to start a new device authorization session. 387 The interval at which the client polls MUST NOT be more frequent than 388 the "interval" parameter returned in the Device Authorization 389 Response (see Section 3.2). 391 The assumption of this specification is that the secondary device the 392 user is authorizing the request on does not have a way to communicate 393 back to the OAuth client. Only a one-way channel is required to make 394 this flow useful in many scenarios. For example, an HTML application 395 on a TV that can only make outbound requests. If a return channel 396 were to exist for the chosen user interaction interface, then the 397 device MAY wait until notified on that channel that the user has 398 completed the action before initiating the token request. Such 399 behavior is, however, outside the scope of this specification. 401 4. Discovery Metadata 403 Support for the device flow MAY be declared in the OAuth 2.0 404 Authorization Server Metadata [I-D.ietf-oauth-discovery] with the 405 following metadata: 407 device_authorization_endpoint 408 OPTIONAL. URL of the authorization server's device authorization 409 endpoint defined in Section 3.1. 411 5. Security Considerations 413 5.1. User Code Brute Forcing 415 Since the user code is typed by the user, the entropy is typically 416 less than would be used for the device code or other OAuth bearer 417 token types. It is therefore recommended that the server rate-limit 418 user code attempts. The user code SHOULD have enough entropy that 419 when combined with rate limiting makes a brute-force attack 420 infeasible. 422 5.2. Device Trustworthiness 424 Unlike other native application OAuth 2.0 flows, the device 425 requesting the authorization is not the same as the device that the 426 user grants access from. Thus, signals from the approving user's 427 session and device are not relevant to the trustworthiness of the 428 client device. 430 5.3. Remote Phishing 432 It is possible for the device flow to be initiated on a device in an 433 attacker's possession. For example, the attacker they might send an 434 email instructing the target user to visit the verification URL and 435 enter the user code. To mitigate such an attack, it is RECOMMENDED 436 to inform the user that they are authorizing a device during the user 437 interaction step (see Section 3.3), and to confirm that the device is 438 in their possession. 440 The user code needs to have a long enough lifetime to be useable 441 (allowing the user to retrieve their secondary device, navigate to 442 the verification URI, login, etc.), but should be sufficiently short 443 to limit the usability of a code obtained for phishing. This doesn't 444 prevent a phisher presenting a fresh token, particularly in the case 445 they are interacting with the user in real time, but it does limit 446 the viability of codes sent over email or SMS. 448 5.4. Non-confidential Clients 450 Most device clients are incapable of being confidential clients, as 451 secrets that are statically included as part of an app distributed to 452 multiple users cannot be considered confidential. For such clients, 453 the recommendations of Section 5.3.1 of [RFC6819] and Section 8.9 of 454 [I-D.ietf-oauth-native-apps] apply. 456 5.5. Non-Visual Code Transmission 458 There is no requirement that the user code be displayed by the device 459 visually. Other methods of one-way communication can potentially be 460 used, such as text-to-speech audio, or Bluetooth Low Energy. To 461 mitigate an attack in which a malicious user can bootstrap their 462 credentials on a device not in their control, it is RECOMMENDED that 463 any chosen communication channel only be accessible by people in 464 close proximity. E.g., users who can see, or hear the device, or 465 within range of a short-range wireless signal. 467 6. Usability Considerations 469 This section is a non-normative discussion of usability 470 considerations. 472 6.1. User Code Recommendations 474 For many users, their nearest Internet-connected device will be their 475 mobile phone, and typically these devices offer input methods that 476 are more time consuming than a computer keyboard to change the case 477 or input numbers. To improve usability (improving entry speed, and 478 reducing retries), these limitations should be taken into account 479 when selecting the user-code character set. 481 One way to improve input speed is to restrict the character set to 482 case-insensitive A-Z characters, with no digits. These characters 483 can typically be entered on a mobile keyboard without using modifier 484 keys. Further removing vowels to avoid randomly creation valid words 485 results in the base-20 character set: "BCDFGHJKLMNPQRSTVWXZ". Dashes 486 or other punctuation may be included for readability. 488 An example user code following this guideline, with an entropy of 489 20^8, is "WDJB-MJHT". 491 The server should ignore any characters like punctuation that are not 492 in the user-code character set. Provided that the character set 493 doesn't include characters of different case, the comparison should 494 be case insensitive. 496 6.2. Non-Browser User Interaction 498 Devices and authorization servers MAY negotiate an alternative code 499 transmission and user interaction method in addition to the one 500 described in Section 3.3. Such an alternative user interaction flow 501 could obviate the need for a browser and manual input of the code, 502 for example, by using Bluetooth to transmit the code to the 503 authorization server's companion app. Such interaction methods can 504 utilize this protocol, as ultimately, the user just needs to identify 505 the authorization session to the authorization server; however, user 506 interaction other than via the "verification_uri" is outside the 507 scope of this specification. 509 7. IANA Considerations 511 7.1. OAuth URI Registration 513 This specification registers the following values in the IANA "OAuth 514 URI" registry [IANA.OAuth.Parameters] established by [RFC6755]. 516 7.1.1. Registry Contents 518 o URN: urn:ietf:params:oauth:grant-type:device_code 519 o Common Name: Device flow grant type for OAuth 2.0 520 o Change controller: IESG 521 o Specification Document: Section 3.1 of [[ this specification ]] 523 7.2. OAuth Extensions Error Registration 525 This specification registers the following values in the IANA "OAuth 526 Extensions Error Registry" registry [IANA.OAuth.Parameters] 527 established by [RFC6749]. 529 7.2.1. Registry Contents 531 o Error name: authorization_pending 532 o Error usage location: Token endpoint response 533 o Related protocol extension: [[ this specification ]] 534 o Change controller: IETF 535 o Specification Document: Section 3.5 of [[ this specification ]] 537 o Error name: slow_down 538 o Error usage location: Token endpoint response 539 o Related protocol extension: [[ this specification ]] 540 o Change controller: IETF 541 o Specification Document: Section 3.5 of [[ this specification ]] 543 o Error name: expired_token 544 o Error usage location: Token endpoint response 545 o Related protocol extension: [[ this specification ]] 546 o Change controller: IETF 547 o Specification Document: Section 3.5 of [[ this specification ]] 549 7.3. OAuth 2.0 Authorization Server Metadata 551 This specification registers the following values in the IANA "OAuth 552 2.0 Authorization Server Metadata" registry [IANA.OAuth.Parameters] 553 established by [I-D.ietf-oauth-discovery]. 555 7.3.1. Registry Contents 557 o Metadata name: device_authorization_endpoint 558 o Metadata Description: The Device Authorization Endpoint. 559 o Change controller: IESG 560 o Specification Document: Section 4 of [[ this specification ]] 562 8. Normative References 564 [I-D.ietf-oauth-discovery] 565 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 566 Authorization Server Metadata", draft-ietf-oauth- 567 discovery-05 (work in progress), January 2017. 569 [I-D.ietf-oauth-native-apps] 570 Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 571 draft-ietf-oauth-native-apps-07 (work in progress), 572 January 2017. 574 [IANA.OAuth.Parameters] 575 IANA, "OAuth Parameters", 576 . 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, 580 DOI 10.17487/RFC2119, March 1997, 581 . 583 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 584 RFC 6749, DOI 10.17487/RFC6749, October 2012, 585 . 587 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 588 for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, 589 . 591 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 592 Threat Model and Security Considerations", RFC 6819, 593 DOI 10.17487/RFC6819, January 2013, 594 . 596 Appendix A. Acknowledgements 598 The -00 version of this document was based on draft-recordon-oauth- 599 v2-device edited by David Recordon and Brent Goldman. The content of 600 that document was initially part of the OAuth 2.0 protocol 601 specification but was later removed due to the lack of sufficient 602 deployment expertise at that time. We would therefore also like to 603 thank the OAuth working group for their work on the initial content 604 of this specification through 2010. 606 The following individuals contributed ideas, feedback, and wording 607 that shaped and formed the final specification: 609 Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein 610 Myrseth, Simon Moffatt, Brian Campbell, James Manger, and Justin 611 Richer. 613 Appendix B. Document History 615 [[ to be removed by the RFC Editor before publication as an RFC ]] 617 -05 619 o response_type parameter removed from authorization request. 620 o Added option for clients to include the user_code on the 621 verification URI. 622 o Clarified token expiry, and other nits. 624 -04 626 o Security & Usability sections. OAuth Discovery Metadata. 628 -03 630 o device_code is now a URN. Added IANA Considerations 632 -02 634 o Added token request & response specification. 636 -01 637 o Applied spelling and grammar corrections and added the Document 638 History appendix. 640 -00 642 o Initial working group draft based on draft-recordon-oauth- 643 v2-device. 645 Authors' Addresses 647 William Denniss 648 Google 649 1600 Amphitheatre Pkwy 650 Mountain View, CA 94043 651 USA 653 Email: wdenniss@google.com 654 URI: http://wdenniss.com/device-flow 656 John Bradley 657 Ping Identity 659 Email: ve7jtb@ve7jtb.com 660 URI: http://www.thread-safe.com/ 662 Michael B. Jones 663 Microsoft 665 Email: mbj@microsoft.com 666 URI: http://self-issued.info/ 668 Hannes Tschofenig 669 ARM Limited 670 Austria 672 Email: Hannes.Tschofenig@gmx.net 673 URI: http://www.tschofenig.priv.at