--- 1/draft-ietf-oauth-saml2-bearer-20.txt 2014-07-23 12:14:33.901603882 -0700 +++ 2/draft-ietf-oauth-saml2-bearer-21.txt 2014-07-23 12:14:33.941604849 -0700 @@ -1,22 +1,22 @@ OAuth Working Group B. Campbell Internet-Draft Ping Identity Intended status: Standards Track C. Mortimore -Expires: October 30, 2014 Salesforce +Expires: January 24, 2015 Salesforce M. Jones Microsoft - April 28, 2014 + July 23, 2014 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants - draft-ietf-oauth-saml2-bearer-20 + draft-ietf-oauth-saml2-bearer-21 Abstract 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 as a means of client authentication. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -25,21 +25,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 October 30, 2014. + This Internet-Draft will expire on January 24, 2015. Copyright Notice Copyright (c) 2014 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 @@ -56,28 +56,29 @@ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 2.1. Using SAML Assertions as Authorization Grants . . . . . . 4 2.2. Using SAML Assertions for Client Authentication . . . . . 5 3. Assertion Format and Processing Requirements . . . . . . . . 6 3.1. Authorization Grant Processing . . . . . . . . . . . . . 8 3.2. Client Authentication Processing . . . . . . . . . . . . 9 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 9 5. Interoperability Considerations . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7.1. Sub-Namespace Registration of urn:ietf:params:oauth + 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Sub-Namespace Registration of urn:ietf:params:oauth :grant-type:saml2-bearer . . . . . . . . . . . . . . . . 12 - 7.2. Sub-Namespace Registration of urn:ietf:params:oauth + 8.2. Sub-Namespace Registration of urn:ietf:params:oauth :client-assertion-type:saml2-bearer . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 @@ -401,22 +402,22 @@ The example shows an assertion issued and signed by the SAML Identity Provider identified as "https://saml-idp.example.com". The subject of the assertion is identified by email address as "brian@example.com", who authenticated to the Identity Provider by means of a digital signature where the key was validated as part of an X.509 Public Key Infrastructure. The intended audience of the assertion is "https://saml-sp.example.net", which is an identifier for a SAML Service Provider with which the authorization server identifies itself. The assertion is sent as part of an access token - request to the authorization server's token endpoint at "https:// - authz.example.net/token.oauth2". + request to the authorization server's token endpoint at + "https://authz.example.net/token.oauth2". Below is an example SAML 2.0 Assertion (whitespace formatting is for display purposes only): https://saml-idp.example.com @@ -490,164 +491,189 @@ [RFC6749], and the Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os] specifications are all applicable to this document. The specification does not mandate replay protection for the SAML assertion usage for either the authorization grant or for client authentication. It is an optional feature, which implementations may employ at their own discretion. -7. IANA Considerations +7. Privacy Considerations -7.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- + A SAML Assertion may contain privacy-sensitive information and, to + prevent disclosure of such information to unintended parties, should + only be transmitted over encrypted channels, such as TLS. In cases + where it is desirable to prevent disclosure of certain information + the client, the Subject and/or individual attributes of a SAML + Assertion should be encrypted to the authorization server. + + Deployments should determine the minimum amount of information + necessary to complete the exchange and include only that information + in an Assertion (typically by limiting what information is included + in an or omitting it altogether). In some + cases, the Subject can be a value representing an anonymous or + pseudonymous user, as described in Section 6.3.1 of the Assertion + Framework for OAuth 2.0 Client Authentication and Authorization + Grants [I-D.ietf-oauth-assertions]. + +8. IANA Considerations + +8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- type:saml2-bearer This is a request to IANA to please register the value "grant- type:saml2-bearer" in the registry urn:ietf:params:oauth established in An IETF URN Sub-Namespace for OAuth [RFC6755]. o URN: urn:ietf:params:oauth:grant-type:saml2-bearer o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 o Change controller: IETF o Specification Document: [[this document]] -7.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- +8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- assertion-type:saml2-bearer This is a request to IANA to please register the value "client- assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth established in An IETF URN Sub-Namespace for OAuth [RFC6755]. o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 Client Authentication o Change controller: IETF o Specification Document: [[this document]] -8. References +9. References -8.1. Normative References +9.1. Normative References [I-D.ietf-oauth-assertions] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", draft-ietf-oauth-assertions - (work in progress), April 2014. + (work in progress), July 2014. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion - Markup Language (SAML) V2.0", OASIS Standard saml- - core-2.0-os, March 2005. + Markup Language (SAML) V2.0", OASIS Standard saml-core- + 2.0-os, March 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, October 2012. -8.2. Informative References +9.2. Informative References [OASIS.saml-deleg-cs] Cantor, S., Ed., "SAML V2.0 Condition for Delegation Restriction", Nov 2009. [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 2005. [OASIS.saml-profiles-2.0-os] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., and E. Maler, "Profiles for the OASIS 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. + Language (SAML) V2.0", OASIS Standard saml-sec-consider- + 2.0-os, March 2005. [W3C.REC-html401-19991224] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, . Appendix A. Acknowledgements The following people contributed wording and concepts to this document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar. Appendix B. Document History [[ to be removed by RFC editor before publication as an RFC ]] + draft-ietf-oauth-saml2-bearer-21 + + o Added Privacy Considerations section per AD review discussion + http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html + and http://www.ietf.org/mail-archive/web/oauth/current/ + msg13144.html + draft-ietf-oauth-saml2-bearer-20 o Clarified some text around the treatment of subject based on the - rough rough consensus from the thread staring at http:// - www.ietf.org/mail-archive/web/oauth/current/msg12630.html + rough rough consensus from the thread staring at + http://www.ietf.org/mail-archive/web/oauth/current/msg12630.html draft-ietf-oauth-saml2-bearer-19 o Updated references. draft-ietf-oauth-saml2-bearer-18 - o Clean up language around subject per http://www.ietf.org/mail- archive/web/oauth/current/msg12254.html. - o As suggested in http://www.ietf.org/mail-archive/web/oauth/current - /msg12253.html stated that "In the absence of an application - profile specifying otherwise, compliant applications MUST compare - the audience/issuer values using the Simple String Comparison - method defined in Section 6.2.1 of RFC 3986." + o As suggested in http://www.ietf.org/mail- + archive/web/oauth/current/msg12253.html stated that "In the + absence of an application profile specifying otherwise, compliant + applications MUST compare the audience/issuer values using the + Simple String Comparison method defined in Section 6.2.1 of RFC + 3986." o Clarify the potentially confusing language about the AS confirming the assertion http://www.ietf.org/mail-archive/web/oauth/current/ msg12255.html. o Combine the two items about AuthnStatement and drop the word - presenter as discussed in http://www.ietf.org/mail-archive/web/ - oauth/current/msg12257.html. + presenter as discussed in http://www.ietf.org/mail- + archive/web/oauth/current/msg12257.html. o Added one-time use, maximum lifetime, and specific subject and attribute requirements to Interoperability Considerations based on http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. o Reword security considerations and mention that replay protection - is not mandated based on http://www.ietf.org/mail-archive/web/ - oauth/current/msg12259.html. + is not mandated based on http://www.ietf.org/mail- + archive/web/oauth/current/msg12259.html. draft-ietf-oauth-saml2-bearer-17 o Stated that issuer and audience values SHOULD be compared using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 unless otherwise specified by the application. draft-ietf-oauth-saml2-bearer-16 o Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth @@ -674,22 +700,22 @@ to SAML Metadata. o Added more explanatory context to the example in Section 4. draft-ietf-oauth-saml2-bearer-15 o Reference RFC 6749 and RFC 6755. o Update draft-ietf-oauth-assertions reference to -06. - o Remove extraneous word per http://www.ietf.org/mail-archive/web/ - oauth/current/msg10055.html + o Remove extraneous word per http://www.ietf.org/mail- + archive/web/oauth/current/msg10055.html draft-ietf-oauth-saml2-bearer-14 o Add more text to intro explaining that an assertion grant type can be used with or without client authentication/identification and that client assertion authentication is nothing more than an alternative way for a client to authenticate to the token endpoint o Add examples to Sections 2.1 and 2.2 @@ -715,26 +740,27 @@ o updated reference to draft-ietf-oauth-v2 from -25 to -26 and draft-ietf-oauth-assertions from -02 to -03 draft-ietf-oauth-saml2-bearer-11 o Removed text about limited lifetime access tokens and the SHOULD NOT on issuing refresh tokens. The text was moved to draft-ietf- oauth-assertions-02 and somewhat modified per http://www.ietf.org/ mail-archive/web/oauth/current/msg08298.html. - o Fixed typo/missing word per http://www.ietf.org/mail-archive/web/ - oauth/current/msg08733.html. + o Fixed typo/missing word per http://www.ietf.org/mail- + archive/web/oauth/current/msg08733.html. o Added Terminology section. 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 @@ -763,55 +788,55 @@ o Fix three typos NamseID->NameID and (2x) Namspace->Namespace draft-ietf-oauth-saml2-bearer-05 o Allow for subject confirmation data to be optional when Conditions contain audience and NotOnOrAfter o Rework most of the spec to profile draft-ietf-oauth-assertions for both authn and authz including (but not limited to): - * remove requirement for issuer to be urn:oasis:names:tc:SAML:2.0 - :nameid-format:entity + * remove requirement for issuer to be + urn:oasis:names:tc:SAML:2.0:nameid-format:entity * change wording on Subject requirements o using a MAY, explicitly say that the Audience can be token endpoint URL of the authorization server o Change title to be more generic (allowing for client authn too) o added client authentication to the abstract o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for grant type rather than http://oauth.net/grant_type/saml/2.0/bearer o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer - o remove scope parameter as it is defined in http://tools.ietf.org/ - html/draft-ietf-oauth-assertions + o remove scope parameter as it is defined in + http://tools.ietf.org/html/draft-ietf-oauth-assertions o remove assertion param registration because it [should] be in http://tools.ietf.org/html/draft-ietf-oauth-assertions o fix typo(s) and update/add references draft-ietf-oauth-saml2-bearer-04 - o Changed the grant_type URI from "http://oauth.net/grant_type/ - assertion/saml/2.0/bearer" to "http://oauth.net/grant_type/saml/ - 2.0/bearer" - dropping the word assertion from the path. Recent - versions of draft-ietf-oauth-v2 no longer refer to extension - grants using the word assertion so 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 is "http://oauth.net/ - grant_type/jwt/1.0/bearer". + o Changed the grant_type URI from + "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to + "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word + assertion from the path. Recent versions of draft-ietf-oauth-v2 + no longer refer to extension grants using the word assertion so + 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 + is "http://oauth.net/grant_type/jwt/1.0/bearer". o Added "case sensitive" to scope definition to align with draft- ietf-oauth-v2-15/16. o Updated to reference draft-ietf-oauth-v2-16 draft-ietf-oauth-saml2-bearer-03 o Cleanup of some editorial issues. @@ -850,22 +875,20 @@ o Added Parameter Registration Request for "assertion" to IANA Considerations. o Changed document name to draft-ietf-oauth-saml2-bearer in anticipation of becoming an OAUTH WG item. o Attempt to move the entire definition of the 'assertion' parameter into this draft (it will no longer be defined in OAuth 2 Protocol Framework). - draft-campbell-oauth-saml-01 - o Updated to reference draft-ietf-oauth-v2-11 and reflect changes from -10 to -11. o Updated examples. o Relaxed processing rules to allow for more than one SubjectConfirmation element. o Removed the 'MUST NOT contain a NotBefore attribute' on SubjectConfirmationData. @@ -876,23 +899,23 @@ o Added some wording about identifying the client when the subject hasn't directly authenticated including an informative reference to SAML V2.0 Condition for Delegation Restriction. o Added a few examples to the language about verifying that the Assertion is valid in all other respects. o Added some wording to the introduction about the similarities to Web SSO in the format and processing rules - o Changed the grant_type (was assertion_type) URI from http:// - oauth.net/assertion_type/saml/2.0/bearer to http://oauth.net/ - grant_type/assertion/saml/2.0/bearer + o Changed the grant_type (was assertion_type) URI from + http://oauth.net/assertion_type/saml/2.0/bearer to + http://oauth.net/grant_type/assertion/saml/2.0/bearer o Changed title to include "Grant Type" in it. o Editorial updates based on feedback from the WG and others (including capitalization of Assertion when referring to SAML). draft-campbell-oauth-saml-00 o Initial I-D