< draft-ietf-oauth-reciprocal-00.txt		draft-ietf-oauth-reciprocal-01.txt >
	OAuth Working Group D. Hardt		OAuth Working Group D. Hardt
	Internet-Draft Amazon		Internet-Draft Amazon
	Intended status: Standards Track May 26, 2018		Intended status: Standards Track October 19, 2018
	Expires: November 27, 2018		Expires: April 22, 2019
	Reciprocal OAuth		Reciprocal OAuth
	draft-ietf-oauth-reciprocal-00		draft-ietf-oauth-reciprocal-01
	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 November 27, 2018.		This Internet-Draft will expire on April 22, 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 38 ¶		skipping to change at page 2, line 38 ¶
	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. Reciprocal Scope Request
	When party B is providing an authorization response per [RFC6749]		When party B is providing an access token response per [RFC6749]
	4.1.2, party B MAY include an additional query component in the		4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query
	redirection URI to indicate the scope requested in the reciprocal		component in the redirection URI to indicate the scope requested in
	grant.		the reciprocal grant.
	reciprocal OPTIONAL. The scope of party B's reciprocal access		reciprocal OPTIONAL. The scope of party B's reciprocal access
	request per [RFC6749] 3.3.		request per [RFC6749] 3.3.
	If party B does not provide a reciprocal parameter in the		If party B does not provide a reciprocal parameter in the access
	authorization response, the reciprocal scope will be a value		token response, the reciprocal scope will be a value previously
	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]
			4.1.4, an example successful response:
			HTTP/1.1 200 OK
			Content-Type: application/json;charset=UTF-8
			Cache-Control: no-store
			Pragma: no-cache
			{
			"access_token":"2YotnFZFEjr1zCsicMWpAA",
			"token_type":"example",
			"expires_in":3600,
			"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
			"reciprocal":"example_scope",
			"example_parameter":"example_value"
			}
			If an authorization code grant access token response per [RFC6749]
			4.2.2, an example successful response (with extra line breaks for
			display purposes only):
			HTTP/1.1 302 Found
			Location: http://example.com/cb#
			access_token=2YotnFZFEjr1zCsicMWpAA&
			state=xyz&token_type=example&
			expires_in=3600&
			reciprocal="example_scope"
	3. Reciprocal Authorization Flow		3. 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		3.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
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 34 ¶
	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. IANA Considerations		4. Authorization Update Flow
			After the initial authorization, the user may add or remove scopes
			available to the client at the authorization server. For example,
			the user may grant additional scopes to the client using a voice
			interface, or revoke some scopes. The authorization server can
			update the client with the new authorization by sending a new
			authorization code per 3.2.
			5. IANA Considerations
	TBD.		TBD.
	5. Acknowledgements		6. Acknowledgements
	TBD.		TBD.
	6. Normative References		7. 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 4, line 41 ¶		skipping to change at page 5, line 27 ¶
	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-reciprical-00
	o Initial version.		o Initial version.
			A.2. draft-ietf-oauth-reciprical-01
			o changed reciprocal scope request to be in access token response
			rather than authorization request
	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. 9 change blocks.
	14 lines changed or deleted		56 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/