< draft-hardt-oauth-mutual-00.txt		draft-hardt-oauth-mutual-01.txt >
	Network Working Group D. Hardt		Network Working Group D. Hardt
	Internet-Draft Amazon		Internet-Draft Amazon
	Intended status: Informational November 13, 2017		Intended status: Informational January 16, 2018
	Expires: May 17, 2018		Expires: July 20, 2018
	This is an Internet-draft		Reciprical OAuth
	draft-hardt-oauth-mutual-00		draft-hardt-oauth-mutual-01
	Abstract		Abstract
	There are times when a user has a pair protected resources that would		There are times when a user has a pair of protected resources that
	like to request access to each other. While OAuth flows typically		would like to request access to each other. While OAuth flows
	enable the user to grant a client access to a protected resource,		typically enable the user to grant a client access to a protected
	granting the inverse access requires an additional flow. Mutual		resource, granting the inverse access requires an additional flow.
	OAuth enables a more seemless experience for the user to grant access		Reciprical OAuth enables a more seemless experience for the user to
	to a pair of protected resources.		grant access to a pair of protected resources.
	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 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 17, 2018.		This Internet-Draft will expire on July 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	In the usual three legged, authorization code grant, OAuth flow		In the usual three legged, authorization code grant, the OAuth flow
	enables a resource owner (user) to enable a client (party A) to be		enables a resource owner (user) to enable a client (party A) to be
	granted authorization to access a protected resource (party B). If		granted authorization to access a protected resource (party B). If
	party A also has a protected resource that the user would like to let		party A also has a protected resource that the user would like to let
	party B access, then a complete OAuth flow, but in the reverse		party B access, then a complete OAuth flow, but in the reverse
	direction, must be performed.		direction, must be performed.
	Mutual OAuth enables party A to obtain constent from the user to		Reciprical OAuth enables party A to obtain constent from the user to
	grant access to a protected resource at party A, and to short circuit		grant access to a protected resource at party A, and to short circuit
	the OAuth flow by passing an authorization code to party B using the		the OAuth flow by passing an authorization code to party B using the
	acces token party A obtained from party B to provide party B the		acces token party A obtained from party B to provide party B the
	context of the user. This simplifies the user experience for each		context of the user. This simplifies the user experience for each
	party to obtain acces tokens from the other.		party to obtain acces tokens from the other.
	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. Mutual Authorization Flow		2. Reciprical Authorization Flow
	The mutual authorization flow starts after the client (party A) has		The reciprical authorization flow starts after the client (party A)
	obtained an access token from the authorization server (party B) per		has obtained an access token from the authorization server (party B)
	[RFC6749] 4.1 Authorization Code Grant.		per [RFC6749] 4.1 Authorization Code Grant.
	After party A obtains consent from the user to grant access to		2.1. User Consent
	protected resources at party A, party A generates an authorization
	code representing the access granted to party B for that user. Party		Party A obtains consent from the user to grant access to protected
	A then makes a request to party B's token endpoint by sending the		resources at party A. The consent represents the scopes party B had
	following parameters using the "application/x-www-form-urlencoded"		preconfigured at party A.
	format per [RFC6749] Appendix B with a character encoding of UTF-8 in
	the HTTP request entity-body:		2.2. Reciprical Authorization Code
			Party A generates an authorization code representing the access
			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
			the following parameters using the "application/x-www-form-
			urlencoded" format per [RFC6749] Appendix B with a character encoding
			of UTF-8 in the HTTP request entity-body:
	grant_type REQUIRED. Value MUST be set to		grant_type REQUIRED. Value MUST be set to
	"mutual_authorization_code".		"reciprical_authorization_code". [DH: should this be a URI?]
	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.
	and pass the access token obtained from Party B in the HTTP		access_token REQUIRED, the access token obtained from Party B. Used
	authorization header.		to provide user context. [DH: security concerns passing the access
			token in the body?]
	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: Bearer ej4hsyfishwssjdusisdhkjsdksusdhjkjsdjk		Authorization: Basic ej4hsyfishwssjdusisdhkjsdksusdhjkjsdjk
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=mutual_authorization_code&code=hasdyubasdjahsbdkjbasd		grant_type=mutual_authorization_code&code=hasdyubasdjahsbdkjbasd&client_id=example.com&access_token=sadadojsadlkjasdkljxxlkjdas
	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 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.
	3. IANA Considerations		3. IANA Considerations
	TBD.		TBD.
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 11 ¶
	[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>.
	[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-hardt-distributed-oauth-00
			A.1. draft-hardt-oauth-mutual-00
	o Initial version.		o Initial version.
			A.2. draft-hardt-oauth-mutual-01
			o renamed to Reciprical OAuth
			o clarified user consent in reciprical flow
			o changed authentication to be client authentication per [RFC6749]
			2.3
	Author's Address		Author's Address
	Dick Hardt		Dick Hardt
	Amazon		Amazon
	Email: dick.hardt@gmail.com		Email: dick.hardt@gmail.com
End of changes. 16 change blocks.
	34 lines changed or deleted		52 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/