< draft-ietf-oauth-token-exchange-15.txt		draft-ietf-oauth-token-exchange-16.txt >
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft A. Nadalin		Internet-Draft A. Nadalin
	Intended status: Standards Track Microsoft		Intended status: Standards Track Microsoft
	Expires: March 14, 2019 B. Campbell, Ed.		Expires: April 22, 2019 B. Campbell, Ed.
	J. Bradley		J. Bradley
	Ping Identity		Ping Identity
	C. Mortimore		C. Mortimore
	Salesforce		Salesforce
	September 10, 2018		October 19, 2018
	OAuth 2.0 Token Exchange		OAuth 2.0 Token Exchange
	draft-ietf-oauth-token-exchange-15		draft-ietf-oauth-token-exchange-16
	Abstract		Abstract
	This specification defines a protocol for an HTTP- and JSON- based		This specification defines a protocol for an HTTP- and JSON- based
	Security Token Service (STS) by defining how to request and obtain		Security Token Service (STS) by defining how to request and obtain
	security tokens from OAuth 2.0 authorization servers, including		security tokens from OAuth 2.0 authorization servers, including
	security tokens employing impersonation and delegation.		security tokens employing impersonation and delegation.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 March 14, 2019.		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 10, line 42 ¶		skipping to change at page 10, line 42 ¶
	resource even when the original credential is no longer valid		resource even when the original credential is no longer valid
	(e.g., user-not-present or offline scenarios where there is no		(e.g., user-not-present or offline scenarios where there is no
	longer any user entertaining an active session with the client).		longer any user entertaining an active session with the client).
	Profiles or deployments of this specification should clearly		Profiles or deployments of this specification should clearly
	document the conditions under which a client should expect a		document the conditions under which a client should expect a
	refresh token in response to "urn:ietf:params:oauth:grant-		refresh token in response to "urn:ietf:params:oauth:grant-
	type:token-exchange" grant type requests.		type:token-exchange" grant type requests.
	2.2.2. Error Response		2.2.2. Error Response
	IF the request itself is not valid or if either the "subject_token"		If the request itself is not valid or if either the "subject_token"
	or "actor_token" are invalid for any reason, or are unacceptable		or "actor_token" are invalid for any reason, or are unacceptable
	based on policy, the authorization server MUST construct an error		based on policy, the authorization server MUST construct an error
	response, as specified in Section 5.2 of [RFC6749]. The value of the		response, as specified in Section 5.2 of [RFC6749]. The value of the
	"error" parameter MUST be the "invalid_request" error code.		"error" parameter MUST be the "invalid_request" error code.
	If the authorization server is unwilling or unable to issue a token		If the authorization server is unwilling or unable to issue a token
	for all the target services indicated by the "resource" or "audience"		for all the target services indicated by the "resource" or "audience"
	parameters, the "invalid_target" error code SHOULD be used in the		parameters, the "invalid_target" error code SHOULD be used in the
	error response.		error response.
	skipping to change at page 29, line 31 ¶		skipping to change at page 29, line 31 ¶
	}		}
	}		}
	Figure 18: Issued Token Claims		Figure 18: Issued Token Claims
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	This specification was developed within the OAuth Working Group,		This specification was developed within the OAuth Working Group,
	which includes dozens of active and dedicated participants. It was		which includes dozens of active and dedicated participants. It was
	produced under the chairmanship of Hannes Tschofenig, Derek Atkins,		produced under the chairmanship of Hannes Tschofenig, Derek Atkins,
	and Rifaat Shekh-Yusef with Kathleen Moriarty, Stephen Farrell, and		and Rifaat Shekh-Yusef with Kathleen Moriarty, Stephen Farrell, Eric
	Eric Rescorla serving as Security Area Directors. The following		Rescorla, and Benjamin Kaduk serving as Security Area Directors. The
	individuals contributed ideas, feedback, and wording to this		following individuals contributed ideas, feedback, and wording to
	specification:		this specification:
	Caleb Baker, Vittorio Bertocci, Thomas Broyer, William Denniss,		Caleb Baker, Vittorio Bertocci, Thomas Broyer, William Denniss,
	Vladimir Dzhuvinov, Phil Hunt, Benjamin Kaduk, Jason Keglovitz,		Vladimir Dzhuvinov, Phil Hunt, Benjamin Kaduk, Jason Keglovitz,
	Torsten Lodderstedt, Adam Lewis, James Manger, Nov Matake, Matt		Torsten Lodderstedt, Adam Lewis, James Manger, Nov Matake, Matt
	Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer,		Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer,
	Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig.		Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig.
	Appendix C. Document History		Appendix C. 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 ]]
	-15		-16
			o Fixed typo and added an AD to Acknowledgements.
			-15
	o Updated the nested actor claim example to (hopefully) be more		o Updated the nested actor claim example to (hopefully) be more
	straightforward.		straightforward.
	o Reworked Privacy Considerations to say to use TLS in transit,		o Reworked Privacy Considerations to say to use TLS in transit,
	minimize the amount of information in the token, and encrypt the		minimize the amount of information in the token, and encrypt the
	token if disclosure of its information to the client is a concern		token if disclosure of its information to the client is a concern
	per https://mailarchive.ietf.org/arch/msg/secdir/		per https://mailarchive.ietf.org/arch/msg/secdir/
	KJhx4aq_U5uk3k6zpYP-CEHbpVM		KJhx4aq_U5uk3k6zpYP-CEHbpVM
	o Moved the Security and Privacy Considerations sections to before		o Moved the Security and Privacy Considerations sections to before
	the IANA Considerations.		the IANA Considerations.
End of changes. 8 change blocks.
	10 lines changed or deleted		13 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/