< draft-ietf-oauth-device-flow-00.txt   draft-ietf-oauth-device-flow-01.txt >
OAuth W. Denniss OAuth W. Denniss
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track S. Myrseth Intended status: Standards Track S. Myrseth
Expires: August 20, 2016 Forgerock Expires: September 4, 2016 ForgeRock
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Jones M. Jones
Microsoft Microsoft
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
February 17, 2016 March 3, 2016
OAuth 2.0 Device Flow OAuth 2.0 Device Flow
draft-ietf-oauth-device-flow-00 draft-ietf-oauth-device-flow-01
Abstract Abstract
The device flow is suitable for OAuth 2.0 clients executing on The device flow is suitable for OAuth 2.0 clients executing on
devices which do not have an easy data-entry method (e.g., game devices that do not have an easy data-entry method (e.g., game
consoles, TVs, picture frames, and media hubs), but where the end- consoles, TVs, picture frames, and media hubs), but where the end-
user has separate access to a user-agent on another computer or user has separate access to a user-agent on another computer or
device (e.g., desktop computer, a laptop, a smart phone, or a device (e.g., desktop computer, a laptop, a smart phone, or a
tablet). tablet).
Note: This version of the document is a continuation of an earlier,
long expired draft. The content of the expired draft has been copied
almost unmodified. The goal of the work on this document is to
capture deployment experience.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 20, 2016. This Internet-Draft will expire on September 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 23
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Client Requests Authorization . . . . . . . . . . . . . . 4 3.1. Client Requests Authorization . . . . . . . . . . . . . . 4
3.2. Client Requests Access Token . . . . . . . . . . . . . . 6 3.2. Client Requests Access Token . . . . . . . . . . . . . . 6
3.3. Additional Error Responses . . . . . . . . . . . . . . . 6 3.3. Additional Error Responses . . . . . . . . . . . . . . . 6
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Document History . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The device flow is suitable for clients executing on devices which do 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 not have an easy data-entry method and where the client is incapable
of receiving incoming requests from the authorization server of receiving incoming requests from the authorization server
(incapable of acting as an HTTP server). (incapable of acting as an HTTP server).
Instead of interacting with the end-user's user-agent, the client Instead of interacting with the end-user's user-agent, the client
instructs the end-user to use another computer or device and connect instructs the end-user to use another computer or device and connect
to the authorization server to approve the access request. Since the to the authorization server to approve the access request. Since the
client cannot receive incoming requests, it polls the authorization client cannot receive incoming requests, it polls the authorization
server repeatedly until the end-user completes the approval process. server repeatedly until the end-user completes the approval process.
skipping to change at page 7, line 13 skipping to change at page 7, line 13
authorization_pending authorization_pending
The authorization request is still pending as the end-user hasn't The authorization request is still pending as the end-user hasn't
yet visited the authorization server and entered their yet visited the authorization server and entered their
verification code. verification code.
slow_down slow_down
The client is polling too quickly and should back off at a The client is polling too quickly and should back off at a
reasonable rate. reasonable rate.
4. Contributors 4. Security Considerations
The -00 version of this document is based on a previous edited by
David Recordon and Brent Goldman. The content of that document was
initially part of the OAuth 2.0 protocol specificaiton 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 this document around 2010.
5. Acknowledgements
Add your name here.
6. Security Considerations
TBD TBD
7. Normative References 5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <http://www.rfc-editor.org/info/rfc6749>.
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.
Appendix B. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]]
-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 Authors' Addresses
William Denniss William Denniss
Google Google
1600 Amphitheatre Pkwy 1600 Amphitheatre Pkwy
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 650-253-0000 Phone: +1 650-253-0000
Email: wdenniss@google.com Email: wdenniss@google.com
skipping to change at page 8, line 4 skipping to change at page 8, line 16
William Denniss William Denniss
Google Google
1600 Amphitheatre Pkwy 1600 Amphitheatre Pkwy
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 650-253-0000 Phone: +1 650-253-0000
Email: wdenniss@google.com Email: wdenniss@google.com
URI: http://google.com/ URI: http://google.com/
Stein Myrseth Stein Myrseth
Forgerock ForgeRock
Lysaker torg 2 Lysaker torg 2
Lysaker 1366 Lysaker 1366
NORWAY NORWAY
Email: stein.myrseth@forgerock.com Email: stein.myrseth@forgerock.com
John Bradley John Bradley
Ping Identity Ping Identity
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
 End of changes. 13 change blocks. 
32 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/