draft-ietf-oauth-saml2-bearer-09.txt   draft-ietf-oauth-saml2-bearer-10.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: April 3, 2012 Salesforce.com Expires: July 4, 2012 Salesforce.com
Oct 2011 Jan 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-09 draft-ietf-oauth-saml2-bearer-10
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 as well as for use as means for requesting an OAuth 2.0 access token as well as for use as
a means of client authentication. 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 April 3, 2012. This Internet-Draft will expire on July 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 27 skipping to change at page 6, line 27
of the authorization server. The authorization server MUST verify of the authorization server. The authorization server MUST verify
that the value of the Recipient attribute matches the token that the value of the Recipient attribute matches the token
endpoint URL (or an acceptable alias) to which the Assertion was endpoint URL (or an acceptable alias) to which the Assertion was
delivered. The <SubjectConfirmationData> element MUST have a delivered. The <SubjectConfirmationData> element MUST have a
NotOnOrAfter attribute that limits the window during which the NotOnOrAfter attribute that limits the window during which the
Assertion can be confirmed. The <SubjectConfirmationData> element Assertion can be confirmed. The <SubjectConfirmationData> element
MAY also contain an Address attribute limiting the client address MAY also contain an Address attribute limiting the client address
from which the Assertion can be delivered. Verification of the from which the Assertion can be delivered. Verification of the
Address is at the discretion of the authorization server. Address is at the discretion of the authorization server.
o The authorization server MUST verify that occurances of the o The authorization server MUST verify that occurrences of the
NotOnOrAfter instant has not passed, subject to allowable clock NotOnOrAfter instant has not passed, subject to allowable clock
skew between systems. An invalid NotOnOrAfter instant on the skew between systems. An invalid NotOnOrAfter instant on the
<Conditions> element invalidates the entire assertion. An invalid <Conditions> element invalidates the entire assertion. An invalid
NotOnOrAfter instant on a <SubjectConfirmationData> element only NotOnOrAfter instant on a <SubjectConfirmationData> element only
invalidates the individual <SubjectConfirmation>. The invalidates the individual <SubjectConfirmation>. The
authorization server MAY reject assertions with a NotOnOrAfter authorization server MAY reject assertions with a NotOnOrAfter
instant that is unreasonably far in the future. The authorization instant that is unreasonably far in the future. The authorization
server MAY ensure that Bearer Assertions are not replayed, by server MAY ensure that Bearer Assertions are not replayed, by
maintaining the set of used ID values for the length of time for maintaining the set of used ID values for the length of time for
which the Assertion would be considered valid based on the which the Assertion would be considered valid based on the
skipping to change at page 11, line 25 skipping to change at page 11, line 25
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 Tomilson, Scott Cantor, Michael Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael
Jones, Hannes Tschofenig, David Waite and Mukesh Bhatnagar. Jones, Hannes Tschofenig, David Waite and Mukesh 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-10
o fix a spelling mistake
draft-ietf-oauth-saml2-bearer-09 draft-ietf-oauth-saml2-bearer-09
o Attempt to address an ambiguity around validation requirements o Attempt to address an ambiguity around validation requirements
when the Conditions element contain a NotOnOrAfter and when the Conditions element contain a NotOnOrAfter and
SubjectConfirmation/SubjectConfirmationData does too. Basically SubjectConfirmation/SubjectConfirmationData does too. Basically
it needs to have at least one bearer SubjectConfirmation element it needs to have at least one bearer SubjectConfirmation element
but that element can omit SubjectConfirmationData, if Conditions but that element can omit SubjectConfirmationData, if Conditions
has an expiry on it. Otherwise, a valid SubjectConfirmation must has an expiry on it. Otherwise, a valid SubjectConfirmation must
have a SubjectConfirmationData with Recipient and NotOnOrAfter. have a SubjectConfirmationData with Recipient and NotOnOrAfter.
And any SubjectConfirmationData that has those elements needs to And any SubjectConfirmationData that has those elements needs to
have them checked. have them checked.
o clarified that AudienceRestriction is under Conditions (even o clarified that AudienceRestriction is under Conditions (even
though it's implied by schema) though it's implied by schema)
o fix a typo o fix a typo
draft-ietf-oauth-saml2-bearer-08 draft-ietf-oauth-saml2-bearer-08
o fix some typos o fix some typos
draft-ietf-oauth-saml2-bearer-07
o update reference from draft-campbell-oauth-urn-sub-ns to o update reference from draft-campbell-oauth-urn-sub-ns to
draft-ietf-oauth-urn-sub-ns draft-ietf-oauth-urn-sub-ns
o Updated to reference draft-ietf-oauth-v2-20 o Updated to reference draft-ietf-oauth-v2-20
draft-ietf-oauth-saml2-bearer-06 draft-ietf-oauth-saml2-bearer-06
o Fix three typos NamseID->NameID and (2x) Namspace->Namespace o Fix three typos NamseID->NameID and (2x) Namspace->Namespace
draft-ietf-oauth-saml2-bearer-05 draft-ietf-oauth-saml2-bearer-05
skipping to change at page 16, line 6 skipping to change at page 16, line 10
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. Standard OASIS.saml-profiles-2.0-os, March 2005.
[OASIS.saml-sec-consider-2.0-os] [OASIS.saml-sec-consider-2.0-os]
Hirsch, F., Philpott, R., and E. Maler, "Security and Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Markup Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS Standard saml-sec-consider- Language (SAML) V2.0", OASIS Standard saml-sec-consider-
2.0-os, March 2005. 2.0-os, March 2005.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Jacobs, I., and A. Hors, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Specification", World Wide Web Consortium
Recommendation REC-html401-19991224, December 1999, Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
Authors' Addresses Authors' Addresses
Brian Campbell (editor) Brian Campbell (editor)
Ping Identity Corp. Ping Identity Corp.
Email: brian.d.campbell@gmail.com Email: brian.d.campbell@gmail.com
 End of changes. 8 change blocks. 
10 lines changed or deleted 11 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/