idnits 2.17.1 draft-ietf-oauth-saml2-bearer-21.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 (July 23, 2014) is 3557 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) ** Downref: Normative reference to an Informational RFC: RFC 6755 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: January 24, 2015 Salesforce 6 M. Jones 7 Microsoft 8 July 23, 2014 10 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization 11 Grants 12 draft-ietf-oauth-saml2-bearer-21 14 Abstract 16 This specification defines the use of a SAML 2.0 Bearer Assertion as 17 a means for requesting an OAuth 2.0 access token as well as for use 18 as a means of client authentication. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 24, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 58 2.1. Using SAML Assertions as Authorization Grants . . . . . . 4 59 2.2. Using SAML Assertions for Client Authentication . . . . . 5 60 3. Assertion Format and Processing Requirements . . . . . . . . 6 61 3.1. Authorization Grant Processing . . . . . . . . . . . . . 8 62 3.2. Client Authentication Processing . . . . . . . . . . . . 9 63 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 9 64 5. Interoperability Considerations . . . . . . . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Sub-Namespace Registration of urn:ietf:params:oauth 69 :grant-type:saml2-bearer . . . . . . . . . . . . . . . . 12 70 8.2. Sub-Namespace Registration of urn:ietf:params:oauth 71 :client-assertion-type:saml2-bearer . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 76 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 The Security Assertion Markup Language (SAML) 2.0 82 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 83 identity and security information to be shared across security 84 domains. The SAML specification, while primarily targeted at 85 providing cross domain Web browser single sign-on, was also designed 86 to be modular and extensible to facilitate use in other contexts. 88 The Assertion, an XML security token, is a fundamental construct of 89 SAML that is often adopted for use in other protocols and 90 specifications. An Assertion is generally issued by an identity 91 provider and consumed by a service provider who relies on its content 92 to identify the Assertion's subject for security related purposes. 94 The OAuth 2.0 Authorization Framework [RFC6749] provides a method for 95 making authenticated HTTP requests to a resource using an access 96 token. Access tokens are issued to third-party clients by an 97 authorization server (AS) with the (sometimes implicit) approval of 98 the resource owner. In OAuth, an authorization grant is an abstract 99 term used to describe intermediate credentials that represent the 100 resource owner authorization. An authorization grant is used by the 101 client to obtain an access token. Several authorization grant types 102 are defined to support a wide range of client types and user 103 experiences. OAuth also allows for the definition of new extension 104 grant types to support additional clients or to provide a bridge 105 between OAuth and other trust frameworks. Finally, OAuth allows the 106 definition of additional authentication mechanisms to be used by 107 clients when interacting with the authorization server. 109 The Assertion Framework for OAuth 2.0 Client Authentication and 110 Authorization Grants [I-D.ietf-oauth-assertions] specification is an 111 abstract extension to OAuth 2.0 that provides a general framework for 112 the use of Assertions as client credentials and/or authorization 113 grants with OAuth 2.0. This specification profiles the Assertion 114 Framework for OAuth 2.0 Client Authentication and Authorization 115 Grants [I-D.ietf-oauth-assertions] specification to define an 116 extension grant type that uses a SAML 2.0 Bearer Assertion to request 117 an OAuth 2.0 access token as well as for use as client credentials. 118 The format and processing rules for the SAML Assertion defined in 119 this specification are intentionally similar, though not identical, 120 to those in the Web Browser SSO Profile defined in the SAML Profiles 121 [OASIS.saml-profiles-2.0-os] specification. This specification is 122 reusing, to the extent reasonable, concepts and patterns from that 123 well-established Profile. 125 This document defines how a SAML Assertion can be used to request an 126 access token when a client wishes to utilize an existing trust 127 relationship, expressed through the semantics of (and digital 128 signature or keyed message digest calculated over) the SAML 129 Assertion, without a direct user approval step at the authorization 130 server. It also defines how a SAML Assertion can be used as a client 131 authentication mechanism. The use of an Assertion for client 132 authentication is orthogonal to and separable from using an Assertion 133 as an authorization grant. They can be used either in combination or 134 separately. Client assertion authentication is nothing more than an 135 alternative way for a client to authenticate to the token endpoint 136 and must be used in conjunction with some grant type to form a 137 complete and meaningful protocol request. Assertion authorization 138 grants may be used with or without client authentication or 139 identification. Whether or not client authentication is needed in 140 conjunction with an assertion authorization grant, as well as the 141 supported types of client authentication, are policy decisions at the 142 discretion of the authorization server. 144 The process by which the client obtains the SAML Assertion, prior to 145 exchanging it with the authorization server or using it for client 146 authentication, is out of scope. 148 1.1. Notational Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 Unless otherwise noted, all the protocol parameter names and values 155 are case sensitive. 157 1.2. Terminology 159 All terms are as defined in The OAuth 2.0 Authorization Framework 160 [RFC6749], the Assertion Framework for OAuth 2.0 Client 161 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 162 and the Security Assertion Markup Language (SAML) 2.0 163 [OASIS.saml-core-2.0-os] specifications. 165 2. HTTP Parameter Bindings for Transporting Assertions 167 The Assertion Framework for OAuth 2.0 Client Authentication and 168 Authorization Grants [I-D.ietf-oauth-assertions] specification 169 defines generic HTTP parameters for transporting Assertions during 170 interactions with a token endpoint. This section defines specific 171 parameters and treatments of those parameters for use with SAML 2.0 172 Bearer Assertions. 174 2.1. Using SAML Assertions as Authorization Grants 176 To use a SAML Bearer Assertion as an authorization grant, use an 177 access token request as defined in Section 4 of the Assertion 178 Framework for OAuth 2.0 Client Authentication and Authorization 179 Grants [I-D.ietf-oauth-assertions] specification with the following 180 specific parameter values and encodings. 182 The value of the "grant_type" parameter MUST be 183 "urn:ietf:params:oauth:grant-type:saml2-bearer". 185 The value of the "assertion" parameter MUST contain a single SAML 2.0 186 Assertion. The SAML Assertion XML data MUST be encoded using 187 base64url, where the encoding adheres to the definition in Section 5 188 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To 189 avoid the need for subsequent encoding steps (by "application/x-www- 190 form-urlencoded" [W3C.REC-html401-19991224], for example), the 191 base64url encoded data SHOULD NOT be line wrapped and pad characters 192 ("=") SHOULD NOT be included. 194 The "scope" parameter may be used, as defined in the Assertion 195 Framework for OAuth 2.0 Client Authentication and Authorization 196 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 197 requested scope. 199 Authentication of the client is optional, as described in 200 Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the 201 "client_id" is only needed when a form of client authentication that 202 relies on the parameter is used. 204 The following non-normative example demonstrates an Access Token 205 Request with an assertion as an authorization grant (with extra line 206 breaks for display purposes only): 208 POST /token.oauth2 HTTP/1.1 209 Host: as.example.com 210 Content-Type: application/x-www-form-urlencoded 212 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 213 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 215 2.2. Using SAML Assertions for Client Authentication 217 To use a SAML Bearer Assertion for client authentication, use the 218 following parameter values and encodings. 220 The value of the "client_assertion_type" parameter MUST be 221 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer". 223 The value of the "client_assertion" parameter MUST contain a single 224 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 225 using base64url, where the encoding adheres to the definition in 226 Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to 227 zero. To avoid the need for subsequent encoding steps (by 228 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 229 example), the base64url encoded data SHOULD NOT be line wrapped and 230 pad characters ("=") SHOULD NOT be included. 232 The following non-normative example demonstrates a client 233 authenticating using an assertion during the presentation of an 234 authorization code grant in an Access Token Request (with extra line 235 breaks for display purposes only): 237 POST /token.oauth2 HTTP/1.1 238 Host: as.example.com 239 Content-Type: application/x-www-form-urlencoded 241 grant_type=authorization_code& 242 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 243 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 244 %3Aclient-assertion-type%3Asaml2-bearer& 245 client_assertion=PHNhbW...[omitted for brevity]...ZT 247 3. Assertion Format and Processing Requirements 249 In order to issue an access token response as described in OAuth 2.0 250 [RFC6749] or to rely on an Assertion for client authentication, the 251 authorization server MUST validate the Assertion according to the 252 criteria below. Application of additional restrictions and policy 253 are at the discretion of the authorization server. 255 1. The Assertion's element MUST contain a unique 256 identifier for the entity that issued the Assertion. In the 257 absence of an application profile specifying otherwise, 258 compliant applications MUST compare Issuer values using the 259 Simple String Comparison method defined in Section 6.2.1 of RFC 260 3986 [RFC3986]. 262 2. The Assertion MUST contain a element with an 263 element with an element that 264 identifies the authorization server as an intended audience. 265 Section 2.5.1.4 of Assertions and Protocols for the OASIS 266 Security Assertion Markup Language [OASIS.saml-core-2.0-os] 267 defines the and elements and, 268 in addition to the URI references discussed there, the token 269 endpoint URL of the authorization server MAY be used as a URI 270 that identifies the authorization server as an intended 271 audience. Assertions that do not identify the Authorization 272 Server as an intended audience MUST be rejected. In the absence 273 of an application profile specifying otherwise, compliant 274 applications MUST compare the audience values using the Simple 275 String Comparison method defined in Section 6.2.1 of RFC 3986 276 [RFC3986]. 278 3. The Assertion MUST contain a element identifying the 279 principal that is the subject of the Assertion. Additional 280 information identifying the subject/principal MAY be included in 281 an . 283 A. For the authorization grant, the Subject typically 284 identifies an authorized accessor for which the access token 285 is being requested (i.e., the resource owner or an 286 authorized delegate), but in some cases, may be a 287 pseudonymous identifier or other value denoting an anonymous 288 user. 290 B. For client authentication, the Subject MUST be the 291 "client_id" of the OAuth client. 293 4. The Assertion MUST have an expiry that limits the time window 294 during which it can be used. The expiry can be expressed either 295 as the NotOnOrAfter attribute of the element or as 296 the NotOnOrAfter attribute of a suitable 297 element. 299 5. The element MUST contain at least one 300 element that has a Method attribute with a 301 value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". The 302 element MUST contain a 303 element, unless the Assertion has a 304 suitable NotOnOrAfter attribute on the element, in 305 which case the element MAY be omitted. 306 When present, the element MUST have a 307 Recipient attribute with a value indicating the token endpoint 308 URL of the authorization server (or an acceptable alias). The 309 authorization server MUST verify that the value of the Recipient 310 attribute matches the token endpoint URL (or an acceptable 311 alias) to which the Assertion was delivered. The 312 element MUST have a NotOnOrAfter 313 attribute that limits the window during which the Assertion can 314 be confirmed. The element MAY also 315 contain an Address attribute limiting the client address from 316 which the Assertion can be delivered. Verification of the 317 Address is at the discretion of the authorization server. 319 6. The authorization server MUST verify that the NotOnOrAfter 320 instant has not passed, subject to allowable clock skew between 321 systems. An invalid NotOnOrAfter instant on the 322 element invalidates the entire Assertion. An invalid 323 NotOnOrAfter instant on a element only 324 invalidates the individual . The 325 authorization server MAY reject Assertions with a NotOnOrAfter 326 instant that is unreasonably far in the future. The 327 authorization server MAY ensure that Bearer Assertions are not 328 replayed, by maintaining the set of used ID values for the 329 length of time for which the Assertion would be considered valid 330 based on the applicable NotOnOrAfter instant. 332 7. If the Assertion issuer authenticated the subject, the Assertion 333 SHOULD contain a single representing that 334 authentication event. If the Assertion was issued with the 335 intention that the client act autonomously on behalf of the 336 subject, an SHOULD NOT be included and the 337 client presenting the assertion SHOULD be identified in the 338 or similar element in the 339 element, or by other available means like SAML V2.0 Condition 340 for Delegation Restriction [OASIS.saml-deleg-cs]. 342 8. Other statements, in particular elements, 343 MAY be included in the Assertion. 345 9. The Assertion MUST be digitally signed or have a keyed message 346 digest applied by the issuer. The authorization server MUST 347 reject assertions with an invalid signature or keyed message 348 digest. 350 10. Encrypted elements MAY appear in place of their plain text 351 counterparts as defined in [OASIS.saml-core-2.0-os]. 353 11. The authorization server MUST verify that the Assertion is valid 354 in all other respects per [OASIS.saml-core-2.0-os], such as (but 355 not limited to) evaluating all content within the Conditions 356 element including the NotOnOrAfter and NotBefore attributes, 357 rejecting unknown condition types, etc. 359 3.1. Authorization Grant Processing 361 Assertion authorization grants may be used with or without client 362 authentication or identification. Whether or not client 363 authentication is needed in conjunction with an assertion 364 authorization grant, as well as the supported types of client 365 authentication, are policy decisions at the discretion of the 366 authorization server. However, if client credentials are present in 367 the request, the authorization server MUST validate them. 369 If the Assertion is not valid (including if its subject confirmation 370 requirements cannot be met), the authorization server MUST construct 371 an error response as defined in OAuth 2.0 [RFC6749]. The value of 372 the "error" parameter MUST be the "invalid_grant" error code. The 373 authorization server MAY include additional information regarding the 374 reasons the Assertion was considered invalid using the 375 "error_description" or "error_uri" parameters. 377 For example: 379 HTTP/1.1 400 Bad Request 380 Content-Type: application/json 381 Cache-Control: no-store 383 { 384 "error":"invalid_grant", 385 "error_description":"Audience validation failed" 386 } 388 3.2. Client Authentication Processing 390 If the client Assertion is not valid (including if its subject 391 confirmation requirements cannot be met), the authorization server 392 MUST construct an error response as defined in OAuth 2.0 [RFC6749]. 393 The value of the "error" parameter MUST be the "invalid_client" error 394 code. The authorization server MAY include additional information 395 regarding the reasons the Assertion was considered invalid using the 396 "error_description" or "error_uri" parameters. 398 4. Authorization Grant Example 400 Though non-normative, the following examples illustrate what a 401 conforming Assertion and access token request would look like. 403 The example shows an assertion issued and signed by the SAML Identity 404 Provider identified as "https://saml-idp.example.com". The subject 405 of the assertion is identified by email address as 406 "brian@example.com", who authenticated to the Identity Provider by 407 means of a digital signature where the key was validated as part of 408 an X.509 Public Key Infrastructure. The intended audience of the 409 assertion is "https://saml-sp.example.net", which is an identifier 410 for a SAML Service Provider with which the authorization server 411 identifies itself. The assertion is sent as part of an access token 412 request to the authorization server's token endpoint at 413 "https://authz.example.net/token.oauth2". 415 Below is an example SAML 2.0 Assertion (whitespace formatting is for 416 display purposes only): 418 422 https://saml-idp.example.com 423 424 [...omitted for brevity...] 425 426 427 429 brian@example.com 430 431 433 436 437 438 439 440 https://saml-sp.example.net 441 442 443 444 445 446 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 447 448 449 450 452 Figure 1: Example SAML 2.0 Assertion 454 To present the Assertion shown in the previous example as part of an 455 access token request, for example, the client might make the 456 following HTTPS request (with extra line breaks for display purposes 457 only): 459 POST /token.oauth2 HTTP/1.1 460 Host: authz.example.net 461 Content-Type: application/x-www-form-urlencoded 463 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 464 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 465 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 467 Figure 2: Example Request 469 5. Interoperability Considerations 471 Agreement between system entities regarding identifiers, keys, and 472 endpoints is required in order to achieve interoperable deployments 473 of this profile. Specific items that require agreement are as 474 follows: values for the issuer and audience identifiers, the location 475 of the token endpoint, the key used to apply and verify the digital 476 signature over the assertion, one-time use restrictions on 477 assertions, maximum assertion lifetime allowed, and the specific 478 subject and attribute requirements of the assertion. The exchange of 479 such information is explicitly out of scope for this specification 480 and typical deployment of it will be done alongside existing SAML Web 481 SSO deployments that have already established a means of exchanging 482 such information. Metadata for the OASIS Security Assertion Markup 483 Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common 484 method of exchanging SAML related information about system entities. 486 6. Security Considerations 488 The security considerations described within the Assertion Framework 489 for OAuth 2.0 Client Authentication and Authorization Grants 490 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 491 [RFC6749], and the Security and Privacy Considerations for the OASIS 492 Security Assertion Markup Language (SAML) V2.0 493 [OASIS.saml-sec-consider-2.0-os] specifications are all applicable to 494 this document. 496 The specification does not mandate replay protection for the SAML 497 assertion usage for either the authorization grant or for client 498 authentication. It is an optional feature, which implementations may 499 employ at their own discretion. 501 7. Privacy Considerations 503 A SAML Assertion may contain privacy-sensitive information and, to 504 prevent disclosure of such information to unintended parties, should 505 only be transmitted over encrypted channels, such as TLS. In cases 506 where it is desirable to prevent disclosure of certain information 507 the client, the Subject and/or individual attributes of a SAML 508 Assertion should be encrypted to the authorization server. 510 Deployments should determine the minimum amount of information 511 necessary to complete the exchange and include only that information 512 in an Assertion (typically by limiting what information is included 513 in an or omitting it altogether). In some 514 cases, the Subject can be a value representing an anonymous or 515 pseudonymous user, as described in Section 6.3.1 of the Assertion 516 Framework for OAuth 2.0 Client Authentication and Authorization 517 Grants [I-D.ietf-oauth-assertions]. 519 8. IANA Considerations 521 8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- 522 type:saml2-bearer 524 This is a request to IANA to please register the value "grant- 525 type:saml2-bearer" in the registry urn:ietf:params:oauth established 526 in An IETF URN Sub-Namespace for OAuth [RFC6755]. 528 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 530 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 531 OAuth 2.0 533 o Change controller: IETF 535 o Specification Document: [[this document]] 537 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 538 assertion-type:saml2-bearer 540 This is a request to IANA to please register the value "client- 541 assertion-type:saml2-bearer" in the registry urn:ietf:params:oauth 542 established in An IETF URN Sub-Namespace for OAuth [RFC6755]. 544 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 546 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 547 Client Authentication 549 o Change controller: IETF 551 o Specification Document: [[this document]] 553 9. References 555 9.1. Normative References 557 [I-D.ietf-oauth-assertions] 558 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 559 "Assertion Framework for OAuth 2.0 Client Authentication 560 and Authorization Grants", draft-ietf-oauth-assertions 561 (work in progress), July 2014. 563 [OASIS.saml-core-2.0-os] 564 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 565 "Assertions and Protocol for the OASIS Security Assertion 566 Markup Language (SAML) V2.0", OASIS Standard saml-core- 567 2.0-os, March 2005. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 573 Resource Identifier (URI): Generic Syntax", STD 66, RFC 574 3986, January 2005. 576 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 577 Encodings", RFC 4648, October 2006. 579 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 580 6749, October 2012. 582 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 583 for OAuth", RFC 6755, October 2012. 585 9.2. Informative References 587 [OASIS.saml-deleg-cs] 588 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 589 Restriction", Nov 2009. 591 [OASIS.saml-metadata-2.0-os] 592 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 593 "Metadata for the Security Assertion Markup Language 594 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 595 2005. 597 [OASIS.saml-profiles-2.0-os] 598 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 599 P., Philpott, R., and E. Maler, "Profiles for the OASIS 600 Security Assertion Markup Language (SAML) V2.0", OASIS 601 Standard OASIS.saml-profiles-2.0-os, March 2005. 603 [OASIS.saml-sec-consider-2.0-os] 604 Hirsch, F., Philpott, R., and E. Maler, "Security and 605 Privacy Considerations for the OASIS Security Markup 606 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 607 2.0-os, March 2005. 609 [W3C.REC-html401-19991224] 610 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 611 Specification", World Wide Web Consortium Recommendation 612 REC-html401-19991224, December 1999, 613 . 615 Appendix A. Acknowledgements 617 The following people contributed wording and concepts to this 618 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 619 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 620 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes 621 Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar. 623 Appendix B. Document History 625 [[ to be removed by RFC editor before publication as an RFC ]] 627 draft-ietf-oauth-saml2-bearer-21 629 o Added Privacy Considerations section per AD review discussion 630 http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html 631 and http://www.ietf.org/mail-archive/web/oauth/current/ 632 msg13144.html 634 draft-ietf-oauth-saml2-bearer-20 636 o Clarified some text around the treatment of subject based on the 637 rough rough consensus from the thread staring at 638 http://www.ietf.org/mail-archive/web/oauth/current/msg12630.html 640 draft-ietf-oauth-saml2-bearer-19 642 o Updated references. 644 draft-ietf-oauth-saml2-bearer-18 645 o Clean up language around subject per http://www.ietf.org/mail- 646 archive/web/oauth/current/msg12254.html. 648 o As suggested in http://www.ietf.org/mail- 649 archive/web/oauth/current/msg12253.html stated that "In the 650 absence of an application profile specifying otherwise, compliant 651 applications MUST compare the audience/issuer values using the 652 Simple String Comparison method defined in Section 6.2.1 of RFC 653 3986." 655 o Clarify the potentially confusing language about the AS confirming 656 the assertion http://www.ietf.org/mail-archive/web/oauth/current/ 657 msg12255.html. 659 o Combine the two items about AuthnStatement and drop the word 660 presenter as discussed in http://www.ietf.org/mail- 661 archive/web/oauth/current/msg12257.html. 663 o Added one-time use, maximum lifetime, and specific subject and 664 attribute requirements to Interoperability Considerations based on 665 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 667 o Reword security considerations and mention that replay protection 668 is not mandated based on http://www.ietf.org/mail- 669 archive/web/oauth/current/msg12259.html. 671 draft-ietf-oauth-saml2-bearer-17 673 o Stated that issuer and audience values SHOULD be compared using 674 the Simple String Comparison method defined in Section 6.2.1 of 675 RFC 3986 unless otherwise specified by the application. 677 draft-ietf-oauth-saml2-bearer-16 679 o Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth 680 2.0" to "SAML 2.0 Profile for OAuth 2.0 Client Authentication and 681 Authorization Grants" to be more explicit about the scope of the 682 document per http://www.ietf.org/mail-archive/web/oauth/current/ 683 msg11063.html. 685 o Fixed typo in text identifying the presenter from "or similar 686 element, the" to "or similar element in the". 688 o Numbered the list of processing rules. 690 o Smallish editorial cleanups to try and improve readability and 691 comprehensibility. 693 o Cleaner split out of the processing rules in cases where they 694 differ for client authentication and authorization grants. 696 o Clarified the parameters that are used/available for authorization 697 grants. 699 o Added Interoperability Considerations section and info reference 700 to SAML Metadata. 702 o Added more explanatory context to the example in Section 4. 704 draft-ietf-oauth-saml2-bearer-15 706 o Reference RFC 6749 and RFC 6755. 708 o Update draft-ietf-oauth-assertions reference to -06. 710 o Remove extraneous word per http://www.ietf.org/mail- 711 archive/web/oauth/current/msg10055.html 713 draft-ietf-oauth-saml2-bearer-14 715 o Add more text to intro explaining that an assertion grant type can 716 be used with or without client authentication/identification and 717 that client assertion authentication is nothing more than an 718 alternative way for a client to authenticate to the token endpoint 720 o Add examples to Sections 2.1 and 2.2 722 o Update references 724 draft-ietf-oauth-saml2-bearer-13 726 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 727 -28 729 o Changed "Description" to "Specification Document" in both 730 registration requests in IANA Considerations per changes to the 731 template in ietf-oauth-urn-sub-ns(-03) 733 o Added "(or an acceptable alias)" so that it's in both sentences 734 about Recipient and the token endpoint URL so there's no ambiguity 736 o Update area and workgroup (now Security and OAuth was Internet and 737 nothing) 739 draft-ietf-oauth-saml2-bearer-12 740 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 741 draft-ietf-oauth-assertions from -02 to -03 743 draft-ietf-oauth-saml2-bearer-11 745 o Removed text about limited lifetime access tokens and the SHOULD 746 NOT on issuing refresh tokens. The text was moved to draft-ietf- 747 oauth-assertions-02 and somewhat modified per http://www.ietf.org/ 748 mail-archive/web/oauth/current/msg08298.html. 750 o Fixed typo/missing word per http://www.ietf.org/mail- 751 archive/web/oauth/current/msg08733.html. 753 o Added Terminology section. 755 draft-ietf-oauth-saml2-bearer-10 757 o fix a spelling mistake 759 draft-ietf-oauth-saml2-bearer-09 761 o Attempt to address an ambiguity around validation requirements 762 when the Conditions element contain a NotOnOrAfter and 763 SubjectConfirmation/SubjectConfirmationData does too. Basically 764 it needs to have at least one bearer SubjectConfirmation element 765 but that element can omit SubjectConfirmationData, if Conditions 766 has an expiry on it. Otherwise, a valid SubjectConfirmation must 767 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 768 And any SubjectConfirmationData that has those elements needs to 769 have them checked. 771 o clarified that AudienceRestriction is under Conditions (even 772 though it's implied by schema) 774 o fix a typo 776 draft-ietf-oauth-saml2-bearer-08 778 o fix some typos 780 draft-ietf-oauth-saml2-bearer-07 782 o update reference from draft-campbell-oauth-urn-sub-ns to draft- 783 ietf-oauth-urn-sub-ns 785 o Updated to reference draft-ietf-oauth-v2-20 787 draft-ietf-oauth-saml2-bearer-06 788 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 790 draft-ietf-oauth-saml2-bearer-05 792 o Allow for subject confirmation data to be optional when Conditions 793 contain audience and NotOnOrAfter 795 o Rework most of the spec to profile draft-ietf-oauth-assertions for 796 both authn and authz including (but not limited to): 798 * remove requirement for issuer to be 799 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 801 * change wording on Subject requirements 803 o using a MAY, explicitly say that the Audience can be token 804 endpoint URL of the authorization server 806 o Change title to be more generic (allowing for client authn too) 808 o added client authentication to the abstract 810 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 811 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 813 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 815 o remove scope parameter as it is defined in 816 http://tools.ietf.org/html/draft-ietf-oauth-assertions 818 o remove assertion param registration because it [should] be in 819 http://tools.ietf.org/html/draft-ietf-oauth-assertions 821 o fix typo(s) and update/add references 823 draft-ietf-oauth-saml2-bearer-04 825 o Changed the grant_type URI from 826 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 827 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 828 assertion from the path. Recent versions of draft-ietf-oauth-v2 829 no longer refer to extension grants using the word assertion so 830 this URI is more reflective of that. It also more closely aligns 831 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 832 is "http://oauth.net/grant_type/jwt/1.0/bearer". 834 o Added "case sensitive" to scope definition to align with draft- 835 ietf-oauth-v2-15/16. 837 o Updated to reference draft-ietf-oauth-v2-16 839 draft-ietf-oauth-saml2-bearer-03 841 o Cleanup of some editorial issues. 843 draft-ietf-oauth-saml2-bearer-02 845 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 846 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 847 really inherited by this spec anymore) 849 o Change definition of the assertion parameter to be more generally 850 applicable per the suggestion near the end of http://www.ietf.org/ 851 mail-archive/web/oauth/current/msg05253.html 853 o Editorial changes based on feedback 855 draft-ietf-oauth-saml2-bearer-01 857 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 858 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 860 o Update wording in Introduction to talk about extension grant types 861 rather than the assertion grant type which is a term no longer 862 used in OAuth 2.0 864 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 865 progress 867 o Update Parameter Registration Request to use similar terms as 868 draft-ietf-oauth-v2-12 and remove Related information part 870 o Add some text giving discretion to AS on rejecting assertions with 871 unreasonably long validity window. 873 draft-ietf-oauth-saml2-bearer-00 875 o Added Parameter Registration Request for "assertion" to IANA 876 Considerations. 878 o Changed document name to draft-ietf-oauth-saml2-bearer in 879 anticipation of becoming an OAUTH WG item. 881 o Attempt to move the entire definition of the 'assertion' parameter 882 into this draft (it will no longer be defined in OAuth 2 Protocol 883 Framework). 885 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 886 from -10 to -11. 888 o Updated examples. 890 o Relaxed processing rules to allow for more than one 891 SubjectConfirmation element. 893 o Removed the 'MUST NOT contain a NotBefore attribute' on 894 SubjectConfirmationData. 896 o Relaxed wording that ties the subject of the Assertion to the 897 resource owner. 899 o Added some wording about identifying the client when the subject 900 hasn't directly authenticated including an informative reference 901 to SAML V2.0 Condition for Delegation Restriction. 903 o Added a few examples to the language about verifying that the 904 Assertion is valid in all other respects. 906 o Added some wording to the introduction about the similarities to 907 Web SSO in the format and processing rules 909 o Changed the grant_type (was assertion_type) URI from 910 http://oauth.net/assertion_type/saml/2.0/bearer to 911 http://oauth.net/grant_type/assertion/saml/2.0/bearer 913 o Changed title to include "Grant Type" in it. 915 o Editorial updates based on feedback from the WG and others 916 (including capitalization of Assertion when referring to SAML). 918 draft-campbell-oauth-saml-00 920 o Initial I-D 922 Authors' Addresses 924 Brian Campbell 925 Ping Identity 927 Email: brian.d.campbell@gmail.com 928 Chuck Mortimore 929 Salesforce.com 931 Email: cmortimore@salesforce.com 933 Michael B. Jones 934 Microsoft 936 Email: mbj@microsoft.com 937 URI: http://self-issued.info/