--- 1/draft-ietf-oauth-saml2-bearer-08.txt 2011-10-28 20:14:05.286671529 +0200 +++ 2/draft-ietf-oauth-saml2-bearer-09.txt 2011-10-28 20:14:05.310672967 +0200 @@ -1,19 +1,19 @@ B. Campbell, Ed. Internet-Draft Ping Identity Corp. Intended status: Standards Track C. Mortimore -Expires: February 2, 2012 Salesforce.com - Aug 2011 +Expires: April 3, 2012 Salesforce.com + Oct 2011 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 - draft-ietf-oauth-saml2-bearer-08 + draft-ietf-oauth-saml2-bearer-09 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,21 +22,21 @@ 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 February 2, 2012. + This Internet-Draft will expire on April 3, 2012. Copyright Notice Copyright (c) 2011 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 @@ -58,24 +58,24 @@ 3.2. Client Authentication Processing . . . . . . . . . . . . . 8 4. Authorization Grant Example (non-normative) . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10 6.2. Sub-Namespace Registration of urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 10 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] is an XML-based framework that allows identity and security information to be shared across security domains. The SAML specification, while primarily targeted at providing cross domain Web browser single sign-on, was also designed to be modular and extensible to facilitate use in other contexts. @@ -114,22 +114,22 @@ extent reasonable, concepts and patterns from that well-established Profile. This document defines how a SAML Assertion can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of (and digital signature calculated over) the SAML Assertion, without a direct user approval step at the authorization server. It also defines how a SAML Assertion can be used as a client authentication mechanism. The use of an Assertion for client authentication is orthogonal and - separable from using an Assertion as an authorization grant and can - be used either in combination or in isolation. + separable from using an Assertion as an authorization grant and the + two can be used either in combination or in isolation. The process by which the client obtains the SAML Assertion, prior to exchanging it with the authorization server or using it for client authentication, is out of scope. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. @@ -183,85 +183,78 @@ In order to issue an access token response as described in The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] or to rely on an assertion for client authentication, the authorization server MUST validate the Assertion according to the criteria below. Application of additional restrictions and policy are at the discretion of the authorization server. o The Assertion's element MUST contain a unique identifier for the entity that issued the Assertion. - o The Assertion MUST contain an element with - an element containing a URI reference that identifies - the authorization server, or the service provider SAML entity of - its controlling domain, as an intended audience. The token - endpoint URL of the authorization server MAY be used as an - acceptable value for an element. The authorization - server MUST verify that it is an intended audience for the - Assertion. + o The Assertion MUST contain element with an + element with an element + containing a URI reference that identifies the authorization + server, or the service provider SAML entity of its controlling + domain, as an intended audience. The token endpoint URL of the + authorization server MAY be used as an acceptable value for an + element. The authorization server MUST verify that it + is an intended audience for the Assertion. o The Assertion MUST contain a element. The subject MAY identify the resource owner for whom the access token is being requested. For client authentication, the Subject MUST be the client_id of the OAuth client. When using assertions as an authorization grant, the Subject SHOULD identify an authorized accessor for whom the access token is being requested (typically the resource owner, or an authorized delegate). Additional information identifying the subject/principal of the transaction MAY be included in an . o The Assertion MUST have an expiry that limits the time window - during which the it can be used. The expiry can be expressed - either as the NotOnOrAfter attribute of the element - or as the NotOnOrAfter attribute of a suitable - element. - - If the Assertion has a NotOnOrAfter attribute on the - element, the authorization server MUST verify that the - NotOnOrAfter instant has not passed, subject to allowable clock - skew between systems. The authorization server SHOULD reject - assertions with an expiry instant that is unreasonably far in the - future. - - If the Assertion does not have a NotOnOrAfter attribute on the - element, then the Assertion's element MUST - contain at least one element that allows the - authorization server to confirm it as a Bearer Assertion. - Conditions for bearer subject confirmation are described below. - - * The element. + during which it can be used. The expiry can be expressed either + as the NotOnOrAfter attribute of the element or as + the NotOnOrAfter attribute of a suitable + element. - * The element MUST have a Recipient - attribute with a value indicating the token endpoint URL of the - authorization server. The authorization server MUST verify + o The element MUST contain at least one + element that allows the authorization server + to confirm it as a Bearer Assertion. Such a + element MUST have a Method attribute with a value of + "urn:oasis:names:tc:SAML:2.0:cm:bearer". The + element MUST contain a + element, unless the Assertion has a + suitable NotOnOrAfter attribute on the element, in + which case the element MAY be omitted. + When present, the element MUST have a + Recipient attribute with a value indicating the token endpoint URL + 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. + 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. - * The element MUST have a NotOnOrAfter - attribute that limits the window during which the Assertion can - be confirmed. The authorization server MUST verify that the + o The authorization server MUST verify that occurances of the NotOnOrAfter instant has not passed, subject to allowable clock - skew between systems. 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 NotOnOrAfter attribute - in the . The authorization server MAY - reject assertions with a NotOnOrAfter instant that is - unreasonably far in the future. - - * 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. + 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 + applicable NotOnOrAfter instant. o If the Assertion issuer authenticated the subject, the Assertion SHOULD contain a single representing that authentication event. o If the Assertion was issued with the intention that the presenter act autonomously on behalf of the subject, an SHOULD NOT be included. The presenter SHOULD be identified in the or similar element, the element, or by other available means like [OASIS.saml-deleg-cs]. @@ -424,20 +417,37 @@ 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-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 @@ -624,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] - Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 + Raggett, D., Jacobs, I., and A. Hors, "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