idnits 2.17.1 draft-ietf-oauth-saml2-bearer-19.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 (March 19, 2014) is 3662 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: September 20, 2014 Salesforce 6 M. Jones 7 Microsoft 8 March 19, 2014 10 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization 11 Grants 12 draft-ietf-oauth-saml2-bearer-19 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 September 20, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . 5 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Sub-Namespace Registration of 68 urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 12 69 7.2. Sub-Namespace Registration of 70 urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 75 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 The Security Assertion Markup Language (SAML) 2.0 81 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 82 identity and security information to be shared across security 83 domains. The SAML specification, while primarily targeted at 84 providing cross domain Web browser single sign-on, was also designed 85 to be modular and extensible to facilitate use in other contexts. 87 The Assertion, an XML security token, is a fundamental construct of 88 SAML that is often adopted for use in other protocols and 89 specifications. An Assertion is generally issued by an identity 90 provider and consumed by a service provider who relies on its content 91 to identify the Assertion's subject for security related purposes. 93 The OAuth 2.0 Authorization Framework [RFC6749] provides a method for 94 making authenticated HTTP requests to a resource using an access 95 token. Access tokens are issued to third-party clients by an 96 authorization server (AS) with the (sometimes implicit) approval of 97 the resource owner. In OAuth, an authorization grant is an abstract 98 term used to describe intermediate credentials that represent the 99 resource owner authorization. An authorization grant is used by the 100 client to obtain an access token. Several authorization grant types 101 are defined to support a wide range of client types and user 102 experiences. OAuth also allows for the definition of new extension 103 grant types to support additional clients or to provide a bridge 104 between OAuth and other trust frameworks. Finally, OAuth allows the 105 definition of additional authentication mechanisms to be used by 106 clients when interacting with the authorization server. 108 The Assertion Framework for OAuth 2.0 Client Authentication and 109 Authorization Grants [I-D.ietf-oauth-assertions] specification is an 110 abstract extension to OAuth 2.0 that provides a general framework for 111 the use of Assertions as client credentials and/or authorization 112 grants with OAuth 2.0. This specification profiles the Assertion 113 Framework for OAuth 2.0 Client Authentication and Authorization 114 Grants [I-D.ietf-oauth-assertions] specification to define an 115 extension grant type that uses a SAML 2.0 Bearer Assertion to request 116 an OAuth 2.0 access token as well as for use as client credentials. 117 The format and processing rules for the SAML Assertion defined in 118 this specification are intentionally similar, though not identical, 119 to those in the Web Browser SSO Profile defined in the SAML Profiles 120 [OASIS.saml-profiles-2.0-os] specification. This specification is 121 reusing, to the extent reasonable, concepts and patterns from that 122 well-established Profile. 124 This document defines how a SAML Assertion can be used to request an 125 access token when a client wishes to utilize an existing trust 126 relationship, expressed through the semantics of (and digital 127 signature or keyed message digest calculated over) the SAML 128 Assertion, without a direct user approval step at the authorization 129 server. It also defines how a SAML Assertion can be used as a client 130 authentication mechanism. The use of an Assertion for client 131 authentication is orthogonal to and separable from using an Assertion 132 as an authorization grant. They can be used either in combination or 133 separately. Client assertion authentication is nothing more than an 134 alternative way for a client to authenticate to the token endpoint 135 and must be used in conjunction with some grant type to form a 136 complete and meaningful protocol request. Assertion authorization 137 grants may be used with or without client authentication or 138 identification. Whether or not client authentication is needed in 139 conjunction with an assertion authorization grant, as well as the 140 supported types of client authentication, are policy decisions at the 141 discretion of the authorization server. 143 The process by which the client obtains the SAML Assertion, prior to 144 exchanging it with the authorization server or using it for client 145 authentication, is out of scope. 147 1.1. Notational Conventions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 Unless otherwise noted, all the protocol parameter names and values 154 are case sensitive. 156 1.2. Terminology 158 All terms are as defined in The OAuth 2.0 Authorization Framework 159 [RFC6749], the Assertion Framework for OAuth 2.0 Client 160 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 161 and the Security Assertion Markup Language (SAML) 2.0 162 [OASIS.saml-core-2.0-os] specifications. 164 2. HTTP Parameter Bindings for Transporting Assertions 166 The Assertion Framework for OAuth 2.0 Client Authentication and 167 Authorization Grants [I-D.ietf-oauth-assertions] specification 168 defines generic HTTP parameters for transporting Assertions during 169 interactions with a token endpoint. This section defines specific 170 parameters and treatments of those parameters for use with SAML 2.0 171 Bearer Assertions. 173 2.1. Using SAML Assertions as Authorization Grants 175 To use a SAML Bearer Assertion as an authorization grant, use an 176 access token request as defined in Section 4 of the Assertion 177 Framework for OAuth 2.0 Client Authentication and Authorization 178 Grants [I-D.ietf-oauth-assertions] specification with the following 179 specific parameter values and encodings. 181 The value of the "grant_type" parameter MUST be 182 "urn:ietf:params:oauth:grant-type:saml2-bearer". 184 The value of the "assertion" parameter MUST contain a single SAML 2.0 185 Assertion. The SAML Assertion XML data MUST be encoded using 186 base64url, where the encoding adheres to the definition in Section 5 187 of RFC 4648 [RFC4648] and where the padding bits are set to zero. To 188 avoid the need for subsequent encoding steps (by "application/ 189 x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the 190 base64url encoded data SHOULD NOT be line wrapped and pad characters 191 ("=") SHOULD NOT be included. 193 The "scope" parameter may be used, as defined in the Assertion 194 Framework for OAuth 2.0 Client Authentication and Authorization 195 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 196 requested scope. 198 Authentication of the client is optional, as described in Section 199 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is 200 only needed when a form of client authentication that relies on the 201 parameter is used. 203 The following non-normative example demonstrates an Access Token 204 Request with an assertion as an authorization grant (with extra line 205 breaks for display purposes only): 207 POST /token.oauth2 HTTP/1.1 208 Host: as.example.com 209 Content-Type: application/x-www-form-urlencoded 211 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 212 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 214 2.2. Using SAML Assertions for Client Authentication 216 To use a SAML Bearer Assertion for client authentication, use the 217 following parameter values and encodings. 219 The value of the "client_assertion_type" parameter MUST be 220 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer". 222 The value of the "client_assertion" parameter MUST contain a single 223 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 224 using base64url, where the encoding adheres to the definition in 225 Section 5 of RFC 4648 [RFC4648] and where the padding bits are set to 226 zero. To avoid the need for subsequent encoding steps (by 227 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 228 example), the base64url encoded data SHOULD NOT be line wrapped and 229 pad characters ("=") SHOULD NOT be included. 231 The following non-normative example demonstrates a client 232 authenticating using an assertion during the presentation of an 233 authorization code grant in an Access Token Request (with extra line 234 breaks for display purposes only): 236 POST /token.oauth2 HTTP/1.1 237 Host: as.example.com 238 Content-Type: application/x-www-form-urlencoded 240 grant_type=authorization_code& 241 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 242 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 243 %3Aclient-assertion-type%3Asaml2-bearer& 244 client_assertion=PHNhbW...[omitted for brevity]...ZT 246 3. Assertion Format and Processing Requirements 248 In order to issue an access token response as described in OAuth 2.0 249 [RFC6749] or to rely on an Assertion for client authentication, the 250 authorization server MUST validate the Assertion according to the 251 criteria below. Application of additional restrictions and policy 252 are at the discretion of the authorization server. 254 1. The Assertion's element MUST contain a unique 255 identifier for the entity that issued the Assertion. In the 256 absence of an application profile specifying otherwise, 257 compliant applications MUST compare Issuer values using the 258 Simple String Comparison method defined in Section 6.2.1 of RFC 259 3986 [RFC3986]. 261 2. The Assertion MUST contain a element with an 262 element with an element that 263 identifies the authorization server as an intended audience. 264 Section 2.5.1.4 of Assertions and Protocols for the OASIS 265 Security Assertion Markup Language [OASIS.saml-core-2.0-os] 266 defines the and elements and, 267 in addition to the URI references discussed there, the token 268 endpoint URL of the authorization server MAY be used as a URI 269 that identifies the authorization server as an intended 270 audience. Assertions that do not identify the Authorization 271 Server as an intended audience MUST be rejected. In the absence 272 of an application profile specifying otherwise, compliant 273 applications MUST compare the audience values using the Simple 274 String Comparison method defined in Section 6.2.1 of RFC 3986 275 [RFC3986]. 277 3. The Assertion MUST contain a element identifying the 278 principal that is the subject of the Assertion. Additional 279 information identifying the subject/principal MAY be included in 280 an . 282 A. For the authorization grant, the Subject SHOULD identify an 283 authorized accessor for whom the access token is being 284 requested (typically the resource owner, or an authorized 285 delegate). 287 B. For client authentication, the Subject MUST be the 288 "client_id" of the OAuth client. 290 4. The Assertion MUST have an expiry that limits the time window 291 during which it can be used. The expiry can be expressed either 292 as the NotOnOrAfter attribute of the element or as 293 the NotOnOrAfter attribute of a suitable 294 element. 296 5. The element MUST contain at least one 297 element that has a Method attribute with a 298 value of "urn:oasis:names:tc:SAML:2.0:cm:bearer". The 299 element MUST contain a 300 element, unless the Assertion has a 301 suitable NotOnOrAfter attribute on the element, in 302 which case the element MAY be omitted. 303 When present, the element MUST have a 304 Recipient attribute with a value indicating the token endpoint 305 URL of the authorization server (or an acceptable alias). The 306 authorization server MUST verify that the value of the Recipient 307 attribute matches the token endpoint URL (or an acceptable 308 alias) to which the Assertion was delivered. The 309 element MUST have a NotOnOrAfter 310 attribute that limits the window during which the Assertion can 311 be confirmed. The element MAY also 312 contain an Address attribute limiting the client address from 313 which the Assertion can be delivered. Verification of the 314 Address is at the discretion of the authorization server. 316 6. The authorization server MUST verify that the NotOnOrAfter 317 instant has not passed, subject to allowable clock skew between 318 systems. An invalid NotOnOrAfter instant on the 319 element invalidates the entire Assertion. An invalid 320 NotOnOrAfter instant on a element only 321 invalidates the individual . The 322 authorization server MAY reject Assertions with a NotOnOrAfter 323 instant that is unreasonably far in the future. The 324 authorization server MAY ensure that Bearer Assertions are not 325 replayed, by maintaining the set of used ID values for the 326 length of time for which the Assertion would be considered valid 327 based on the applicable NotOnOrAfter instant. 329 7. If the Assertion issuer authenticated the subject, the Assertion 330 SHOULD contain a single representing that 331 authentication event. If the Assertion was issued with the 332 intention that the client act autonomously on behalf of the 333 subject, an SHOULD NOT be included and the 334 client presenting the assertion SHOULD be identified in the 335 or similar element in the 336 element, or by other available means like SAML V2.0 Condition 337 for Delegation Restriction [OASIS.saml-deleg-cs]. 339 8. Other statements, in particular elements, 340 MAY be included in the Assertion. 342 9. The Assertion MUST be digitally signed or have a keyed message 343 digest applied by the issuer. The authorization server MUST 344 reject assertions with an invalid signature or keyed message 345 digest. 347 10. Encrypted elements MAY appear in place of their plain text 348 counterparts as defined in [OASIS.saml-core-2.0-os]. 350 11. The authorization server MUST verify that the Assertion is valid 351 in all other respects per [OASIS.saml-core-2.0-os], such as (but 352 not limited to) evaluating all content within the Conditions 353 element including the NotOnOrAfter and NotBefore attributes, 354 rejecting unknown condition types, etc. 356 3.1. Authorization Grant Processing 358 Assertion authorization grants may be used with or without client 359 authentication or identification. Whether or not client 360 authentication is needed in conjunction with an assertion 361 authorization grant, as well as the supported types of client 362 authentication, are policy decisions at the discretion of the 363 authorization server. However, if client credentials are present in 364 the request, the authorization server MUST validate them. 366 If the Assertion is not valid (including if its subject confirmation 367 requirements cannot be met), the authorization server MUST construct 368 an error response as defined in OAuth 2.0 [RFC6749]. The value of 369 the "error" parameter MUST be the "invalid_grant" error code. The 370 authorization server MAY include additional information regarding the 371 reasons the Assertion was considered invalid using the 372 "error_description" or "error_uri" parameters. 374 For example: 376 HTTP/1.1 400 Bad Request 377 Content-Type: application/json 378 Cache-Control: no-store 380 { 381 "error":"invalid_grant", 382 "error_description":"Audience validation failed" 383 } 385 3.2. Client Authentication Processing 387 If the client Assertion is not valid (including if its subject 388 confirmation requirements cannot be met), the authorization server 389 MUST construct an error response as defined in OAuth 2.0 [RFC6749]. 390 The value of the "error" parameter MUST be the "invalid_client" error 391 code. The authorization server MAY include additional information 392 regarding the reasons the Assertion was considered invalid using the 393 "error_description" or "error_uri" parameters. 395 4. Authorization Grant Example 397 Though non-normative, the following examples illustrate what a 398 conforming Assertion and access token request would look like. 400 The example shows an assertion issued and signed by the SAML Identity 401 Provider identified as "https://saml-idp.example.com". The subject 402 of the assertion is identified by email address as 403 "brian@example.com", who authenticated to the Identity Provider by 404 means of a digital signature where the key was validated as part of 405 an X.509 Public Key Infrastructure. The intended audience of the 406 assertion is "https://saml-sp.example.net", which is an identifier 407 for a SAML Service Provider with which the authorization server 408 identifies itself. The assertion is sent as part of an access token 409 request to the authorization server's token endpoint at 410 "https://authz.example.net/token.oauth2". 412 Below is an example SAML 2.0 Assertion (whitespace formatting is for 413 display purposes only): 415 419 https://saml-idp.example.com 420 421 [...omitted for brevity...] 422 423 424 426 brian@example.com 427 428 430 433 434 435 436 437 https://saml-sp.example.net 438 439 440 441 442 443 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 444 445 446 447 449 Figure 1: Example SAML 2.0 Assertion 451 To present the Assertion shown in the previous example as part of an 452 access token request, for example, the client might make the 453 following HTTPS request (with extra line breaks for display purposes 454 only): 456 POST /token.oauth2 HTTP/1.1 457 Host: authz.example.net 458 Content-Type: application/x-www-form-urlencoded 460 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 461 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 462 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 464 Figure 2: Example Request 466 5. Interoperability Considerations 468 Agreement between system entities regarding identifiers, keys, and 469 endpoints is required in order to achieve interoperable deployments 470 of this profile. Specific items that require agreement are as 471 follows: values for the issuer and audience identifiers, the location 472 of the token endpoint, the key used to apply and verify the digital 473 signature over the assertion, one-time use restrictions on 474 assertions, maximum assertion lifetime allowed, and the specific 475 subject and attribute requirements of the assertion. The exchange of 476 such information is explicitly out of scope for this specification 477 and typical deployment of it will be done alongside existing SAML Web 478 SSO deployments that have already established a means of exchanging 479 such information. Metadata for the OASIS Security Assertion Markup 480 Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common 481 method of exchanging SAML related information about system entities. 483 6. Security Considerations 485 The security considerations described within the Assertion Framework 486 for OAuth 2.0 Client Authentication and Authorization Grants 487 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 488 [RFC6749], and the Security and Privacy Considerations for the OASIS 489 Security Assertion Markup Language (SAML) V2.0 490 [OASIS.saml-sec-consider-2.0-os] specifications are all applicable to 491 this document. 493 The specification does not mandate replay protection for the SAML 494 assertion usage for either the authorization grant or for client 495 authentication. It is an optional feature, which implementations may 496 employ at their own discretion. 498 7. IANA Considerations 500 7.1. Sub-Namespace Registration of 501 urn:ietf:params:oauth:grant-type:saml2-bearer 503 This is a request to IANA to please register the value 504 "grant-type:saml2-bearer" in the registry urn:ietf:params:oauth 505 established in An IETF URN Sub-Namespace for OAuth [RFC6755]. 507 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 509 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 510 OAuth 2.0 512 o Change controller: IETF 514 o Specification Document: [[this document]] 516 7.2. Sub-Namespace Registration of 517 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 519 This is a request to IANA to please register the value 520 "client-assertion-type:saml2-bearer" in the registry 521 urn:ietf:params:oauth established in An IETF URN Sub-Namespace for 522 OAuth [RFC6755]. 524 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 526 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 527 Client Authentication 529 o Change controller: IETF 531 o Specification Document: [[this document]] 533 8. References 535 8.1. Normative References 537 [I-D.ietf-oauth-assertions] 538 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 539 "Assertion Framework for OAuth 2.0 Client Authentication 540 and Authorization Grants", draft-ietf-oauth-assertions 541 (work in progress), March 2014. 543 [OASIS.saml-core-2.0-os] 544 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 545 "Assertions and Protocol for the OASIS Security Assertion 546 Markup Language (SAML) V2.0", OASIS Standard saml-core- 547 2.0-os, March 2005. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 553 Resource Identifier (URI): Generic Syntax", STD 66, 554 RFC 3986, January 2005. 556 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 557 Encodings", RFC 4648, October 2006. 559 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 560 RFC 6749, October 2012. 562 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 563 for OAuth", RFC 6755, October 2012. 565 8.2. Informative References 567 [OASIS.saml-deleg-cs] 568 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 569 Restriction", Nov 2009. 571 [OASIS.saml-metadata-2.0-os] 572 Cantor, S., Moreh, J., Philpott, R., and E. Maler, 573 "Metadata for the Security Assertion Markup Language 574 (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, 575 March 2005. 577 [OASIS.saml-profiles-2.0-os] 578 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 579 P., Philpott, R., and E. Maler, "Profiles for the OASIS 580 Security Assertion Markup Language (SAML) V2.0", OASIS 581 Standard OASIS.saml-profiles-2.0-os, March 2005. 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. 589 [W3C.REC-html401-19991224] 590 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 591 Specification", World Wide Web Consortium 592 Recommendation REC-html401-19991224, December 1999, 593 . 595 Appendix A. Acknowledgements 597 The following people contributed wording and concepts to this 598 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 599 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 600 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Hannes 601 Tschofenig, David Waite, Phil Hunt, and Mukesh Bhatnagar. 603 Appendix B. Document History 605 [[ to be removed by RFC editor before publication as an RFC ]] 607 draft-ietf-oauth-saml2-bearer-19 609 o Updated references. 611 draft-ietf-oauth-saml2-bearer-18 613 o Clean up language around subject per 614 http://www.ietf.org/mail-archive/web/oauth/current/msg12254.html. 616 o As suggested in 617 http://www.ietf.org/mail-archive/web/oauth/current/msg12253.html 618 stated that "In the absence of an application profile specifying 619 otherwise, compliant applications MUST compare the audience/issuer 620 values using the Simple String Comparison method defined in 621 Section 6.2.1 of RFC 3986." 623 o Clarify the potentially confusing language about the AS confirming 624 the assertion 625 http://www.ietf.org/mail-archive/web/oauth/current/msg12255.html. 627 o Combine the two items about AuthnStatement and drop the word 628 presenter as discussed in 629 http://www.ietf.org/mail-archive/web/oauth/current/msg12257.html. 631 o Added one-time use, maximum lifetime, and specific subject and 632 attribute requirements to Interoperability Considerations based on 633 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 635 o Reword security considerations and mention that replay protection 636 is not mandated based on 637 http://www.ietf.org/mail-archive/web/oauth/current/msg12259.html. 639 o Stated that issuer and audience values SHOULD be compared using 640 the Simple String Comparison method defined in Section 6.2.1 of 641 RFC 3986 unless otherwise specified by the application. 643 draft-ietf-oauth-saml2-bearer-16 645 o Changed title from "SAML 2.0 Bearer Assertion Profiles for OAuth 646 2.0" to "SAML 2.0 Profile for OAuth 2.0 Client Authentication and 647 Authorization Grants" to be more explicit about the scope of the 648 document per 649 http://www.ietf.org/mail-archive/web/oauth/current/msg11063.html. 651 o Fixed typo in text identifying the presenter from "or similar 652 element, the" to "or similar element in the". 654 o Numbered the list of processing rules. 656 o Smallish editorial cleanups to try and improve readability and 657 comprehensibility. 659 o Cleaner split out of the processing rules in cases where they 660 differ for client authentication and authorization grants. 662 o Clarified the parameters that are used/available for authorization 663 grants. 665 o Added Interoperability Considerations section and info reference 666 to SAML Metadata. 668 o Added more explanatory context to the example in Section 4. 670 draft-ietf-oauth-saml2-bearer-15 672 o Reference RFC 6749 and RFC 6755. 674 o Update draft-ietf-oauth-assertions reference to -06. 676 o Remove extraneous word per 677 http://www.ietf.org/mail-archive/web/oauth/current/msg10055.html 679 draft-ietf-oauth-saml2-bearer-14 681 o Add more text to intro explaining that an assertion grant type can 682 be used with or without client authentication/identification and 683 that client assertion authentication is nothing more than an 684 alternative way for a client to authenticate to the token endpoint 686 o Add examples to Sections 2.1 and 2.2 688 o Update references 690 draft-ietf-oauth-saml2-bearer-13 692 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 693 -28 695 o Changed "Description" to "Specification Document" in both 696 registration requests in IANA Considerations per changes to the 697 template in ietf-oauth-urn-sub-ns(-03) 699 o Added "(or an acceptable alias)" so that it's in both sentences 700 about Recipient and the token endpoint URL so there's no ambiguity 702 o Update area and workgroup (now Security and OAuth was Internet and 703 nothing) 705 draft-ietf-oauth-saml2-bearer-12 707 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 708 draft-ietf-oauth-assertions from -02 to -03 710 draft-ietf-oauth-saml2-bearer-11 712 o Removed text about limited lifetime access tokens and the SHOULD 713 NOT on issuing refresh tokens. The text was moved to 714 draft-ietf-oauth-assertions-02 and somewhat modified per 715 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 717 o Fixed typo/missing word per 718 http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. 720 o Added Terminology section. 722 draft-ietf-oauth-saml2-bearer-10 724 o fix a spelling mistake 726 draft-ietf-oauth-saml2-bearer-09 728 o Attempt to address an ambiguity around validation requirements 729 when the Conditions element contain a NotOnOrAfter and 730 SubjectConfirmation/SubjectConfirmationData does too. Basically 731 it needs to have at least one bearer SubjectConfirmation element 732 but that element can omit SubjectConfirmationData, if Conditions 733 has an expiry on it. Otherwise, a valid SubjectConfirmation must 734 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 735 And any SubjectConfirmationData that has those elements needs to 736 have them checked. 738 o clarified that AudienceRestriction is under Conditions (even 739 though it's implied by schema) 741 o fix a typo 743 draft-ietf-oauth-saml2-bearer-08 745 o fix some typos 747 draft-ietf-oauth-saml2-bearer-07 749 o update reference from draft-campbell-oauth-urn-sub-ns to 750 draft-ietf-oauth-urn-sub-ns 752 o Updated to reference draft-ietf-oauth-v2-20 754 draft-ietf-oauth-saml2-bearer-06 756 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 758 draft-ietf-oauth-saml2-bearer-05 760 o Allow for subject confirmation data to be optional when Conditions 761 contain audience and NotOnOrAfter 763 o Rework most of the spec to profile draft-ietf-oauth-assertions for 764 both authn and authz including (but not limited to): 766 * remove requirement for issuer to be 767 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 769 * change wording on Subject requirements 771 o using a MAY, explicitly say that the Audience can be token 772 endpoint URL of the authorization server 774 o Change title to be more generic (allowing for client authn too) 776 o added client authentication to the abstract 778 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 779 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 781 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 783 o remove scope parameter as it is defined in 784 http://tools.ietf.org/html/draft-ietf-oauth-assertions 786 o remove assertion param registration because it [should] be in 787 http://tools.ietf.org/html/draft-ietf-oauth-assertions 789 o fix typo(s) and update/add references 791 draft-ietf-oauth-saml2-bearer-04 793 o Changed the grant_type URI from 794 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 795 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 796 assertion from the path. Recent versions of draft-ietf-oauth-v2 797 no longer refer to extension grants using the word assertion so 798 this URI is more reflective of that. It also more closely aligns 799 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 800 is "http://oauth.net/grant_type/jwt/1.0/bearer". 802 o Added "case sensitive" to scope definition to align with 803 draft-ietf-oauth-v2-15/16. 805 o Updated to reference draft-ietf-oauth-v2-16 807 draft-ietf-oauth-saml2-bearer-03 809 o Cleanup of some editorial issues. 811 draft-ietf-oauth-saml2-bearer-02 813 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 814 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 815 really inherited by this spec anymore) 817 o Change definition of the assertion parameter to be more generally 818 applicable per the suggestion near the end of 819 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 821 o Editorial changes based on feedback 823 draft-ietf-oauth-saml2-bearer-01 825 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 826 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 828 o Update wording in Introduction to talk about extension grant types 829 rather than the assertion grant type which is a term no longer 830 used in OAuth 2.0 832 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 833 progress 835 o Update Parameter Registration Request to use similar terms as 836 draft-ietf-oauth-v2-12 and remove Related information part 838 o Add some text giving discretion to AS on rejecting assertions with 839 unreasonably long validity window. 841 draft-ietf-oauth-saml2-bearer-00 843 o Added Parameter Registration Request for "assertion" to IANA 844 Considerations. 846 o Changed document name to draft-ietf-oauth-saml2-bearer in 847 anticipation of becoming an OAUTH WG item. 849 o Attempt to move the entire definition of the 'assertion' parameter 850 into this draft (it will no longer be defined in OAuth 2 Protocol 851 Framework). 853 draft-campbell-oauth-saml-01 855 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 856 from -10 to -11. 858 o Updated examples. 860 o Relaxed processing rules to allow for more than one 861 SubjectConfirmation element. 863 o Removed the 'MUST NOT contain a NotBefore attribute' on 864 SubjectConfirmationData. 866 o Relaxed wording that ties the subject of the Assertion to the 867 resource owner. 869 o Added some wording about identifying the client when the subject 870 hasn't directly authenticated including an informative reference 871 to SAML V2.0 Condition for Delegation Restriction. 873 o Added a few examples to the language about verifying that the 874 Assertion is valid in all other respects. 876 o Added some wording to the introduction about the similarities to 877 Web SSO in the format and processing rules 879 o Changed the grant_type (was assertion_type) URI from 880 http://oauth.net/assertion_type/saml/2.0/bearer to 881 http://oauth.net/grant_type/assertion/saml/2.0/bearer 883 o Changed title to include "Grant Type" in it. 885 o Editorial updates based on feedback from the WG and others 886 (including capitalization of Assertion when referring to SAML). 888 draft-campbell-oauth-saml-00 890 o Initial I-D 892 Authors' Addresses 894 Brian Campbell 895 Ping Identity 897 Email: brian.d.campbell@gmail.com 899 Chuck Mortimore 900 Salesforce.com 902 Email: cmortimore@salesforce.com 904 Michael B. Jones 905 Microsoft 907 Email: mbj@microsoft.com 908 URI: http://self-issued.info/