< draft-ietf-oauth-reciprocal-01.txt		draft-ietf-oauth-reciprocal-02.txt >
	OAuth Working Group D. Hardt		OAuth Working Group D. Hardt
	Internet-Draft Amazon		Internet-Draft July 03, 2019
	Intended status: Standards Track October 19, 2018		Intended status: Standards Track
	Expires: April 22, 2019		Expires: January 4, 2020
	Reciprocal OAuth		Reciprocal OAuth
	draft-ietf-oauth-reciprocal-01		draft-ietf-oauth-reciprocal-02
	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 April 22, 2019.		This Internet-Draft will expire on January 4, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	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 36 ¶		skipping to change at page 2, line 36 ¶
	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.
	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. Reciprocal Scope Request		2. Reciprocol Protocol Flow
			Party A Party B
			+---------------+ +---------------+
			| |--(A)- Authorization Request ->| Resource |
			| | | Owner B |
			| |<-(B)-- Authorization Grant ---| |
			| | +---------------+
			| Client A |
			| | +---------------+
			| |--(C)-- Authorization Grant -->| |
			| | | Authorization |
			| |<-(D)---- Access Token B ------| Server B |
			| | Reciprocol Request | |
			+---------------+ +---------------+
			|
			Reciprocol Request
			V
			+---------------+ +---------------+
			| Resource | | Authorization |
			| Owner A |--(E)--- Reciprocol Grant ---->| Server B |
			| | Access Token B | |
			+---------------+ +---------------+
			|
			Reciprocol Grant
			V
			+---------------+ +---------------+
			| |<-(F)--- Reciprocol Grant -----| |
			| Authorization | | Client B |
			| Server A |--(G)---- Access Token A ----->| |
			+---------------+ +---------------+
			Figure 1: Abstract Reciprocol Protocol Flow
			The reciprocol authorization between party A and party B are
			abstractly represented in Figure 1 and includes the following steps:
			o (A - C) are the same as in [RFC6749] 1.2
			o (D) Party B optionally includes the reciprocol scope in the
			response.
			See Section 2.1 for details.
			o (E) Party A sends the reciprocol authorization grant to party B.
			See Section 2.2.2 for details.
			o (F) Party B requests an access token, mirroring step (B)
			o (G) Party A issues an access token, mirroring step (C)
			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. The scope of party B's reciprocal access		reciprocal OPTIONAL
	request per [RFC6749] 3.3.		The scope of party B's reciprocal access request per [RFC6749] 3.3.
	If party B does not provide a reciprocal parameter in the access		If party B does not provide a reciprocal parameter in the access
	token response, the reciprocal scope will be a value previously		token response, the reciprocal scope will be a value previously
	preconfigured by party A and party B.		preconfigured by party A and party B.
	If an authorization code grant access token response per [RFC6749]		If an authorization code grant access token response per [RFC6749]
	4.1.4, an example successful response:		4.1.4, an example successful response (with extra line breaks for
			display purposes only):
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json;charset=UTF-8		Content-Type: application/json;charset=UTF-8
	Cache-Control: no-store		Cache-Control: no-store
	Pragma: no-cache		Pragma: no-cache
	{		{
	"access_token":"2YotnFZFEjr1zCsicMWpAA",		"access_token":"2YotnFZFEjr1zCsicMWpAA",
	"token_type":"example",		"token_type":"example",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",		"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
	"reciprocal":"example_scope",		"reciprocal":"example_scope",
	"example_parameter":"example_value"		"example_parameter":"example_value"
	}		}
	If an authorization code grant access token response per [RFC6749]		If an authorization code grant access token response per [RFC6749]
	4.2.2, an example successful response (with extra line breaks for		4.2.2, an example successful response (with extra line breaks for
	display purposes only):		display purposes only):
	HTTP/1.1 302 Found		HTTP/1.1 302 Found
	Location: http://example.com/cb#		Location: http://example.com/cb#
	access_token=2YotnFZFEjr1zCsicMWpAA&		access_token=2YotnFZFEjr1zCsicMWpAA&
	state=xyz&token_type=example&		state=xyz&
	expires_in=3600&		token_type=example&
	reciprocal="example_scope"		expires_in=3600&
			reciprocal="example_scope"
	3. Reciprocal Authorization Flow		When party B is providing an authorization response per [RFC6749]
			4.1.2, party B MAY include an additional query component in the
			redirection URI to indicate the scope requested in the reciprocal
			grant.
			reciprocal OPTIONAL. The scope of party B's reciprocal access
			request per [RFC6749] 3.3.
			If party B does not provide a reciprocal parameter in the
			authorization response, the reciprocal scope will be a value
			previously preconfigured by party A and party B.
			2.2. Reciprocal Authorization Flow
	The reciprocal authorization flow starts after the client (party A)		The reciprocal authorization flow starts after the client (party A)
	has obtained an access token from the authorization server (party B)		has obtained an access token from the authorization server (party B)
	per [RFC6749] 4.1 Authorization Code Grant.		per [RFC6749] 4.1 Authorization Code Grant.
	3.1. User Consent		2.2.1. User Consent
	Party A obtains consent from the user to grant Party B access to		Party A obtains consent from the user to grant Party B access to
	protected resources at party A. The consent represents the scopes		protected resources at party A. The consent represents the scopes
	party B had preconfigured at party A.		requested by party B from party A per Section 2.1.
	3.2. Reciprocal Authorization Code		2.2.2. Reciprocal Authorization Code
	Party A generates an authorization code representing the access		Party A generates an authorization code representing the access
	granted to party B by the user. Party A then makes a request to		granted to party B by the user. Party A then makes a request to
	party B's token endpoint authenticating per [RFC6749] 2.3 and sending		party B's token endpoint authenticating per [RFC6749] 2.3 and sending
	the following parameters using the "application/x-www-form-		the following parameters using the "application/x-www-form-
	urlencoded" format per [RFC6749] Appendix B with a character encoding		urlencoded" format per [RFC6749] Appendix B with a character encoding
	of UTF-8 in the HTTP request entity-body:		of UTF-8 in the HTTP request entity-body:
	grant_type REQUIRED. Value MUST be set to		grant_type REQUIRED
	"urn:ietf:params:oauth:grant-type:reciprocal".		Value MUST be set to "urn:ietf:params:oauth:grant-type:reciprocal".
	code REQUIRED. The authorization code generated by party A.		code REQUIRED
			the authorization code generated by party A.
	client_id REQUIRED, party A'a client ID.		client_id REQUIRED
			party A'a client ID.
	access_token REQUIRED, the access token obtained from Party B. Used		access_token REQUIRED the access token obtained from Party B. Used
	to provide user context.		by Party B to identify which user authorization is being requested.
	For example, the client makes the following HTTP request using TLS		For example, the client makes the following HTTP request using TLS
	(with extra line breaks for display purposes only):		(with extra line breaks for display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic ej4hsyfishwssjdusisdhkjsdksusdhjkjsdjk		Authorization: Basic ej4hsyfishwssjdusisdhkjsdksusdhjkjsdjk
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3reciprocal&code=hasdyubasdjahsbdkjbasd&client_id=example.com&access_token=sadadojsadlkjasdkljxxlkjdas		grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3reciprocal
			&code=hasdyubasdjahsbdkjbasd
			&client_id=example.com
			&access_token=sadadojsadlkjasdkljxxlkjdas
	Party B MUST verify the authentication provided by Party A per		Party B MUST verify the authentication provided by Party A per
	[RFC6749] 2.3		[RFC6749] 2.3
	Party B MUST then verify the access token was granted to the client		Party B MUST then verify the access token was granted to the client
	identified by the client_id.		identified by the client_id.
	Party B MUST respond with either an HTTP 200 (OK) response if the		Party B MUST respond with either an HTTP 200 (OK) response if the
	request is valid, or an HTTP 400 "Bad Request" if it is not.		request is valid, or an HTTP 400 "Bad Request" if it is not.
	Party B then plays the role of the client to make an access token		Party B then plays the role of the client to make an access token
	request per [RFC6749] 4.1.3.		request per [RFC6749] 4.1.3.
	4. Authorization Update Flow		3. Authorization Update Flow
	After the initial authorization, the user may add or remove scopes		After the initial authorization, the user may add or remove scopes
	available to the client at the authorization server. For example,		available to the client at the authorization server. For example,
	the user may grant additional scopes to the client using a voice		the user may grant additional scopes to the client using a voice
	interface, or revoke some scopes. The authorization server can		interface, or revoke some scopes. The authorization server can
	update the client with the new authorization by sending a new		update the client with the new authorization by sending a new
	authorization code per 3.2.		authorization code per Section 2.2.2.
	5. IANA Considerations		4. IANA Considerations
	TBD.		TBD.
	6. Acknowledgements		5. Acknowledgements
	TBD.		TBD.
	7. Normative References		6. 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>.
	skipping to change at page 5, line 29 ¶		skipping to change at page 7, line 22 ¶
	<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-reciprical-00
	o Initial version.		o Initial version.
	A.2. draft-ietf-oauth-reciprical-01		A.2. draft-ietf-oauth-reciprical-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
			o Added in diagram to clarify protocol flow
	Author's Address		Author's Address
	Dick Hardt		Dick Hardt
	Amazon
	Email: dick.hardt@gmail.com		Email: dick.hardt@gmail.com
End of changes. 29 change blocks.
	51 lines changed or deleted		122 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/