draft-ietf-oauth-incremental-authz-00.txt		draft-ietf-oauth-incremental-authz-01.txt
	OAuth Working Group W. Denniss		OAuth Working Group W. Denniss
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track June 28, 2018		Intended status: Standards Track October 22, 2018
	Expires: December 30, 2018		Expires: April 25, 2019
	OAuth 2.0 Incremental Authorization		OAuth 2.0 Incremental Authorization
	draft-ietf-oauth-incremental-authz-00		draft-ietf-oauth-incremental-authz-01
	Abstract		Abstract
	OAuth 2.0 authorization requests that include every scope the client		OAuth 2.0 authorization requests that include every scope the client
	might ever need can result in over-scoped authorization and a sub-		might ever need can result in over-scoped authorization and a sub-
	optimal end-user consent experience. This specification enhances the		optimal end-user consent experience. This specification enhances the
	OAuth 2.0 authorization protocol by adding incremental authorization,		OAuth 2.0 authorization protocol by adding incremental authorization,
	the ability to request specific authorization scopes as needed, when		the ability to request specific authorization scopes as needed, when
	they're needed, removing the requirement to request every possible		they're needed, removing the requirement to request every possible
	scope that might be needed upfront.		scope that might be needed upfront.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 December 30, 2018.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	5. Incremental Auth for Public Clients . . . . . . . . . . . . . 4		5. Incremental Auth for Public Clients . . . . . . . . . . . . . 4
	6. Usability Considerations . . . . . . . . . . . . . . . . . . 4		6. Usability Considerations . . . . . . . . . . . . . . . . . . 4
	6.1. Handling Denials . . . . . . . . . . . . . . . . . . . . 4		6.1. Handling Denials . . . . . . . . . . . . . . . . . . . . 4
	7. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5		7. Alternative Approaches . . . . . . . . . . . . . . . . . . . 5
	7.1. Alternative for Public Clients . . . . . . . . . . . . . 5		7.1. Alternative for Public Clients . . . . . . . . . . . . . 5
	7.2. Alternative for Confidential Clients . . . . . . . . . . 5		7.2. Alternative for Confidential Clients . . . . . . . . . . 5
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
	8.1. Requesting Authorization In Context . . . . . . . . . . . 5		8.1. Requesting Authorization In Context . . . . . . . . . . . 5
	8.2. Preventing Overbroad Authorization Requests . . . . . . . 6		8.2. Preventing Overbroad Authorization Requests . . . . . . . 6
	8.3. Authorization Correlation . . . . . . . . . . . . . . . . 6		8.3. Authorization Correlation . . . . . . . . . . . . . . . . 6
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		9. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 6
	9.1. Public Client Impersonation . . . . . . . . . . . . . . . 6		10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		10.1. Public Client Impersonation . . . . . . . . . . . . . . 7
	10.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 7		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	11. Normative References . . . . . . . . . . . . . . . . . . . . 7		11.1. OAuth Parameters Registry . . . . . . . . . . . . . . . 7
			11.2. OAuth 2.0 Authorization Server Metadata . . . . . . . . 8
			12. Normative References . . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 8		Appendix B. Document History . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	OAuth 2.0 clients may offer multiple features that requiring user		OAuth 2.0 clients may offer multiple features that require user
	authorization, but commonly not every user will use each feature.		authorization, but commonly not every user will use each feature.
	Without incremental authentication, applications need to either		Without incremental authentication, applications need to either
	request all the possible scopes they need upfront, potentially		request all the possible scopes they need upfront, potentially
	resulting in a bad user experience, or track each authorization grant		resulting in a bad user experience, or track each authorization grant
	separately, complicating development.		separately, complicating development.
	The goal of incremental authorization is to allow clients to request		The goal of incremental authorization is to allow clients to request
	just the scopes they need, when they need them, while allowing them		just the scopes they need, when they need them, while allowing them
	to store a single authorization grant for the user that contains the		to store a single authorization grant for the user that contains the
	sum of the scopes granted. Thus, each new authorization request		sum of the scopes granted. Thus, each new authorization request
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	additional parameter:		additional parameter:
	existing_grant OPTIONAL. The refresh token from the existing		existing_grant OPTIONAL. The refresh token from the existing
	authorization grant.		authorization grant.
	When processing the token exchange, in addition to the normal		When processing the token exchange, in addition to the normal
	processing of such a request, the token endpoint MUST verify that		processing of such a request, the token endpoint MUST verify that
	token provided in the "existing_grant" parameter is unexpired and		token provided in the "existing_grant" parameter is unexpired and
	unrevoked, and was issued to the same client id and relates to the		unrevoked, and was issued to the same client id and relates to the
	same user as the current authorization grant. If this verification		same user as the current authorization grant. If this verification
	succeeds, the new refresh token issued in the Access Token Response		succeeds, the new access and refresh tokens issued in the Access
	(Section 4.1.4 of ) SHOULD include authorization for the scopes in		Token Response (Section 4.1.4 of ) MUST include authorization for the
	the previous grant.		scopes in the previous grant, unless the authorization server is
			exercising its prerogative to "fully or partially ignore the scope
			requested by the client" per Section 3.3 of OAuth 2.0 [RFC6749].
	6. Usability Considerations		6. Usability Considerations
	6.1. Handling Denials		6.1. Handling Denials
	A core principle of OAuth is that users may deny authorization		A core principle of OAuth is that users may deny authorization
	requests for any reason. This remains true for incremental		requests for any reason. This remains true for incremental
	authorization requests. In the case of incremental authorization,		authorization requests. In the case of incremental authorization,
	clients may already have a valid authorization and receive a denial		clients may already have a valid authorization and receive a denial
	for an incremental authorization request (that is, an "access_denied"		for an incremental authorization request (that is, an "access_denied"
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 47 ¶
	giving them more choice over which scopes they grant access to.		giving them more choice over which scopes they grant access to.
	Previously many apps would request an overly large number of scopes		Previously many apps would request an overly large number of scopes
	upfront (typically for all the features of the app, rather than the		upfront (typically for all the features of the app, rather than the
	subset that the user is currently wishing to use). The scopes in		subset that the user is currently wishing to use). The scopes in
	such authorization grants are necessarily correlated with the same		such authorization grants are necessarily correlated with the same
	user as they are contained in a single authorization grant.		user as they are contained in a single authorization grant.
	Implementing this specification doesn't change that attribute, but it		Implementing this specification doesn't change that attribute, but it
	does improve user privacy overall by empowering the user to grant		does improve user privacy overall by empowering the user to grant
	access in a more granular way.		access in a more granular way.
	9. Security Considerations		9. Discovery Metadata
	9.1. Public Client Impersonation		Support for the incremental authorization MAY be declared in the
			OAuth 2.0 Authorization Server Metadata [RFC8414] with the following
			metadata:
			incremental_authz_types_supported
			OPTIONAL. JSON array of OAuth 2.0 client types that are supported
			for incremental authorization. The possible types, defined by
			Section 2.1 of RFC6749, are "public", "confidential".
			10. Security Considerations
			10.1. Public Client Impersonation
	As documented in Section 8.6 of RFC 8252 [RFC8252], some public		As documented in Section 8.6 of RFC 8252 [RFC8252], some public
	clients are susceptible to client impersonation, depending on the		clients are susceptible to client impersonation, depending on the
	type of redirect URI used. If the "include_granted_scopes" feature		type of redirect URI used. If the "include_granted_scopes" feature
	documented in Section 4 is used by an impersonating client, it may		documented in Section 4 is used by an impersonating client, it may
	receive a greater authorization grant than the user specifically		receive a greater authorization grant than the user specifically
	approved for that client. For this reason, the		approved for that client. For this reason, the
	"include_granted_scopes" feature MUST NOT be enabled for such public		"include_granted_scopes" feature MUST NOT be enabled for such public
	client requests.		client requests.
	Note that there is no such restriction on the use of "existing_grant"		Note that there is no such restriction on the use of "existing_grant"
	feature documented in Section 5. While it is designed for public		feature documented in Section 5. While it is designed for public
	clients, it MAY be supported for all client types.		clients, it MAY be supported for all client types.
	10. IANA Considerations		11. IANA Considerations
	This specification makes a registration request as follows:		This specification makes a registration request as follows:
	10.1. OAuth Parameters Registry		11.1. OAuth Parameters Registry
	This specification registers the following parameters in the IANA		This specification registers the following parameters in the IANA
	OAuth Parameters registry defined in OAuth 2.0 [RFC6749].		OAuth Parameters registry defined in OAuth 2.0 [RFC6749].
	o Parameter name: include_granted_scopes		o Parameter name: include_granted_scopes
	o Parameter usage location: authorization request		o Parameter usage location: authorization request
	o Change controller: IESG		o Change controller: IESG
	o Specification document(s): this document		o Specification document(s): this document
	o Parameter name: existing_grant		o Parameter name: existing_grant
	o Parameter usage location: token request		o Parameter usage location: token request
	o Change controller: IESG		o Change controller: IESG
	o Specification document(s): this document		o Specification document(s): this document
	11. Normative References		11.2. 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 [RFC8414].
			o Metadata Name: incremental_authz_types_supported
			o Metadata Description: JSON array containing a list of client types
			that support OAuth 2.0 Incremental Authorization [[ this
			specification ]]. The possible types, defined by Section 2.1 of
			RFC6749, are "public", "confidential".
			o Change controller: IESG
			o Specification Document: Section 9 of [[ this specification ]]
			12. 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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://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,
	<https://www.rfc-editor.org/info/rfc6749>.		<https://www.rfc-editor.org/info/rfc6749>.
	[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",		[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,		BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
	<https://www.rfc-editor.org/info/rfc8252>.		<https://www.rfc-editor.org/info/rfc8252>.
			[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
			Authorization Server Metadata", RFC 8414,
			DOI 10.17487/RFC8414, June 2018,
			<https://www.rfc-editor.org/info/rfc8414>.
			[IANA.OAuth.Parameters]
			IANA, "OAuth Parameters",
			<http://www.iana.org/assignments/oauth-parameters>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This document was produced in the OAuth working group under the		This document was produced in the OAuth working group under the
	chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with		chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig with
	Benjamin Kaduk, and Eric Rescorla serving as Security Area Directors.		Benjamin Kaduk, and Eric Rescorla serving as Security Area Directors.
	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:
	Yanna Wu, Marius Scurtescu, Jason Huang, Nicholas Watson, and Breno		Yanna Wu, Marius Scurtescu, Jason Huang, Nicholas Watson, and Breno
	de Medeiros.		de Medeiros.
	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 ]]
			01
			o Changed a SHOULD to a MUST in Section 5 regarding the protocol
			behavior of incremental auth for public clients, while clarifying
			that the authorization server retains the prerogative to do
			whatever it wants.
			o Defined an OAuth Metadata entry.
	00		00
	o Now a working group draft.		o Now a working group draft.
	draft-wdenniss-oauth-incremental-auth-01		draft-wdenniss-oauth-incremental-auth-01
	o Added usability, privacy, and security considerations.		o Added usability, privacy, and security considerations.
	o Documented alternative approaches.		o Documented alternative approaches.
End of changes. 14 change blocks.
	20 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/