< draft-ietf-oauth-saml2-bearer-12.txt		draft-ietf-oauth-saml2-bearer-13.txt >
	B. Campbell, Ed.		OAuth Working Group B. Campbell
	Internet-Draft Ping Identity		Internet-Draft Ping Identity
	Intended status: Standards Track C. Mortimore		Intended status: Standards Track C. Mortimore
	Expires: November 4, 2012 Salesforce		Expires: January 4, 2013 Salesforce
	May 3, 2012		July 3, 2012
	SAML 2.0 Bearer Assertion Profiles for OAuth 2.0		SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
	draft-ietf-oauth-saml2-bearer-12		draft-ietf-oauth-saml2-bearer-13
	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
	a means for requesting an OAuth 2.0 access token as well as for use		a means for requesting an OAuth 2.0 access token as well as for use
	as a means of client authentication.		as a means of client authentication.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 November 4, 2012.		This Internet-Draft will expire on January 4, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 28 ¶		skipping to change at page 2, line 28 ¶
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Sub-Namespace Registration of		6.1. Sub-Namespace Registration of
	urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10		urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10
	6.2. Sub-Namespace Registration of		6.2. Sub-Namespace Registration of
	urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 11		urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	7.2. Informative References . . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	Appendix B. Document History . . . . . . . . . . . . . . . . . . 12		Appendix B. Document History . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	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 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	<SubjectConfirmation> element that allows the authorization server		<SubjectConfirmation> element that allows the authorization server
	to confirm it as a Bearer Assertion. Such a <SubjectConfirmation>		to confirm it as a Bearer Assertion. Such a <SubjectConfirmation>
	element MUST have a Method attribute with a value of		element MUST have a Method attribute with a value of
	"urn:oasis:names:tc:SAML:2.0:cm:bearer". The		"urn:oasis:names:tc:SAML:2.0:cm:bearer". The
	<SubjectConfirmation> element MUST contain a		<SubjectConfirmation> element MUST contain a
	<SubjectConfirmationData> element, unless the Assertion has a		<SubjectConfirmationData> element, unless the Assertion has a
	suitable NotOnOrAfter attribute on the <Conditions> element, in		suitable NotOnOrAfter attribute on the <Conditions> element, in
	which case the <SubjectConfirmationData> element MAY be omitted.		which case the <SubjectConfirmationData> element MAY be omitted.
	When present, the <SubjectConfirmationData> element MUST have a		When present, the <SubjectConfirmationData> element MUST have a
	Recipient attribute with a value indicating the token endpoint URL		Recipient attribute with a value indicating the token endpoint URL
	of the authorization server. The authorization server MUST verify		of the authorization server (or an acceptable alias). The
	that the value of the Recipient attribute matches the token		authorization server MUST verify that the value of the Recipient
	endpoint URL (or an acceptable alias) to which the Assertion was		attribute matches the token endpoint URL (or an acceptable alias)
	delivered. The <SubjectConfirmationData> element MUST have a		to which the Assertion was delivered. The
	NotOnOrAfter attribute that limits the window during which the		<SubjectConfirmationData> element MUST have a NotOnOrAfter
	Assertion can be confirmed. The <SubjectConfirmationData> element		attribute that limits the window during which the Assertion can be
	MAY also contain an Address attribute limiting the client address		confirmed. The <SubjectConfirmationData> element MAY also contain
	from which the Assertion can be delivered. Verification of the		an Address attribute limiting the client address from which the
	Address is at the discretion of the authorization server.		Assertion can be delivered. Verification of the Address is at the
			discretion of the authorization server.
	o The authorization server MUST verify that the NotOnOrAfter instant		o The authorization server MUST verify that the NotOnOrAfter instant
	has not passed, subject to allowable clock skew between systems.		has not passed, subject to allowable clock skew between systems.
	An invalid NotOnOrAfter instant on the <Conditions> element		An invalid NotOnOrAfter instant on the <Conditions> element
	invalidates the entire Assertion. An invalid NotOnOrAfter instant		invalidates the entire Assertion. An invalid NotOnOrAfter instant
	on a <SubjectConfirmationData> element only invalidates the		on a <SubjectConfirmationData> element only invalidates the
	individual <SubjectConfirmation>. The authorization server MAY		individual <SubjectConfirmation>. The authorization server MAY
	reject Assertions with a NotOnOrAfter instant that is unreasonably		reject Assertions with a NotOnOrAfter instant that is unreasonably
	far in the future. The authorization server MAY ensure that		far in the future. The authorization server MAY ensure that
	Bearer Assertions are not replayed, by maintaining the set of used		Bearer Assertions are not replayed, by maintaining the set of used
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	established in An IETF URN Sub-Namespace for OAuth		established in An IETF URN Sub-Namespace for OAuth
	[I-D.ietf-oauth-urn-sub-ns].		[I-D.ietf-oauth-urn-sub-ns].
	o URN: urn:ietf:params:oauth:grant-type:saml2-bearer		o URN: urn:ietf:params:oauth:grant-type:saml2-bearer
	o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for		o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for
	OAuth 2.0		OAuth 2.0
	o Change controller: IETF		o Change controller: IETF
	o Description: [[this document]]		o Specification Document: [[this document]]
	6.2. Sub-Namespace Registration of		6.2. Sub-Namespace Registration of
	urn:ietf:params:oauth:client-assertion-type:saml2-bearer		urn:ietf:params:oauth:client-assertion-type:saml2-bearer
	This is a request to IANA to please register the value		This is a request to IANA to please register the value
	"client-assertion-type:saml2-bearer" in the registry		"client-assertion-type:saml2-bearer" in the registry
	urn:ietf:params:oauth established in An IETF URN Sub-Namespace for		urn:ietf:params:oauth established in An IETF URN Sub-Namespace for
	OAuth [I-D.ietf-oauth-urn-sub-ns].		OAuth [I-D.ietf-oauth-urn-sub-ns].
	o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer		o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer
	o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0		o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0
	Client Authentication		Client Authentication
	o Change controller: IETF		o Change controller: IETF
	o Description: [[this document]]		o Specification Document: [[this document]]
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-oauth-assertions]		[I-D.ietf-oauth-assertions]
	Jones, M., Campbell, B., and Y. Goland, "OAuth 2.0		Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
	Assertion Profile", draft-ietf-oauth-assertions-03 (work		"Assertion Framework for OAuth 2.0",
	in progress), May 2012.		draft-ietf-oauth-assertions-04 (work in progress),
			July 2012.
	[I-D.ietf-oauth-urn-sub-ns]		[I-D.ietf-oauth-urn-sub-ns]
	Tschofenig, H., "An IETF URN Sub-Namespace for OAuth",		Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
	draft-ietf-oauth-urn-sub-ns-02 (work in progress),		for OAuth", draft-ietf-oauth-urn-sub-ns-05 (work in
	January 2012.		progress), June 2012.
	[I-D.ietf-oauth-v2]		[I-D.ietf-oauth-v2]
	Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth		Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
	2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work		2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work
	in progress), May 2012.		in progress), June 2012.
	[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.
	skipping to change at page 12, line 42 ¶		skipping to change at page 12, line 43 ¶
	document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran		document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran
	Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten		Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten
	Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B.		Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B.
	Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh		Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh
	Bhatnagar.		Bhatnagar.
	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-13
			o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth
			-28
			o Changed "Description" to "Specification Document" in both
			registration requests in IANA Considerations per changes to the
			template in ietf-oauth-urn-sub-ns(-03)
			o Added "(or an acceptable alias)" so that it's in both sentences
			about Recipient and the token endpoint URL so there's no ambiguity
			o (now Security and OAuth was Internet and nothing)
	draft-ietf-oauth-saml2-bearer-12		draft-ietf-oauth-saml2-bearer-12
	o updated reference to draft-ietf-oauth-v2 from -25 to -26 and		o updated reference to draft-ietf-oauth-v2 from -25 to -26 and
	draft-ietf-oauth-assertions from -02 to -03		draft-ietf-oauth-assertions from -02 to -03
	draft-ietf-oauth-saml2-bearer-11		draft-ietf-oauth-saml2-bearer-11
	o Removed text about limited lifetime access tokens and the SHOULD		o Removed text about limited lifetime access tokens and the SHOULD
	NOT on issuing refresh tokens. The text was moved to		NOT on issuing refresh tokens. The text was moved to
	draft-ietf-oauth-assertions-02 and somewhat modified per		draft-ietf-oauth-assertions-02 and somewhat modified per
	skipping to change at page 14, line 34 ¶		skipping to change at page 15, line 4 ¶
	o remove scope parameter as it is defined in		o remove scope parameter as it is defined in
	http://tools.ietf.org/html/draft-ietf-oauth-assertions		http://tools.ietf.org/html/draft-ietf-oauth-assertions
	o remove assertion param registration because it [should] be in		o remove assertion param registration because it [should] be in
	http://tools.ietf.org/html/draft-ietf-oauth-assertions		http://tools.ietf.org/html/draft-ietf-oauth-assertions
	o fix typo(s) and update/add references		o fix typo(s) and update/add references
	draft-ietf-oauth-saml2-bearer-04		draft-ietf-oauth-saml2-bearer-04
	o Changed the grant_type URI from		o Changed the grant_type URI from
	"http://oauth.net/grant_type/assertion/saml/2.0/bearer" to		"http://oauth.net/grant_type/assertion/saml/2.0/bearer" to
	"http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word		"http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word
	assertion from the path. Recent versions of draft-ietf-oauth-v2		assertion from the path. Recent versions of draft-ietf-oauth-v2
	no longer refer to extension grants using the word assertion so		no longer refer to extension grants using the word assertion so
	this URI is more reflective of that. It also more closely aligns		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		with the grant type URI in draft-jones-oauth-jwt-bearer-00 which
	is "http://oauth.net/grant_type/jwt/1.0/bearer".		is "http://oauth.net/grant_type/jwt/1.0/bearer".
	o Added "case sensitive" to scope definition to align with		o Added "case sensitive" to scope definition to align with
	draft-ietf-oauth-v2-15/16.		draft-ietf-oauth-v2-15/16.
	o Updated to reference draft-ietf-oauth-v2-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
	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)
	o Change definition of the assertion parameter to be more generally		o Change definition of the assertion parameter to be more generally
	applicable per the suggestion near the end of		applicable per the suggestion near the end of
	http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html		http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html
	o Editorial changes based on feedback		o Editorial changes based on feedback
	skipping to change at page 15, line 33 ¶		skipping to change at page 16, line 5 ¶
	o Updated to reference draft-ietf-oauth-v2-12 and denote as work in		o Updated to reference draft-ietf-oauth-v2-12 and denote as work in
	progress		progress
	o Update Parameter Registration Request to use similar terms as		o Update Parameter Registration Request to use similar terms as
	draft-ietf-oauth-v2-12 and remove Related information part		draft-ietf-oauth-v2-12 and remove Related information part
	o Add some text giving discretion to AS on rejecting assertions with		o Add some text giving discretion to AS on rejecting assertions with
	unreasonably long validity window.		unreasonably long validity window.
	draft-ietf-oauth-saml2-bearer-00
	o Added Parameter Registration Request for "assertion" to IANA		o Added Parameter Registration Request for "assertion" to IANA
	Considerations.		Considerations.
	o Changed document name to draft-ietf-oauth-saml2-bearer in		o Changed document name to draft-ietf-oauth-saml2-bearer in
	anticipation of becoming an OAUTH WG item.		anticipation of becoming an OAUTH WG item.
	o Attempt to move the entire definition of the 'assertion' parameter		o Attempt to move the entire definition of the 'assertion' parameter
	into this draft (it will no longer be defined in OAuth 2 Protocol		into this draft (it will no longer be defined in OAuth 2 Protocol
	Framework).		Framework).
	skipping to change at page 16, line 36 ¶		skipping to change at page 17, line 4 ¶
	o Changed the grant_type (was assertion_type) URI from		o Changed the grant_type (was assertion_type) URI from
	http://oauth.net/assertion_type/saml/2.0/bearer to		http://oauth.net/assertion_type/saml/2.0/bearer to
	http://oauth.net/grant_type/assertion/saml/2.0/bearer		http://oauth.net/grant_type/assertion/saml/2.0/bearer
	o Changed title to include "Grant Type" in it.		o Changed title to include "Grant Type" in it.
	o Editorial updates based on feedback from the WG and others		o Editorial updates based on feedback from the WG and others
	(including capitalization of Assertion when referring to SAML).		(including capitalization of Assertion when referring to SAML).
	draft-campbell-oauth-saml-00		draft-campbell-oauth-saml-00
	o Initial I-D		o Initial I-D
	Authors' Addresses		Authors' Addresses
	Brian Campbell (editor)		Brian Campbell
	Ping Identity Corp.		Ping Identity Corp.
	Email: brian.d.campbell@gmail.com		Email: brian.d.campbell@gmail.com
	Chuck Mortimore		Chuck Mortimore
	Salesforce.com		Salesforce.com
	Email: cmortimore@salesforce.com		Email: cmortimore@salesforce.com
End of changes. 17 change blocks.
	30 lines changed or deleted		44 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/