draft-ietf-oauth-saml2-bearer-03.txt		draft-ietf-oauth-saml2-bearer-04.txt
	B. Campbell, Ed.		B. Campbell, Ed.
	Internet-Draft Ping Identity Corp.		Internet-Draft Ping Identity Corp.
	Intended status: Standards Track C. Mortimore		Intended status: Standards Track C. Mortimore
	Expires: August 8, 2011 Salesforce.com		Expires: November 24, 2011 Salesforce.com
	February 4, 2011		May 23, 2011
	SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0		SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0
	draft-ietf-oauth-saml2-bearer-03		draft-ietf-oauth-saml2-bearer-04
	Abstract		Abstract
	This specification defines the use of a SAML 2.0 Bearer Assertion as		This specification defines the use of a SAML 2.0 Bearer Assertion as
	means for requesting an OAuth 2.0 access token.		means for requesting an OAuth 2.0 access token.
	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.
	skipping to change at page 1, line 32		skipping to change at page 1, line 32
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 8, 2011.		This Internet-Draft will expire on November 24, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 19		skipping to change at page 2, line 19
	2. SAML Assertion Access Token Request . . . . . . . . . . . . . 4		2. SAML Assertion Access Token Request . . . . . . . . . . . . . 4
	2.1. Client Requests Access Token . . . . . . . . . . . . . . . 4		2.1. Client Requests Access Token . . . . . . . . . . . . . . . 4
	2.2. Assertion Format and Processing Requirements . . . . . . . 5		2.2. Assertion Format and Processing Requirements . . . . . . . 5
	2.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Example (non-normative) . . . . . . . . . . . . . . . . . 7		2.4. Example (non-normative) . . . . . . . . . . . . . . . . . 7
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 9		3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Parameter Registration Request . . . . . . . . . . . . . . 9		4.1. Parameter Registration Request . . . . . . . . . . . . . . 9
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 10		Appendix B. Document History . . . . . . . . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 11		5.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	5.2. Informative References . . . . . . . . . . . . . . . . . . 12		5.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Security Assertion Markup Language (SAML) 2.0		The Security Assertion Markup Language (SAML) 2.0
	[OASIS.saml-core-2.0-os] is an XML-based framework that allows		[OASIS.saml-core-2.0-os] is an XML-based framework that allows
	identity and security information to be shared across security		identity and security information to be shared across security
	domains. The SAML specification, while primarily targeted at		domains. The SAML specification, while primarily targeted at
	providing cross domain Web browser single sign-on, was also designed		providing cross domain Web browser single sign-on, was also designed
	to be modular and extensible to facilitate use in other contexts.		to be modular and extensible to facilitate use in other contexts.
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	| | | |		| | | |
	+--------+ +---------------+		+--------+ +---------------+
	Figure 1: Assertion Access Token Request		Figure 1: Assertion Access Token Request
	The request/response flow illustrated in Figure 1 includes the		The request/response flow illustrated in Figure 1 includes the
	following steps:		following steps:
	(A) The client sends an access token request to the authorization		(A) The client sends an access token request to the authorization
	server that includes a SAML 2.0 Assertion and a grant_type of		server that includes a SAML 2.0 Assertion and a grant_type of
	"http://oauth.net/grant_type/assertion/saml/2.0/bearer".		"http://oauth.net/grant_type/saml/2.0/bearer".
	(B) The authorization server validates the Assertion per the		(B) The authorization server validates the Assertion per the
	processing rules defined in this specification and issues an		processing rules defined in this specification and issues an
	access token.		access token.
	2.1. Client Requests Access Token		2.1. Client Requests Access Token
	The client includes the Assertion in the access token request, the		The client includes the Assertion in the access token request, the
	core details of which are defined in OAuth [I-D.ietf.oauth-v2], by		core details of which are defined in OAuth [I-D.ietf.oauth-v2], by
	specifying "http://oauth.net/grant_type/assertion/saml/2.0/bearer" as		specifying "http://oauth.net/grant_type/saml/2.0/bearer" as the
	the absolute URI value of the "grant_type" parameter and by adding		absolute URI value of the "grant_type" parameter and by adding the
	the following parameter:		following parameter:
	assertion		assertion
	REQUIRED. The value of the assertion parameter MUST contain a		REQUIRED. The value of the assertion parameter MUST contain a
	single SAML 2.0 Assertion. When used with the		single SAML 2.0 Assertion. When used with the
	"http://oauth.net/grant_type/assertion/saml/2.0/bearer" grant		"http://oauth.net/grant_type/saml/2.0/bearer" grant type, the
	type, the assertion MUST be a SAML 2.0 Assertion. The SAML		assertion MUST be a SAML 2.0 Assertion. The SAML Assertion XML
	Assertion XML data MUST be encoded using base64url, where the		data MUST be encoded using base64url, where the encoding
	encoding adheres to the definition in Section 5 of RFC4648		adheres to the definition in Section 5 of RFC4648 [RFC4648] and
	[RFC4648] and where the padding bits are set to zero. To to		where the padding bits are set to zero. To to avoid the need
	avoid the need for subsequent encoding steps (by "application/		for subsequent encoding steps (by "application/
	x-www-form-urlencoded" [W3C.REC-html401-19991224], for		x-www-form-urlencoded" [W3C.REC-html401-19991224], for
	example), the base64url encoded data SHOULD NOT be line wrapped		example), the base64url encoded data SHOULD NOT be line wrapped
	and pad characters ("=") SHOULD NOT be included.		and pad characters ("=") SHOULD NOT be included.
	scope		scope
	OPTIONAL. The scope of the access request is expressed as a		OPTIONAL. The scope of the access request expressed as a list
	list of space-delimited strings. The value is defined by the		of space-delimited, case sensitive strings. The value is
	authorization server. If the value contains multiple space-		defined by the authorization server. If the value contains
	delimited strings, their order does not matter, and each string		multiple space-delimited strings, their order does not matter,
	adds an additional access range to the requested scope.		and each string adds an additional access range to the
			requested scope.
	Authorization servers SHOULD issue access tokens with a limited		Authorization servers SHOULD issue access tokens with a limited
	lifetime and require clients to refresh them by requesting a new		lifetime and require clients to refresh them by requesting a new
	access token using the same assertion, if it is still valid, or with		access token using the same assertion, if it is still valid, or with
	a new assertion. The authorization server SHOULD NOT issue a refresh		a new assertion. The authorization server SHOULD NOT issue a refresh
	token.		token.
	2.2. Assertion Format and Processing Requirements		2.2. Assertion Format and Processing Requirements
	Prior to issuing an access token response as described in		Prior to issuing an access token response as described in
	skipping to change at page 9, line 13		skipping to change at page 9, line 13
	Figure 2: Example SAML 2.0 Assertion		Figure 2: Example SAML 2.0 Assertion
	To present the Assertion shown in the previous example as part of an		To present the Assertion shown in the previous example as part of an
	access token request, for example, the client might make the		access token request, for example, the client might make the
	following HTTPS request (line breaks are for display purposes only):		following HTTPS request (line breaks are for display purposes only):
	POST /token.oauth2 HTTP/1.1		POST /token.oauth2 HTTP/1.1
	Host: authz.example.net		Host: authz.example.net
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F		grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F
	saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ		bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
	[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-		[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
	Figure 3: Example Request		Figure 3: Example Request
	3. Security Considerations		3. Security Considerations
	No additional considerations beyond those described within the OAuth		No additional considerations beyond those described within the OAuth
	2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and		2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and
	Privacy Considerations for the OASIS Security Assertion Markup		Privacy Considerations for the OASIS Security Assertion Markup
	Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os].		Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os].
	skipping to change at page 10, line 9		skipping to change at page 10, line 9
	The following people contributed wording and concepts to this		The following people contributed wording and concepts to this
	document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran		document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran
	Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten		Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten
	Lodderstedt, Susan Harper, Scott Cantor, and David Waite		Lodderstedt, Susan Harper, Scott Cantor, and David Waite
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
			draft-ietf-oauth-saml2-bearer-04
			o Changed the grant_type URI from
			"http://oauth.net/grant_type/assertion/saml/2.0/bearer" to
			"http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word
			assertion from the path. Recent versions of draft-ietf-oauth-v2
			no longer refer to extension grants using the word assertion so
			this URI is more reflective of that. It also more closely aligns
			with the grant type URI in draft-jones-oauth-jwt-bearer-00 which
			is "http://oauth.net/grant_type/jwt/1.0/bearer".
			o Added "case sensitive" to scope definition to align with
			draft-ietf-oauth-v2-15/16.
			o Updated to reference draft-ietf-oauth-v2-16
	draft-ietf-oauth-saml2-bearer-03		draft-ietf-oauth-saml2-bearer-03
	o Cleanup of some editorial issues.		o Cleanup of some editorial issues.
	draft-ietf-oauth-saml2-bearer-02		draft-ietf-oauth-saml2-bearer-02
	o Added scope parameter with text copied from draft-ietf-oauth-v2-12		o Added scope parameter with text copied from draft-ietf-oauth-v2-12
	(the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't		(the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't
	really inherited by this spec anymore)		really inherited by this spec anymore)
	skipping to change at page 12, line 5		skipping to change at page 12, line 21
	o Initial I-D		o Initial I-D
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[I-D.ietf.oauth-v2]		[I-D.ietf.oauth-v2]
	Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The		Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The
	OAuth 2.0 Authorization Protocol",		OAuth 2.0 Authorization Protocol",
	ID draft-ietf-oauth-v2-12 (work in progress), Dec 2010.		ID draft-ietf-oauth-v2-16 (work in progress), May 2011.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	Markup Language (SAML) V2.0", OASIS Standard saml-core-		Markup Language (SAML) V2.0", OASIS Standard saml-core-
	2.0-os, March 2005.		2.0-os, March 2005.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 12 change blocks.
	25 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/