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 15, line 5 skipping to change at page 15, line 22
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. 16 change blocks. 
29 lines changed or deleted 44 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/