idnits 2.17.1 draft-ietf-oauth-saml2-bearer-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2014) is 3452 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6931 (Obsoleted by RFC 9231) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group B. Campbell 3 Internet-Draft Ping Identity 4 Intended status: Standards Track C. Mortimore 5 Expires: May 16, 2015 Salesforce 6 M. Jones 7 Microsoft 8 November 12, 2014 10 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization 11 Grants 12 draft-ietf-oauth-saml2-bearer-23 14 Abstract 16 This specification defines the use of a Security Assertion Markup 17 Language (SAML) 2.0 Bearer Assertion as a means for requesting an 18 OAuth 2.0 access token as well as for use as a means of client 19 authentication. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 16, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 59 2.1. Using SAML Assertions as Authorization Grants . . . . . . 4 60 2.2. Using SAML Assertions for Client Authentication . . . . . 5 61 3. Assertion Format and Processing Requirements . . . . . . . . 6 62 3.1. Authorization Grant Processing . . . . . . . . . . . . . 8 63 3.2. Client Authentication Processing . . . . . . . . . . . . 9 64 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 9 65 5. Interoperability Considerations . . . . . . . . . . . . . . . 11 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Sub-Namespace Registration of urn:ietf:params:oauth 70 :grant-type:saml2-bearer . . . . . . . . . . . . . . . . 12 71 8.2. Sub-Namespace Registration of urn:ietf:params:oauth 72 :client-assertion-type:saml2-bearer . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 77 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 80 1. Introduction 82 The Security Assertion Markup Language (SAML) 2.0 83 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 84 identity and security information to be shared across security 85 domains. The SAML specification, while primarily targeted at 86 providing cross domain Web browser single sign-on, was also designed 87 to be modular and extensible to facilitate use in other contexts. 89 The Assertion, an XML security token, is a fundamental construct of 90 SAML that is often adopted for use in other protocols and 91 specifications. (Some examples include [OASIS.WSS-SAMLTokenProfile] 92 and [OASIS.WS-Fed].) An Assertion is generally issued by an identity 93 provider and consumed by a service provider who relies on its content 94 to identify the Assertion's subject for security related purposes. 96 The OAuth 2.0 Authorization Framework [RFC6749] provides a method for 97 making authenticated HTTP requests to a resource using an access 98 token. Access tokens are issued to third-party clients by an 99 authorization server (AS) with the (sometimes implicit) approval of 100 the resource owner. In OAuth, an authorization grant is an abstract 101 term used to describe intermediate credentials that represent the 102 resource owner authorization. An authorization grant is used by the 103 client to obtain an access token. Several authorization grant types 104 are defined to support a wide range of client types and user 105 experiences. OAuth also allows for the definition of new extension 106 grant types to support additional clients or to provide a bridge 107 between OAuth and other trust frameworks. Finally, OAuth allows the 108 definition of additional authentication mechanisms to be used by 109 clients when interacting with the authorization server. 111 The Assertion Framework for OAuth 2.0 Client Authentication and 112 Authorization Grants [I-D.ietf-oauth-assertions] specification is an 113 abstract extension to OAuth 2.0 that provides a general framework for 114 the use of Assertions as client credentials and/or authorization 115 grants with OAuth 2.0. This specification profiles the Assertion 116 Framework for OAuth 2.0 Client Authentication and Authorization 117 Grants [I-D.ietf-oauth-assertions] specification to define an 118 extension grant type that uses a SAML 2.0 Bearer Assertion to request 119 an OAuth 2.0 access token as well as for use as client credentials. 120 The format and processing rules for the SAML Assertion defined in 121 this specification are intentionally similar, though not identical, 122 to those in the Web Browser SSO Profile defined in the SAML Profiles 123 [OASIS.saml-profiles-2.0-os] specification. This specification is 124 reusing, to the extent reasonable, concepts and patterns from that 125 well-established Profile. 127 This document defines how a SAML Assertion can be used to request an 128 access token when a client wishes to utilize an existing trust 129 relationship, expressed through the semantics of (and digital 130 signature or keyed message digest calculated over) the SAML 131 Assertion, without a direct user approval step at the authorization 132 server. It also defines how a SAML Assertion can be used as a client 133 authentication mechanism. The use of an Assertion for client 134 authentication is orthogonal to and separable from using an Assertion 135 as an authorization grant. They can be used either in combination or 136 separately. Client assertion authentication is nothing more than an 137 alternative way for a client to authenticate to the token endpoint 138 and must be used in conjunction with some grant type to form a 139 complete and meaningful protocol request. Assertion authorization 140 grants may be used with or without client authentication or 141 identification. Whether or not client authentication is needed in 142 conjunction with an assertion authorization grant, as well as the 143 supported types of client authentication, are policy decisions at the 144 discretion of the authorization server. 146 The process by which the client obtains the SAML Assertion, prior to 147 exchanging it with the authorization server or using it for client 148 authentication, is out of scope. 150 1.1. Notational Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 Unless otherwise noted, all the protocol parameter names and values 157 are case sensitive. 159 1.2. Terminology 161 All terms are as defined in The OAuth 2.0 Authorization Framework 162 [RFC6749], the Assertion Framework for OAuth 2.0 Client 163 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 164 and the Security Assertion Markup Language (SAML) 2.0 165 [OASIS.saml-core-2.0-os] specifications. 167 2. HTTP Parameter Bindings for Transporting Assertions 169 The Assertion Framework for OAuth 2.0 Client Authentication and 170 Authorization Grants [I-D.ietf-oauth-assertions] specification 171 defines generic HTTP parameters for transporting Assertions during 172 interactions with a token endpoint. This section defines specific 173 parameters and treatments of those parameters for use with SAML 2.0 174 Bearer Assertions. 176 2.1. Using SAML Assertions as Authorization Grants 178 To use a SAML Bearer Assertion as an authorization grant, the client 179 uses an access token request as defined in Section 4 of the Assertion 180 Framework for OAuth 2.0 Client Authentication and Authorization 181 Grants [I-D.ietf-oauth-assertions] specification with the following 182 specific parameter values and encodings. 184 The value of the "grant_type" parameter is 185 "urn:ietf:params:oauth:grant-type:saml2-bearer". 187 The value of the "assertion" parameter contains a single SAML 2.0 188 Assertion. It MUST NOT contain more than one SAML 2.0 assertion. 189 The SAML Assertion XML data MUST be encoded using base64url, where 190 the encoding adheres to the definition in Section 5 of RFC 4648 192 [RFC4648] and where the padding bits are set to zero. To avoid the 193 need for subsequent encoding steps (by "application/x-www-form- 194 urlencoded" [W3C.REC-html401-19991224], for example), the base64url 195 encoded data MUST NOT be line wrapped and pad characters ("=") MUST 196 NOT be included. 198 The "scope" parameter may be used, as defined in the Assertion 199 Framework for OAuth 2.0 Client Authentication and Authorization 200 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 201 requested scope. 203 Authentication of the client is optional, as described in 204 Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the 205 "client_id" is only needed when a form of client authentication that 206 relies on the parameter is used. 208 The following example demonstrates an Access Token Request with an 209 assertion as an authorization grant (with extra line breaks for 210 display purposes only): 212 POST /token.oauth2 HTTP/1.1 213 Host: as.example.com 214 Content-Type: application/x-www-form-urlencoded 216 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 217 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 219 2.2. Using SAML Assertions for Client Authentication 221 To use a SAML Bearer Assertion for client authentication, the client 222 uses the following parameter values and encodings. 224 The value of the "client_assertion_type" parameter is 225 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer". 227 The value of the "client_assertion" parameter MUST contain a single 228 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 229 using base64url, where the encoding adheres to the definition in 230 Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to 231 zero. To avoid the need for subsequent encoding steps (by 232 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 233 example), the base64url encoded data SHOULD NOT be line wrapped and 234 pad characters ("=") SHOULD NOT be included. 236 The following example demonstrates a client authenticating using an 237 assertion during the presentation of an authorization code grant in 238 an Access Token Request (with extra line breaks for display purposes 239 only): 241 POST /token.oauth2 HTTP/1.1 242 Host: as.example.com 243 Content-Type: application/x-www-form-urlencoded 245 grant_type=authorization_code& 246 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 247 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 248 %3Aclient-assertion-type%3Asaml2-bearer& 249 client_assertion=PHNhbW...[omitted for brevity]...ZT 251 3. Assertion Format and Processing Requirements 253 In order to issue an access token response as described in OAuth 2.0 254 [RFC6749] or to rely on an Assertion for client authentication, the 255 authorization server MUST validate the Assertion according to the 256 criteria below. Application of additional restrictions and policy 257 are at the discretion of the authorization server. 259 1. The Assertion's element MUST contain a unique 260 identifier for the entity that issued the Assertion. In the 261 absence of an application profile specifying otherwise, 262 compliant applications MUST compare Issuer values using the 263 Simple String Comparison method defined in Section 6.2.1 of RFC 264 3986 [RFC3986]. 266 2. The Assertion MUST contain a element with an 267 element with an element that 268 identifies the authorization server as an intended audience. 269 Section 2.5.1.4 of Assertions and Protocols for the OASIS 270 Security Assertion Markup Language [OASIS.saml-core-2.0-os] 271 defines the and elements and, 272 in addition to the URI references discussed there, the token 273 endpoint URL of the authorization server MAY be used as a URI 274 that identifies the authorization server as an intended 275 audience. The Authorization Server MUST reject any assertion 276 that does not contain its own identity as the intended audience. 277 In the absence of an application profile specifying otherwise, 278 compliant applications MUST compare the audience values using 279 the Simple String Comparison method defined in Section 6.2.1 of 280 RFC 3986 [RFC3986]. As noted in Section 5, the precise strings 281 to be used as the audience for a given Authorization Server must 282 be configured out-of-band by the Authorization Server and the 283 Issuer of the assertion. 285 3. The Assertion MUST contain a element identifying the 286 principal that is the subject of the Assertion. Additional 287 information identifying the subject/principal MAY be included in 288 an . 290 A. For the authorization grant, the Subject typically 291 identifies an authorized accessor for which the access token 292 is being requested (i.e., the resource owner or an 293 authorized delegate), but in some cases, may be a 294 pseudonymous identifier or other value denoting an anonymous 295 user. 297 B. For client authentication, the Subject MUST be the 298 "client_id" of the OAuth client. 300 4. The Assertion MUST have an expiry that limits the time window 301 during which it can be used. The expiry can be expressed either 302 as the NotOnOrAfter attribute of the element or as 303 the NotOnOrAfter attribute of a suitable 304 element. 306 5. The element MUST contain at least one 307 element that has a Method attribute with a 308 value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". If the 309 Assertion does not have a suitable NonOnOrAfter attribute on the 310 element, the element MUST 311 contain a element. When present, the 312 element MUST have a Recipient 313 attribute with a value indicating the token endpoint URL of the 314 authorization server (or an acceptable alias). The 315 authorization server MUST verify that the value of the Recipient 316 attribute matches the token endpoint URL (or an acceptable 317 alias) to which the Assertion was delivered. The 318 element MUST have a NotOnOrAfter 319 attribute that limits the window during which the Assertion can 320 be confirmed. The element MAY also 321 contain an Address attribute limiting the client address from 322 which the Assertion can be delivered. Verification of the 323 Address is at the discretion of the authorization server. 325 6. The authorization server MUST reject the entire Assertion if the 326 NotOnOrAfter instant on the element has passed 327 (subject to allowable clock skew between systems). The 328 authorization server MUST reject the (but 329 MAY still use the rest of the Assertion) if the NotOnOrAfter 330 instant on the has passed (subject to 331 allowable clock skew). Note that the authorization server may 332 reject Assertions with a NotOnOrAfter instant that is 333 unreasonably far in the future. The authorization server MAY 334 ensure that Bearer Assertions are not replayed, by maintaining 335 the set of used ID values for the length of time for which the 336 Assertion would be considered valid based on the applicable 337 NotOnOrAfter instant. 339 7. If the Assertion issuer directly authenticated the subject, the 340 Assertion SHOULD contain a single representing 341 that authentication event. If the Assertion was issued with the 342 intention that the client act autonomously on behalf of the 343 subject, an SHOULD NOT be included and the 344 client presenting the assertion SHOULD be identified in the 345 or similar element in the 346 element, or by other available means like SAML V2.0 Condition 347 for Delegation Restriction [OASIS.saml-deleg-cs]. 349 8. Other statements, in particular elements, 350 MAY be included in the Assertion. 352 9. The Assertion MUST be digitally signed or have a Message 353 Authentication Code applied by the issuer. The authorization 354 server MUST reject assertions with an invalid signature or 355 Message Authentication Code. 357 10. Encrypted elements MAY appear in place of their plain text 358 counterparts as defined in [OASIS.saml-core-2.0-os]. 360 11. The authorization server MUST reject an Assertion that is not 361 valid in all other respects per [OASIS.saml-core-2.0-os], such 362 as (but not limited to) all content within the Conditions 363 element including the NotOnOrAfter and NotBefore attributes, 364 unknown condition types, etc. 366 3.1. Authorization Grant Processing 368 Assertion authorization grants may be used with or without client 369 authentication or identification. Whether or not client 370 authentication is needed in conjunction with an assertion 371 authorization grant, as well as the supported types of client 372 authentication, are policy decisions at the discretion of the 373 authorization server. However, if client credentials are present in 374 the request, the authorization server MUST validate them. 376 If the Assertion is not valid (including if its subject confirmation 377 requirements cannot be met), the authorization server constructs an 378 error response as defined in OAuth 2.0 [RFC6749]. The value of the 379 "error" parameter MUST be the "invalid_grant" error code. The 380 authorization server MAY include additional information regarding the 381 reasons the Assertion was considered invalid using the 382 "error_description" or "error_uri" parameters. 384 For example: 386 HTTP/1.1 400 Bad Request 387 Content-Type: application/json 388 Cache-Control: no-store 390 { 391 "error":"invalid_grant", 392 "error_description":"Audience validation failed" 393 } 395 3.2. Client Authentication Processing 397 If the client Assertion is not valid (including if its subject 398 confirmation requirements cannot be met), the authorization server 399 constructs an error response as defined in OAuth 2.0 [RFC6749]. The 400 value of the "error" parameter MUST be the "invalid_client" error 401 code. The authorization server MAY include additional information 402 regarding the reasons the Assertion was considered invalid using the 403 "error_description" or "error_uri" parameters. 405 4. Authorization Grant Example 407 The following examples illustrate what a conforming Assertion and an 408 access token request would look like. 410 The example shows an assertion issued and signed by the SAML Identity 411 Provider identified as "https://saml-idp.example.com". The subject 412 of the assertion is identified by email address as 413 "brian@example.com", who authenticated to the Identity Provider by 414 means of a digital signature where the key was validated as part of 415 an X.509 Public Key Infrastructure. The intended audience of the 416 assertion is "https://saml-sp.example.net", which is an identifier 417 for a SAML Service Provider with which the authorization server 418 identifies itself. The assertion is sent as part of an access token 419 request to the authorization server's token endpoint at 420 "https://authz.example.net/token.oauth2". 422 Below is an example SAML 2.0 Assertion (whitespace formatting is for 423 display purposes only): 425 429 https://saml-idp.example.com 430 431 [...omitted for brevity...] 432 433 434 436 brian@example.com 437 438 440 443 444 445 446 447 https://saml-sp.example.net 448 449 450 451 452 453 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 454 455 456 457 459 Figure 1: Example SAML 2.0 Assertion 461 To present the Assertion shown in the previous example as part of an 462 access token request, for example, the client might make the 463 following HTTPS request (with extra line breaks for display purposes 464 only): 466 POST /token.oauth2 HTTP/1.1 467 Host: authz.example.net 468 Content-Type: application/x-www-form-urlencoded 470 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 471 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 472 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 474 Figure 2: Example Request 476 5. Interoperability Considerations 478 Agreement between system entities regarding identifiers, keys, and 479 endpoints is required in order to achieve interoperable deployments 480 of this profile. Specific items that require agreement are as 481 follows: values for the issuer and audience identifiers, the location 482 of the token endpoint, the key used to apply and verify the digital 483 signature over the assertion, one-time use restrictions on 484 assertions, maximum assertion lifetime allowed, and the specific 485 subject and attribute requirements of the assertion. The exchange of 486 such information is explicitly out of scope for this specification 487 and typical deployment of it will be done alongside existing SAML Web 488 SSO deployments that have already established a means of exchanging 489 such information. Metadata for the OASIS Security Assertion Markup 490 Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common 491 method of exchanging SAML related information about system entities. 493 The RSA-SHA256 algorithm, from [RFC6931], is a mandatory to implement 494 XML signature algorithm for this profile. 496 6. Security Considerations 498 The security considerations described within the Assertion Framework 499 for OAuth 2.0 Client Authentication and Authorization Grants 500 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 501 [RFC6749], and the Security and Privacy Considerations for the OASIS 502 Security Assertion Markup Language (SAML) V2.0 503 [OASIS.saml-sec-consider-2.0-os] specifications are all applicable to 504 this document. 506 The specification does not mandate replay protection for the SAML 507 assertion usage for either the authorization grant or for client 508 authentication. It is an optional feature, which implementations may 509 employ at their own discretion. 511 7. Privacy Considerations 513 A SAML Assertion may contain privacy-sensitive information and, to 514 prevent disclosure of such information to unintended parties, should 515 only be transmitted over encrypted channels, such as TLS. In cases 516 where it is desirable to prevent disclosure of certain information to 517 the client, the Subject and/or individual attributes of a SAML 518 Assertion should be encrypted to the authorization server. 520 Deployments should determine the minimum amount of information 521 necessary to complete the exchange and include only that information 522 in an Assertion (typically by limiting what information is included 523 in an or omitting it altogether). In some 524 cases, the Subject can be a value representing an anonymous or 525 pseudonymous user, as described in Section 6.3.1 of the Assertion 526 Framework for OAuth 2.0 Client Authentication and Authorization 527 Grants [I-D.ietf-oauth-assertions]. 529 8. IANA Considerations 531 8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- 532 type:saml2-bearer 534 This is a request to IANA to please register the value "grant- 535 type:saml2-bearer" in the registry urn:ietf:params:oauth established 536 in An IETF URN Sub-Namespace for OAuth [RFC6755]. 538 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 540 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 541 OAuth 2.0 543 o Change controller: IESG 545 o Specification Document: [[this document]] 547 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 548 assertion-type:saml2-bearer 550 This is a request to IANA to please register the value "client- 551 assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth 552 established in An IETF URN Sub-Namespace for OAuth [RFC6755]. 554 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 555 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 556 Client Authentication 558 o Change controller: IESG 560 o Specification Document: [[this document]] 562 9. References 564 9.1. Normative References 566 [I-D.ietf-oauth-assertions] 567 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 568 "Assertion Framework for OAuth 2.0 Client Authentication 569 and Authorization Grants", draft-ietf-oauth-assertions 570 (work in progress), October 2014. 572 [OASIS.saml-core-2.0-os] 573 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 574 "Assertions and Protocol for the OASIS Security Assertion 575 Markup Language (SAML) V2.0", OASIS Standard saml-core- 576 2.0-os, March 2005, . 579 [OASIS.saml-deleg-cs] 580 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 581 Restriction", Nov 2009. 583 [OASIS.saml-sec-consider-2.0-os] 584 Hirsch, F., Philpott, R., and E. Maler, "Security and 585 Privacy Considerations for the OASIS Security Markup 586 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 587 2.0-os, March 2005, . 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 594 Resource Identifier (URI): Generic Syntax", STD 66, RFC 595 3986, January 2005. 597 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 598 Encodings", RFC 4648, October 2006. 600 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 601 6749, October 2012. 603 [RFC6931] Eastlake, D., "Additional XML Security Uniform Resource 604 Identifiers (URIs)", RFC 6931, April 2013. 606 9.2. Informative References 608 [OASIS.WS-Fed] 609 Goodner, M. and T. Nadalin, "Web Services Federation 610 Language (WS-Federation) Version 1.2", May 2009, 611 . 614 [OASIS.WSS-SAMLTokenProfile] 615 Monzillo, R., Kaler, C., Nadalin, T., Hallam-Baker, P., 616 and C. Milono, "Web Services Security SAML Token Profile 617 Version 1.1.1", May 2012, . 620 [OASIS.saml-metadata-2.0-os] 621 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 622 "Metadata for the Security Assertion Markup Language 623 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 624 2005, . 627 [OASIS.saml-profiles-2.0-os] 628 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 629 P., Philpott, R., and E. Maler, "Profiles for the OASIS 630 Security Assertion Markup Language (SAML) V2.0", OASIS 631 Standard OASIS.saml-profiles-2.0-os, March 2005, 632 . 635 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 636 for OAuth", RFC 6755, October 2012. 638 [W3C.REC-html401-19991224] 639 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 640 Specification", World Wide Web Consortium Recommendation 641 REC-html401-19991224, December 1999, 642 . 644 Appendix A. Acknowledgements 646 The following people contributed wording and concepts to this 647 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 648 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 649 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes 650 Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar. 652 Appendix B. Document History 654 [[ to be removed by RFC editor before publication as an RFC ]] 656 draft-ietf-oauth-saml2-bearer-23 658 o Fix typo per http://www.ietf.org/mail-archive/web/oauth/current/ 659 msg13790.html 661 draft-ietf-oauth-saml2-bearer-22 663 o Changes/suggestions from IESG reviews. 665 draft-ietf-oauth-saml2-bearer-21 667 o Added Privacy Considerations section per AD review discussion 668 http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html 669 and http://www.ietf.org/mail-archive/web/oauth/current/ 670 msg13144.html 672 draft-ietf-oauth-saml2-bearer-20 674 o Clarified some text around the treatment of subject based on the 675 rough rough consensus from the thread staring at 676 http://www.ietf.org/mail-archive/web/oauth/current/msg12630.html 678 draft-ietf-oauth-saml2-bearer-19 680 o Updated references. 682 draft-ietf-oauth-saml2-bearer-18 684 o Clean up language around subject per http://www.ietf.org/mail- 685 archive/web/oauth/current/msg12254.html. 687 o As suggested in http://www.ietf.org/mail- 688 archive/web/oauth/current/msg12253.html stated that "In the 689 absence of an application profile specifying otherwise, compliant 690 applications MUST compare the audience/issuer values using the 691 Simple String Comparison method defined in Section 6.2.1 of RFC 692 3986." 694 o Clarify the potentially confusing language about the AS confirming 695 the assertion http://www.ietf.org/mail-archive/web/oauth/current/ 696 msg12255.html. 698 o Combine the two items about AuthnStatement and drop the word 699 presenter as discussed in http://www.ietf.org/mail- 700 archive/web/oauth/current/msg12257.html. 702 o Added one-time use, maximum lifetime, and specific subject and 703 attribute requirements to Interoperability Considerations based on 704 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 706 o Reword security considerations and mention that replay protection 707 is not mandated based on http://www.ietf.org/mail- 708 archive/web/oauth/current/msg12259.html. 710 draft-ietf-oauth-saml2-bearer-17 712 o Stated that issuer and audience values SHOULD be compared using 713 the Simple String Comparison method defined in Section 6.2.1 of 714 RFC 3986 unless otherwise specified by the application. 716 draft-ietf-oauth-saml2-bearer-16 718 o Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth 719 2.0" to "SAML 2.0 Profile for OAuth 2.0 Client Authentication and 720 Authorization Grants" to be more explicit about the scope of the 721 document per http://www.ietf.org/mail-archive/web/oauth/current/ 722 msg11063.html. 724 o Fixed typo in text identifying the presenter from "or similar 725 element, the" to "or similar element in the". 727 o Numbered the list of processing rules. 729 o Smallish editorial cleanups to try and improve readability and 730 comprehensibility. 732 o Cleaner split out of the processing rules in cases where they 733 differ for client authentication and authorization grants. 735 o Clarified the parameters that are used/available for authorization 736 grants. 738 o Added Interoperability Considerations section and info reference 739 to SAML Metadata. 741 o Added more explanatory context to the example in Section 4. 743 draft-ietf-oauth-saml2-bearer-15 745 o Reference RFC 6749 and RFC 6755. 747 o Update draft-ietf-oauth-assertions reference to -06. 749 o Remove extraneous word per http://www.ietf.org/mail- 750 archive/web/oauth/current/msg10055.html 752 draft-ietf-oauth-saml2-bearer-14 754 o Add more text to intro explaining that an assertion grant type can 755 be used with or without client authentication/identification and 756 that client assertion authentication is nothing more than an 757 alternative way for a client to authenticate to the token endpoint 759 o Add examples to Sections 2.1 and 2.2 761 o Update references 763 draft-ietf-oauth-saml2-bearer-13 765 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 766 -28 768 o Changed "Description" to "Specification Document" in both 769 registration requests in IANA Considerations per changes to the 770 template in ietf-oauth-urn-sub-ns(-03) 772 o Added "(or an acceptable alias)" so that it's in both sentences 773 about Recipient and the token endpoint URL so there's no ambiguity 775 o Update area and workgroup (now Security and OAuth was Internet and 776 nothing) 778 draft-ietf-oauth-saml2-bearer-12 780 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 781 draft-ietf-oauth-assertions from -02 to -03 783 draft-ietf-oauth-saml2-bearer-11 785 o Removed text about limited lifetime access tokens and the SHOULD 786 NOT on issuing refresh tokens. The text was moved to draft-ietf- 787 oauth-assertions-02 and somewhat modified per http://www.ietf.org/ 788 mail-archive/web/oauth/current/msg08298.html. 790 o Fixed typo/missing word per http://www.ietf.org/mail- 791 archive/web/oauth/current/msg08733.html. 793 o Added Terminology section. 795 o fix a spelling mistake 797 draft-ietf-oauth-saml2-bearer-09 799 o Attempt to address an ambiguity around validation requirements 800 when the Conditions element contain a NotOnOrAfter and 801 SubjectConfirmation/SubjectConfirmationData does too. Basically 802 it needs to have at least one bearer SubjectConfirmation element 803 but that element can omit SubjectConfirmationData, if Conditions 804 has an expiry on it. Otherwise, a valid SubjectConfirmation must 805 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 806 And any SubjectConfirmationData that has those elements needs to 807 have them checked. 809 o clarified that AudienceRestriction is under Conditions (even 810 though it's implied by schema) 812 o fix a typo 814 draft-ietf-oauth-saml2-bearer-08 816 o fix some typos 818 draft-ietf-oauth-saml2-bearer-07 820 o update reference from draft-campbell-oauth-urn-sub-ns to draft- 821 ietf-oauth-urn-sub-ns 823 o Updated to reference draft-ietf-oauth-v2-20 825 draft-ietf-oauth-saml2-bearer-06 827 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 829 draft-ietf-oauth-saml2-bearer-05 831 o Allow for subject confirmation data to be optional when Conditions 832 contain audience and NotOnOrAfter 834 o Rework most of the spec to profile draft-ietf-oauth-assertions for 835 both authn and authz including (but not limited to): 837 * remove requirement for issuer to be 838 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 840 * change wording on Subject requirements 842 o using a MAY, explicitly say that the Audience can be token 843 endpoint URL of the authorization server 845 o Change title to be more generic (allowing for client authn too) 847 o added client authentication to the abstract 849 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 850 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 852 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 854 o remove scope parameter as it is defined in 855 http://tools.ietf.org/html/draft-ietf-oauth-assertions 857 o remove assertion param registration because it [should] be in 858 http://tools.ietf.org/html/draft-ietf-oauth-assertions 860 o fix typo(s) and update/add references 862 draft-ietf-oauth-saml2-bearer-04 864 o Changed the grant_type URI from 865 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 866 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 867 assertion from the path. Recent versions of draft-ietf-oauth-v2 868 no longer refer to extension grants using the word assertion so 869 this URI is more reflective of that. It also more closely aligns 870 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 871 is "http://oauth.net/grant_type/jwt/1.0/bearer". 873 o Added "case sensitive" to scope definition to align with draft- 874 ietf-oauth-v2-15/16. 876 o Updated to reference draft-ietf-oauth-v2-16 878 draft-ietf-oauth-saml2-bearer-03 880 o Cleanup of some editorial issues. 882 draft-ietf-oauth-saml2-bearer-02 884 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 885 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 886 really inherited by this spec anymore) 888 o Change definition of the assertion parameter to be more generally 889 applicable per the suggestion near the end of http://www.ietf.org/ 890 mail-archive/web/oauth/current/msg05253.html 892 o Editorial changes based on feedback 894 draft-ietf-oauth-saml2-bearer-01 896 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 897 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 899 o Update wording in Introduction to talk about extension grant types 900 rather than the assertion grant type which is a term no longer 901 used in OAuth 2.0 903 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 904 progress 906 o Update Parameter Registration Request to use similar terms as 907 draft-ietf-oauth-v2-12 and remove Related information part 909 o Add some text giving discretion to AS on rejecting assertions with 910 unreasonably long validity window. 912 draft-ietf-oauth-saml2-bearer-00 914 o Added Parameter Registration Request for "assertion" to IANA 915 Considerations. 917 o Changed document name to draft-ietf-oauth-saml2-bearer in 918 anticipation of becoming an OAUTH WG item. 920 o Attempt to move the entire definition of the 'assertion' parameter 921 into this draft (it will no longer be defined in OAuth 2 Protocol 922 Framework). 924 draft-campbell-oauth-saml-01 926 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 927 from -10 to -11. 929 o Updated examples. 931 o Relaxed processing rules to allow for more than one 932 SubjectConfirmation element. 934 o Removed the 'MUST NOT contain a NotBefore attribute' on 935 SubjectConfirmationData. 937 o Relaxed wording that ties the subject of the Assertion to the 938 resource owner. 940 o Added some wording about identifying the client when the subject 941 hasn't directly authenticated including an informative reference 942 to SAML V2.0 Condition for Delegation Restriction. 944 o Added a few examples to the language about verifying that the 945 Assertion is valid in all other respects. 947 o Added some wording to the introduction about the similarities to 948 Web SSO in the format and processing rules 950 o Changed the grant_type (was assertion_type) URI from 951 http://oauth.net/assertion_type/saml/2.0/bearer to 952 http://oauth.net/grant_type/assertion/saml/2.0/bearer 954 o Changed title to include "Grant Type" in it. 956 o Editorial updates based on feedback from the WG and others 957 (including capitalization of Assertion when referring to SAML). 959 draft-campbell-oauth-saml-00 961 o Initial I-D 963 Authors' Addresses 965 Brian Campbell 966 Ping Identity 968 Email: brian.d.campbell@gmail.com 970 Chuck Mortimore 971 Salesforce.com 973 Email: cmortimore@salesforce.com 975 Michael B. Jones 976 Microsoft 978 Email: mbj@microsoft.com 979 URI: http://self-issued.info/