< draft-ietf-oauth-device-flow-07.txt		draft-ietf-oauth-device-flow-08.txt >
	OAuth W. Denniss		OAuth W. Denniss
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track J. Bradley		Intended status: Standards Track J. Bradley
	Expires: May 3, 2018 Ping Identity		Expires: September 20, 2018 Ping Identity
	M. Jones		M. Jones
	Microsoft		Microsoft
	H. Tschofenig		H. Tschofenig
	ARM Limited		ARM Limited
	October 30, 2017		March 19, 2018
	OAuth 2.0 Device Flow for Browserless and Input Constrained Devices		OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
	draft-ietf-oauth-device-flow-07		draft-ietf-oauth-device-flow-08
	Abstract		Abstract
	This OAuth 2.0 authorization flow for browserless and input		This OAuth 2.0 authorization flow for browserless and input
	constrained devices, often referred to as the device flow, enables		constrained devices, often referred to as the device flow, enables
	OAuth clients to request user authorization from devices that have an		OAuth clients to request user authorization from devices that have an
	Internet connection, but don't have an easy input method (such as a		Internet connection, but don't have an easy input method (such as a
	smart TV, media console, picture frame, or printer), or lack a		smart TV, media console, picture frame, or printer), or lack a
	suitable browser for a more traditional OAuth flow. This		suitable browser for a more traditional OAuth flow. This
	authorization flow instructs the user to perform the authorization		authorization flow instructs the user to perform the authorization
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 May 3, 2018.		This Internet-Draft will expire on September 20, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Device Authorization Request . . . . . . . . . . . . . . 5		3.1. Device Authorization Request . . . . . . . . . . . . . . 5
	3.2. Device Authorization Response . . . . . . . . . . . . . . 6		3.2. Device Authorization Response . . . . . . . . . . . . . . 6
	3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 7		3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 7
	3.3.1. Non-textual Verification URI Optimization . . . . . . 8		3.3.1. Non-textual Verification URI Optimization . . . . . . 8
	3.4. Device Access Token Request . . . . . . . . . . . . . . . 9		3.4. Device Access Token Request . . . . . . . . . . . . . . . 9
	3.5. Device Access Token Response . . . . . . . . . . . . . . 10		3.5. Device Access Token Response . . . . . . . . . . . . . . 10
	4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 11		4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 11		5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 11
	5.2. Device Trustworthiness . . . . . . . . . . . . . . . . . 11		5.2. Device Trustworthiness . . . . . . . . . . . . . . . . . 12
	5.3. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 11		5.3. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Session Spying . . . . . . . . . . . . . . . . . . . . . 12		5.4. Session Spying . . . . . . . . . . . . . . . . . . . . . 12
	5.5. Non-confidential Clients . . . . . . . . . . . . . . . . 12		5.5. Non-confidential Clients . . . . . . . . . . . . . . . . 12
	5.6. Non-Visual Code Transmission . . . . . . . . . . . . . . 12		5.6. Non-Visual Code Transmission . . . . . . . . . . . . . . 13
	6. Usability Considerations . . . . . . . . . . . . . . . . . . 12		6. Usability Considerations . . . . . . . . . . . . . . . . . . 13
	6.1. User Code Recommendations . . . . . . . . . . . . . . . . 13		6.1. User Code Recommendations . . . . . . . . . . . . . . . . 13
	6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 13		6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 14		7.1. OAuth URI Registration . . . . . . . . . . . . . . . . . 14
	7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 14		7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 14
	7.2. OAuth Extensions Error Registration . . . . . . . . . . . 14		7.2. OAuth Extensions Error Registration . . . . . . . . . . . 14
	7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 14		7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 14
	7.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . . 14		7.3. OAuth 2.0 Authorization Server Metadata . . . . . . . . . 15
	7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 15		7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 15
	8. Normative References . . . . . . . . . . . . . . . . . . . . 15		8. Normative References . . . . . . . . . . . . . . . . . . . . 15
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 16		Appendix B. Document History . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This OAuth 2.0 protocol flow for browserless and input constrained		This OAuth 2.0 protocol flow for browserless and input constrained
	devices, often referred to as the device flow, enables OAuth clients		devices, often referred to as the device flow, enables OAuth clients
	to request user authorization from devices that have an internet		to request user authorization from devices that have an internet
	connection, but don't have an easy input method (such as a smart TV,		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		media console, picture frame, or printer), or lack a suitable browser
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 21 ¶
	following metadata:		following metadata:
	device_authorization_endpoint		device_authorization_endpoint
	OPTIONAL. URL of the authorization server's device authorization		OPTIONAL. URL of the authorization server's device authorization
	endpoint defined in Section 3.1.		endpoint defined in Section 3.1.
	5. Security Considerations		5. Security Considerations
	5.1. User Code Brute Forcing		5.1. User Code Brute Forcing
	Since the user code is typed by the user, the entropy is typically		Since the user code is typed by the user, shorter codes are more
			desirable for usability reasons. This means the entropy is typically
	less than would be used for the device code or other OAuth bearer		less than would be used for the device code or other OAuth bearer
	token types. It is therefore recommended that the server rate-limit		token types where the code length does not impact usability. It is
	user code attempts. The user code SHOULD have enough entropy that		therefore recommended that the server rate-limit user code attempts.
	when combined with rate limiting makes a brute-force attack		The user code SHOULD have enough entropy that when combined with rate
	infeasible.		limiting and other mitigations makes a brute-force attack infeasible.
			A successful brute forcing of the user code would enable the attacker
			to authenticate with their own credentials and make an authorization
			grant to the device. This is the opposite scenario to an OAuth
			bearer token being brute forced, whereby the attacker gains control
			of the victim's authorization grant. In some applications this
			attack may not make much economic sense, for example for a video app,
			the owner of the device may then be able to purchase movies with the
			attacker's account, however there are still privacy considerations in
			that case as well as other uses of the device flow whereby the
			granting account may be able to perform sensitive actions such as
			controlling the victim's device.
			The precise length of the user code and the entropy contained within
			is at the discretion of the authorization server, which needs to
			consider the sensitivity of their specific protected resources, the
			practicality of the code length from a usability standpoint, and any
			mitigations that are in place such as rate-limiting, when determining
			the user code format.
	5.2. Device Trustworthiness		5.2. Device Trustworthiness
	Unlike other native application OAuth 2.0 flows, the device		Unlike other native application OAuth 2.0 flows, the device
	requesting the authorization is not the same as the device that the		requesting the authorization is not the same as the device that the
	user grants access from. Thus, signals from the approving user's		user grants access from. Thus, signals from the approving user's
	session and device are not relevant to the trustworthiness of the		session and device are not relevant to the trustworthiness of the
	client device.		client device.
	5.3. Remote Phishing		5.3. Remote Phishing
	skipping to change at page 16, line 12 ¶		skipping to change at page 16, line 29 ¶
	OAuth 2.0 protocol specification removed prior to publication due to		OAuth 2.0 protocol specification removed prior to publication due to
	a then lack of sufficient deployment expertise. Thank you to the		a then lack of sufficient deployment expertise. Thank you to the
	OAuth working group members who worked on this specification through		OAuth working group members who worked on this specification through
	2010.		2010.
	The following individuals contributed ideas, feedback, and wording		The following individuals contributed ideas, feedback, and wording
	that shaped and formed the final specification:		that shaped and formed the final specification:
	Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein		Roshni Chandrashekhar, Marius Scurtescu, Breno de Medeiros, Stein
	Myrseth, Simon Moffatt, Brian Campbell, James Manger, Justin Richer,		Myrseth, Simon Moffatt, Brian Campbell, James Manger, Justin Richer,
	Ken Wang, Steven E. Wright, Nat Sakimura, and Torsten Lodderstedt.		Ken Wang, Steven E. Wright, Nat Sakimura, and Torsten Lodderstedt.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by the RFC Editor before publication as an RFC ]]		[[ to be removed by the RFC Editor before publication as an RFC ]]
	-07		-07
	o Replaced the "user_code" URI parameter optimization with		o Replaced the "user_code" URI parameter optimization with
	verification_uri_complete following the IETF99 working group		verification_uri_complete following the IETF99 working group
	discussion.		discussion.
End of changes. 13 change blocks.
	18 lines changed or deleted		38 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/