--- 1/draft-ietf-oauth-saml2-bearer-03.txt 2011-05-23 17:16:01.000000000 +0200 +++ 2/draft-ietf-oauth-saml2-bearer-04.txt 2011-05-23 17:16:01.000000000 +0200 @@ -1,19 +1,19 @@ B. Campbell, Ed. Internet-Draft Ping Identity Corp. Intended status: Standards Track C. Mortimore -Expires: August 8, 2011 Salesforce.com - February 4, 2011 +Expires: November 24, 2011 Salesforce.com + May 23, 2011 SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 - draft-ietf-oauth-saml2-bearer-03 + draft-ietf-oauth-saml2-bearer-04 Abstract This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -21,21 +21,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 August 8, 2011. + This Internet-Draft will expire on November 24, 2011. 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 @@ -52,24 +52,24 @@ 2. SAML Assertion Access Token Request . . . . . . . . . . . . . 4 2.1. Client Requests Access Token . . . . . . . . . . . . . . . 4 2.2. Assertion Format and Processing Requirements . . . . . . . 5 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Example (non-normative) . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1. Parameter Registration Request . . . . . . . . . . . . . . 9 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 12 5.2. Informative References . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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. @@ -130,53 +130,54 @@ | | | | +--------+ +---------------+ Figure 1: Assertion Access Token Request The request/response flow illustrated in Figure 1 includes the following steps: (A) The client sends an access token request to the authorization server that includes a SAML 2.0 Assertion and a grant_type of - "http://oauth.net/grant_type/assertion/saml/2.0/bearer". + "http://oauth.net/grant_type/saml/2.0/bearer". (B) The authorization server validates the Assertion per the processing rules defined in this specification and issues an access token. 2.1. Client Requests Access Token The client includes the Assertion in the access token request, the core details of which are defined in OAuth [I-D.ietf.oauth-v2], by - specifying "http://oauth.net/grant_type/assertion/saml/2.0/bearer" as - the absolute URI value of the "grant_type" parameter and by adding - the following parameter: + specifying "http://oauth.net/grant_type/saml/2.0/bearer" as the + absolute URI value of the "grant_type" parameter and by adding the + following parameter: assertion REQUIRED. The value of the assertion parameter MUST contain a single SAML 2.0 Assertion. When used with the - "http://oauth.net/grant_type/assertion/saml/2.0/bearer" grant - type, the assertion MUST be a SAML 2.0 Assertion. The SAML - Assertion XML data MUST be encoded using base64url, where the - encoding adheres to the definition in Section 5 of RFC4648 - [RFC4648] and where the padding bits are set to zero. To to - avoid the need for subsequent encoding steps (by "application/ + "http://oauth.net/grant_type/saml/2.0/bearer" grant type, the + assertion MUST be a SAML 2.0 Assertion. The SAML Assertion XML + data MUST be encoded using base64url, where the encoding + adheres to the definition in Section 5 of RFC4648 [RFC4648] and + where the padding bits are set to zero. To to avoid the need + for subsequent encoding steps (by "application/ x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the base64url encoded data SHOULD NOT be line wrapped and pad characters ("=") SHOULD NOT be included. scope - OPTIONAL. The scope of the access request is expressed as a - list of space-delimited strings. The value is defined by the - authorization server. If the value contains multiple space- - delimited strings, their order does not matter, and each string - adds an additional access range to the requested scope. + OPTIONAL. The scope of the access request expressed as a list + of space-delimited, case sensitive strings. The value is + defined by the authorization server. If the value contains + multiple space-delimited strings, their order does not matter, + and each string adds an additional access range to the + requested scope. Authorization servers SHOULD issue access tokens with a limited lifetime and require clients to refresh them by requesting a new access token using the same assertion, if it is still valid, or with a new assertion. The authorization server SHOULD NOT issue a refresh token. 2.2. Assertion Format and Processing Requirements Prior to issuing an access token response as described in @@ -326,22 +327,22 @@ Figure 2: Example SAML 2.0 Assertion To present the Assertion shown in the previous example as part of an access token request, for example, the client might make the following HTTPS request (line breaks are for display purposes only): POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded - grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F - saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ + grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fsaml%2F2.0%2F + bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM [...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Figure 3: Example Request 3. Security Considerations No additional considerations beyond those described within the OAuth 2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. @@ -366,20 +367,36 @@ 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 Cantor, and David Waite Appendix B. Document History [[ to be removed by RFC editor before publication as an RFC ]] + 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 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. draft-ietf-oauth-saml2-bearer-02 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 really inherited by this spec anymore) @@ -458,21 +475,21 @@ o Initial I-D 5. References 5.1. Normative References [I-D.ietf.oauth-v2] Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Protocol", - ID draft-ietf-oauth-v2-12 (work in progress), Dec 2010. + ID draft-ietf-oauth-v2-16 (work in progress), May 2011. [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.