--- 1/draft-ietf-oauth-saml2-bearer-09.txt 2012-01-03 18:14:01.942670793 +0100 +++ 2/draft-ietf-oauth-saml2-bearer-10.txt 2012-01-03 18:14:01.966670860 +0100 @@ -1,19 +1,19 @@ B. Campbell, Ed. Internet-Draft Ping Identity Corp. Intended status: Standards Track C. Mortimore -Expires: April 3, 2012 Salesforce.com - Oct 2011 +Expires: July 4, 2012 Salesforce.com + Jan 2012 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 - draft-ietf-oauth-saml2-bearer-09 + draft-ietf-oauth-saml2-bearer-10 Abstract 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 a means of client authentication. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -22,25 +22,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -229,21 +229,21 @@ of the authorization server. The authorization server MUST verify that the value of the Recipient attribute matches the token endpoint URL (or an acceptable alias) to which the Assertion was delivered. The element MUST have a NotOnOrAfter attribute that limits the window during which the Assertion can be confirmed. The element MAY also contain an Address attribute limiting the client address from which the Assertion can be delivered. Verification of the 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 skew between systems. An invalid NotOnOrAfter instant on the element invalidates the entire assertion. An invalid NotOnOrAfter instant on a element only invalidates the individual . The authorization server MAY reject assertions with a NotOnOrAfter instant that is unreasonably far in the future. The authorization server MAY ensure that Bearer Assertions are not replayed, by maintaining the set of used ID values for the length of time for which the Assertion would be considered valid based on the @@ -417,43 +417,44 @@ The following people contributed wording and concepts to this document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael Jones, Hannes Tschofenig, David Waite and Mukesh Bhatnagar. Appendix B. Document History [[ 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 o Attempt to address an ambiguity around validation requirements when the Conditions element contain a NotOnOrAfter and SubjectConfirmation/SubjectConfirmationData does too. Basically it needs to have at least one bearer SubjectConfirmation element but that element can omit SubjectConfirmationData, if Conditions has an expiry on it. Otherwise, a valid SubjectConfirmation must have a SubjectConfirmationData with Recipient and NotOnOrAfter. And any SubjectConfirmationData that has those elements needs to have them checked. o clarified that AudienceRestriction is under Conditions (even though it's implied by schema) o fix a typo draft-ietf-oauth-saml2-bearer-08 o fix some typos - - draft-ietf-oauth-saml2-bearer-07 - o update reference from draft-campbell-oauth-urn-sub-ns to draft-ietf-oauth-urn-sub-ns o Updated to reference draft-ietf-oauth-v2-20 draft-ietf-oauth-saml2-bearer-06 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace draft-ietf-oauth-saml2-bearer-05 @@ -633,21 +633,21 @@ Security Assertion Markup Language (SAML) V2.0", OASIS Standard OASIS.saml-profiles-2.0-os, March 2005. [OASIS.saml-sec-consider-2.0-os] Hirsch, F., Philpott, R., and E. Maler, "Security and Privacy Considerations for the OASIS Security Markup Language (SAML) V2.0", OASIS Standard saml-sec-consider- 2.0-os, March 2005. [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 Recommendation REC-html401-19991224, December 1999, . Authors' Addresses Brian Campbell (editor) Ping Identity Corp. Email: brian.d.campbell@gmail.com