< draft-ietf-oauth-reciprocal-02.txt		draft-ietf-oauth-reciprocal-03.txt >
	OAuth Working Group D. Hardt		OAuth Working Group D. Hardt
	Internet-Draft July 03, 2019		Internet-Draft July 23, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 4, 2020		Expires: January 24, 2020
	Reciprocal OAuth		Reciprocal OAuth
	draft-ietf-oauth-reciprocal-02		draft-ietf-oauth-reciprocal-03
	Abstract		Abstract
	There are times when a user has a pair of protected resources that		There are times when a user has a pair of protected resources that
	would like to request access to each other. While OAuth flows		would like to request access to each other. While OAuth flows
	typically enable the user to grant a client access to a protected		typically enable the user to grant a client access to a protected
	resource, granting the inverse access requires an additional flow.		resource, granting the inverse access requires an additional flow.
	Reciprocal OAuth enables a more seamless experience for the user to		Reciprocal OAuth enables a more seamless experience for the user to
	grant access to a pair of protected resources.		grant access to a pair of protected resources.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 January 4, 2020.		This Internet-Draft will expire on January 24, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 29 ¶		skipping to change at page 2, line 29 ¶
	though the original flow started at Party A.		though the original flow started at Party A.
	Reciprocal OAuth simplifies the user experience by eliminating the		Reciprocal OAuth simplifies the user experience by eliminating the
	redirections in the second OAuth flow. After the intial OAuth flow,		redirections in the second OAuth flow. After the intial OAuth flow,
	party A obtains consent from the user to grant party B access to a		party A obtains consent from the user to grant party B access to a
	protected resource at party A, and then passes an authorization code		protected resource at party A, and then passes an authorization code
	to party B using the access token party A obtained from party B to		to party B using the access token party A obtained from party B to
	provide party B the context of the user. Party B then exchanges the		provide party B the context of the user. Party B then exchanges the
	authorization code for an access token per the usual OAuth flow.		authorization code for an access token per the usual OAuth flow.
			For example, a user would like their voice assistant (party A) and
			music service (party B) to work together. The voice assistant wants
			to call the music service to play music, and the music service wants
			to call the voice assistant with music information to present to the
			user. The user starts the OAuth flow at the voice assistant, and is
			redirected to the music service. The music services obtains consent
			from the user and the redirects back to the voice assistant. At this
			point the voice assistant is able to obtain an access token for the
			music service. The voice assistant can the get consent from the user
			to authorize the music service to access the voice assistant, and
			then the voice assistant can create an authorization code and send it
			to the music service, which then exchanges the authorization code for
			an access token, all without further user interaction. Note that
			either the voice assistant or the music service can initiate the
			flow, so that either can prompt the user for the two parties to work
			together.
	1.1. Terminology		1.1. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119		and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	2. Reciprocol Protocol Flow		2. reciprocal Protocol Flow
	Party A Party B		Party A Party B
	+---------------+ +---------------+		+---------------+ +---------------+
	| |--(A)- Authorization Request ->| Resource |		| |--(A)- Authorization Request ->| Resource |
	| | | Owner B |		| | | Owner B |
	| |<-(B)-- Authorization Grant ---| |		| |<-(B)-- Authorization Grant ---| |
	| | +---------------+		| | +---------------+
	| Client A |		| Client A |
	| | +---------------+		| | +---------------+
	| |--(C)-- Authorization Grant -->| |		| |--(C)-- Authorization Grant -->| |
	| | | Authorization |		| | | Authorization |
	| |<-(D)---- Access Token B ------| Server B |		| |<-(D)---- Access Token B ------| Server B |
	| | Reciprocol Request | |		| | reciprocal Request | |
	+---------------+ +---------------+		+---------------+ +---------------+
	|		|
	Reciprocol Request		reciprocal Request
	V		V
	+---------------+ +---------------+		+---------------+ +---------------+
	| Resource | | Authorization |		| Resource | | Authorization |
	| Owner A |--(E)--- Reciprocol Grant ---->| Server B |		| Owner A |--(E)--- reciprocal Grant ---->| Server B |
	| | Access Token B | |		| | Access Token B | |
	+---------------+ +---------------+		+---------------+ +---------------+
	|		|
	Reciprocol Grant		reciprocal Grant
	V		V
	+---------------+ +---------------+		+---------------+ +---------------+
	| |<-(F)--- Reciprocol Grant -----| |		| |<-(F)--- reciprocal Grant -----| |
	| Authorization | | Client B |		| Authorization | | Client B |
	| Server A |--(G)---- Access Token A ----->| |		| Server A |--(G)---- Access Token A ----->| |
	+---------------+ +---------------+		+---------------+ +---------------+
	Figure 1: Abstract Reciprocol Protocol Flow		Figure 1: Abstract reciprocal Protocol Flow
	The reciprocol authorization between party A and party B are		The reciprocal authorization between party A and party B are
	abstractly represented in Figure 1 and includes the following steps:		abstractly represented in Figure 1 and includes the following steps:
	o (A - C) are the same as in [RFC6749] 1.2		o (A - C) are the same as in [RFC6749] 1.2
	o (D) Party B optionally includes the reciprocol scope in the		o (D) Party B optionally includes the reciprocal scope in the
	response.		response. See Section 2.1 for details.
	See Section 2.1 for details.
	o (E) Party A sends the reciprocol authorization grant to party B.		o (E) Party A sends the reciprocal authorization grant to party B.
	See Section 2.2.2 for details.		See Section 2.2.2 for details.
	o (F) Party B requests an access token, mirroring step (B)		o (F) Party B requests an access token, mirroring step (B)
	o (G) Party A issues an access token, mirroring step (C)		o (G) Party A issues an access token, mirroring step (C)
			Note that Resource Owner A and Resource Owner B are the respective
			resource owner interaction systems controlled by the same owner.
	2.1. Reciprocal Scope Request		2.1. Reciprocal Scope Request
	When party B is providing an access token response per [RFC6749]		When party B is providing an access token response per [RFC6749]
	4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query		4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query
	component in the redirection URI to indicate the scope requested in		component in the redirection URI to indicate the scope requested in
	the reciprocal grant:		the reciprocal grant:
	reciprocal OPTIONAL		reciprocal OPTIONAL
	The scope of party B's reciprocal access request per [RFC6749] 3.3.		The scope of party B's reciprocal access request per [RFC6749] 3.3.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	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>.
	[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization		[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
	Framework: Bearer Token Usage", RFC 6750,		Framework: Bearer Token Usage", RFC 6750,
	DOI 10.17487/RFC6750, October 2012,		DOI 10.17487/RFC6750, October 2012,
	<https://www.rfc-editor.org/info/rfc6750>.		<https://www.rfc-editor.org/info/rfc6750>.
	Appendix A. Document History		Appendix A. Document History
	A.1. draft-ietf-oauth-reciprical-00		A.1. draft-ietf-oauth-reciprocal-00
	o Initial version.		o Initial version.
	A.2. draft-ietf-oauth-reciprical-01		A.2. draft-ietf-oauth-reciprocal-01
	o Changed reciprocal scope request to be in access token response		o Changed reciprocal scope request to be in access token response
	rather than authorization request		rather than authorization request
	A.3. draft-ietf-oauth-reciprical-02		A.3. draft-ietf-oauth-reciprocal-02
	o Added in diagram to clarify protocol flow		o Added in diagram to clarify protocol flow
			A.4. draft-ietf-oauth-reciprocal-03
			o fixed spelling of reciprocal
			o added example use case in introduction
			o resource owner is the same in Party A and Party B
	Author's Address		Author's Address
	Dick Hardt		Dick Hardt
	Email: dick.hardt@gmail.com		Email: dick.hardt@gmail.com
End of changes. 20 change blocks.
	19 lines changed or deleted		46 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/