idnits 2.17.1 draft-ietf-oauth-saml2-bearer-15.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 7, 2012) is 4188 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) == Outdated reference: A later version (-18) exists of draft-ietf-oauth-assertions-06 ** Downref: Normative reference to an Informational RFC: RFC 6755 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 11, 2013 Salesforce 6 November 7, 2012 8 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-15 11 Abstract 13 This specification defines the use of a SAML 2.0 Bearer Assertion as 14 a means for requesting an OAuth 2.0 access token as well as for use 15 as a means of client authentication. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 11, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 55 2.1. Using SAML Assertions as Authorization Grants . . . . . . 4 56 2.2. Using SAML Assertions for Client Authentication . . . . . 5 57 3. Assertion Format and Processing Requirements . . . . . . . . . 6 58 3.1. Authorization Grant Processing . . . . . . . . . . . . . . 8 59 3.2. Client Authentication Processing . . . . . . . . . . . . . 8 60 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 9 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6.1. Sub-Namespace Registration of 64 urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10 65 6.2. Sub-Namespace Registration of 66 urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 10 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 71 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 The Security Assertion Markup Language (SAML) 2.0 77 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 78 identity and security information to be shared across security 79 domains. The SAML specification, while primarily targeted at 80 providing cross domain Web browser single sign-on, was also designed 81 to be modular and extensible to facilitate use in other contexts. 83 The Assertion, an XML security token, is a fundamental construct of 84 SAML that is often adopted for use in other protocols and 85 specifications. An Assertion is generally issued by an identity 86 provider and consumed by a service provider who relies on its content 87 to identify the Assertion's subject for security related purposes. 89 The OAuth 2.0 Authorization Protocol [RFC6749] provides a method for 90 making authenticated HTTP requests to a resource using an access 91 token. Access tokens are issued to third-party clients by an 92 authorization server (AS) with the (sometimes implicit) approval of 93 the resource owner. In OAuth, an authorization grant is an abstract 94 term used to describe intermediate credentials that represent the 95 resource owner authorization. An authorization grant is used by the 96 client to obtain an access token. Several authorization grant types 97 are defined to support a wide range of client types and user 98 experiences. OAuth also allows for the definition of new extension 99 grant types to support additional clients or to provide a bridge 100 between OAuth and other trust frameworks. Finally, OAuth allows the 101 definition of additional authentication mechanisms to be used by 102 clients when interacting with the authorization server. 104 The OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions] is an 105 abstract extension to OAuth 2.0 that provides a general framework for 106 the use of Assertions as client credentials and/or authorization 107 grants with OAuth 2.0. This specification profiles the OAuth 2.0 108 Assertion Profile [I-D.ietf-oauth-assertions] to define an extension 109 grant type that uses a SAML 2.0 Bearer Assertion to request an OAuth 110 2.0 access token as well as for use as client credentials. The 111 format and processing rules for the SAML Assertion defined in this 112 specification are intentionally similar, though not identical, to 113 those in the Web Browser SSO Profile defined in SAML Profiles 114 [OASIS.saml-profiles-2.0-os]. This specification is reusing, to the 115 extent reasonable, concepts and patterns from that well-established 116 Profile. 118 This document defines how a SAML Assertion can be used to request an 119 access token when a client wishes to utilize an existing trust 120 relationship, expressed through the semantics of (and digital 121 signature calculated over) the SAML Assertion, without a direct user 122 approval step at the authorization server. It also defines how a 123 SAML Assertion can be used as a client authentication mechanism. The 124 use of an Assertion for client authentication is orthogonal to and 125 separable from using an Assertion as an authorization grant. They 126 can be used either in combination or separately. Client assertion 127 authentication is nothing more than an alternative way for a client 128 to authenticate to the token endpoint and must be used in conjunction 129 with some grant type to form a complete and meaningful protocol 130 request. Assertion authorization grants may be used with or without 131 client authentication or identification. Whether or not client 132 authentication is needed in conjunction with an assertion 133 authorization grant, as well as the supported types of client 134 authentication, are policy decisions at the discretion of the 135 authorization server. 137 The process by which the client obtains the SAML Assertion, prior to 138 exchanging it with the authorization server or using it for client 139 authentication, is out of scope. 141 1.1. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 Unless otherwise noted, all the protocol parameter names and values 148 are case sensitive. 150 1.2. Terminology 152 All terms are as defined in The OAuth 2.0 Authorization Protocol 153 [RFC6749], OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions], 154 and Security Assertion Markup Language (SAML) 2.0 155 [OASIS.saml-core-2.0-os]. 157 2. HTTP Parameter Bindings for Transporting Assertions 159 The OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions] defines 160 generic HTTP parameters for transporting Assertions during 161 interactions with a token endpoint. This section defines the values 162 of those parameters for use with SAML 2.0 Bearer Assertions. 164 2.1. Using SAML Assertions as Authorization Grants 166 To use a SAML Bearer Assertion as an authorization grant, use the 167 following parameter values and encodings. 169 The value of the "grant_type" parameter MUST be 170 "urn:ietf:params:oauth:grant-type:saml2-bearer". 172 The value of the "assertion" parameter MUST contain a single SAML 2.0 173 Assertion. The SAML Assertion XML data MUST be encoded using 174 base64url, where the encoding adheres to the definition in Section 5 175 of RFC4648 [RFC4648] and where the padding bits are set to zero. To 176 avoid the need for subsequent encoding steps (by "application/ 177 x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the 178 base64url encoded data SHOULD NOT be line wrapped and pad characters 179 ("=") SHOULD NOT be included. 181 The following non-normative example demonstrates an Access Token 182 Request with an assertion as an authorization grant (with extra line 183 breaks for display purposes only): 185 POST /token.oauth2 HTTP/1.1 186 Host: as.example.com 187 Content-Type: application/x-www-form-urlencoded 189 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 190 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 192 2.2. Using SAML Assertions for Client Authentication 194 To use a SAML Bearer Assertion for client authentication, use the 195 following parameter values and encodings. 197 The value of the "client_assertion_type" parameter MUST be 198 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer". 200 The value of the "client_assertion" parameter MUST contain a single 201 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 202 using base64url, where the encoding adheres to the definition in 203 Section 5 of RFC4648 [RFC4648] and where the padding bits are set to 204 zero. To avoid the need for subsequent encoding steps (by 205 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 206 example), the base64url encoded data SHOULD NOT be line wrapped and 207 pad characters ("=") SHOULD NOT be included. 209 The following non-normative example demonstrates a client 210 authenticating using an assertion during the presentation of an 211 authorization code grant in an Access Token Request (with extra line 212 breaks for display purposes only): 214 POST /token.oauth2 HTTP/1.1 215 Host: as.example.com 216 Content-Type: application/x-www-form-urlencoded 218 grant_type=authorization_code& 219 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 220 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 221 %3Aclient-assertion-type%3Asaml2-bearer& 222 client_assertion=PHNhbW...[omitted for brevity]...ZT 224 3. Assertion Format and Processing Requirements 226 In order to issue an access token response as described in The OAuth 227 2.0 Authorization Protocol [RFC6749] or to rely on an Assertion for 228 client authentication, the authorization server MUST validate the 229 Assertion according to the criteria below. Application of additional 230 restrictions and policy are at the discretion of the authorization 231 server. 233 o The Assertion's element MUST contain a unique identifier 234 for the entity that issued the Assertion. 236 o The Assertion MUST contain element with an 237 element with an element 238 containing a URI reference that identifies the authorization 239 server, or the service provider SAML entity of its controlling 240 domain, as an intended audience. The token endpoint URL of the 241 authorization server MAY be used as an acceptable value for an 242 element. The authorization server MUST verify that it 243 is an intended audience for the Assertion. 245 o The Assertion MUST contain a element. The subject MAY 246 identify the resource owner for whom the access token is being 247 requested. For client authentication, the Subject MUST be the 248 "client_id" of the OAuth client. When using an Assertion as an 249 authorization grant, the Subject SHOULD identify an authorized 250 accessor for whom the access token is being requested (typically 251 the resource owner, or an authorized delegate). Additional 252 information identifying the subject/principal of the transaction 253 MAY be included in an . 255 o The Assertion MUST have an expiry that limits the time window 256 during which it can be used. The expiry can be expressed either 257 as the NotOnOrAfter attribute of the element or as 258 the NotOnOrAfter attribute of a suitable 259 element. 261 o The element MUST contain at least one 262 element that allows the authorization server 263 to confirm it as a Bearer Assertion. Such a 264 element MUST have a Method attribute with a value of 265 "urn:oasis:names:tc:SAML:2.0:cm:bearer". The 266 element MUST contain a 267 element, unless the Assertion has a 268 suitable NotOnOrAfter attribute on the element, in 269 which case the element MAY be omitted. 270 When present, the element MUST have a 271 Recipient attribute with a value indicating the token endpoint URL 272 of the authorization server (or an acceptable alias). The 273 authorization server MUST verify that the value of the Recipient 274 attribute matches the token endpoint URL (or an acceptable alias) 275 to which the Assertion was delivered. The 276 element MUST have a NotOnOrAfter 277 attribute that limits the window during which the Assertion can be 278 confirmed. The element MAY also contain 279 an Address attribute limiting the client address from which the 280 Assertion can be delivered. Verification of the Address is at the 281 discretion of the authorization server. 283 o The authorization server MUST verify that the NotOnOrAfter instant 284 has not passed, subject to allowable clock skew between systems. 285 An invalid NotOnOrAfter instant on the element 286 invalidates the entire Assertion. An invalid NotOnOrAfter instant 287 on a element only invalidates the 288 individual . The authorization server MAY 289 reject Assertions with a NotOnOrAfter instant that is unreasonably 290 far in the future. The authorization server MAY ensure that 291 Bearer Assertions are not replayed, by maintaining the set of used 292 ID values for the length of time for which the Assertion would be 293 considered valid based on the applicable NotOnOrAfter instant. 295 o If the Assertion issuer authenticated the subject, the Assertion 296 SHOULD contain a single representing that 297 authentication event. 299 o If the Assertion was issued with the intention that the presenter 300 act autonomously on behalf of the subject, an 301 SHOULD NOT be included. The presenter SHOULD be identified in the 302 or similar element, the element, or 303 by other available means like [OASIS.saml-deleg-cs]. 305 o Other statements, in particular elements, MAY 306 be included in the Assertion. 308 o The Assertion MUST be digitally signed by the issuer and the 309 authorization server MUST verify the signature. 311 o Encrypted elements MAY appear in place of their plain text 312 counterparts as defined in [OASIS.saml-core-2.0-os]. 314 o The authorization server MUST verify that the Assertion is valid 315 in all other respects per [OASIS.saml-core-2.0-os], such as (but 316 not limited to) evaluating all content within the Conditions 317 element including the NotOnOrAfter and NotBefore attributes, 318 rejecting unknown condition types, etc. 320 3.1. Authorization Grant Processing 322 If present, the authorization server MUST also validate the client 323 credentials. 325 If the Assertion is not valid, or its subject confirmation 326 requirements cannot be met, the authorization server MUST construct 327 an error response as defined in OAuth 2.0 [RFC6749]. The value of 328 the "error" parameter MUST be the "invalid_grant" error code. The 329 authorization server MAY include additional information regarding the 330 reasons the Assertion was considered invalid using the 331 "error_description" or "error_uri" parameters. 333 For example: 335 HTTP/1.1 400 Bad Request 336 Content-Type: application/json 337 Cache-Control: no-store 339 { 340 "error":"invalid_grant", 341 "error_description":"Audience validation failed" 342 } 344 3.2. Client Authentication Processing 346 If the client Assertion is not valid, or its subject confirmation 347 requirements cannot be met, the authorization server MUST construct 348 an error response as defined in OAuth 2.0 [RFC6749]. The value of 349 the "error" parameter MUST be the "invalid_client" error code. The 350 authorization server MAY include additional information regarding the 351 reasons the Assertion was considered invalid using the 352 "error_description" or "error_uri" parameters. 354 4. Authorization Grant Example 356 Though non-normative, the following examples illustrate what a 357 conforming Assertion and access token request would look like. 359 Below is an example SAML 2.0 Assertion (whitespace formatting is for 360 display purposes only): 362 366 https://saml-idp.example.com 367 368 [...omitted for brevity...] 369 370 371 373 brian@example.com 374 375 377 380 381 382 383 384 https://saml-sp.example.net 385 386 387 388 389 390 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 391 392 393 394 396 Figure 1: Example SAML 2.0 Assertion 398 To present the Assertion shown in the previous example as part of an 399 access token request, for example, the client might make the 400 following HTTPS request (with extra line breaks for display purposes 401 only): 403 POST /token.oauth2 HTTP/1.1 404 Host: authz.example.net 405 Content-Type: application/x-www-form-urlencoded 407 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 408 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 409 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 411 Figure 2: Example Request 413 5. Security Considerations 415 No additional security considerations apply beyond those described 416 within The OAuth 2.0 Authorization Protocol [RFC6749], the OAuth 2.0 417 Assertion Profile [I-D.ietf-oauth-assertions], and in the Security 418 and Privacy Considerations for the OASIS Security Assertion Markup 419 Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 421 6. IANA Considerations 423 6.1. Sub-Namespace Registration of 424 urn:ietf:params:oauth:grant-type:saml2-bearer 426 This is a request to IANA to please register the value 427 "grant-type:saml2-bearer" in the registry urn:ietf:params:oauth 428 established in An IETF URN Sub-Namespace for OAuth [RFC6755]. 430 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 432 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 433 OAuth 2.0 435 o Change controller: IETF 437 o Specification Document: [[this document]] 439 6.2. Sub-Namespace Registration of 440 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 442 This is a request to IANA to please register the value 443 "client-assertion-type:saml2-bearer" in the registry 444 urn:ietf:params:oauth established in An IETF URN Sub-Namespace for 445 OAuth [RFC6755]. 447 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 449 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 450 Client Authentication 452 o Change controller: IETF 454 o Specification Document: [[this document]] 456 7. References 458 7.1. Normative References 460 [I-D.ietf-oauth-assertions] 461 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 462 "Assertion Framework for OAuth 2.0", 463 draft-ietf-oauth-assertions-06 (work in progress), 464 September 2012. 466 [OASIS.saml-core-2.0-os] 467 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 468 "Assertions and Protocol for the OASIS Security Assertion 469 Markup Language (SAML) V2.0", OASIS Standard saml-core- 470 2.0-os, March 2005. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 476 Encodings", RFC 4648, October 2006. 478 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 479 RFC 6749, October 2012. 481 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 482 for OAuth", RFC 6755, October 2012. 484 7.2. Informative References 486 [OASIS.saml-deleg-cs] 487 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 488 Restriction", Nov 2009. 490 [OASIS.saml-profiles-2.0-os] 491 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 492 P., Philpott, R., and E. Maler, "Profiles for the OASIS 493 Security Assertion Markup Language (SAML) V2.0", OASIS 494 Standard OASIS.saml-profiles-2.0-os, March 2005. 496 [OASIS.saml-sec-consider-2.0-os] 497 Hirsch, F., Philpott, R., and E. Maler, "Security and 498 Privacy Considerations for the OASIS Security Markup 499 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 500 2.0-os, March 2005. 502 [W3C.REC-html401-19991224] 503 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 504 Specification", World Wide Web Consortium 505 Recommendation REC-html401-19991224, December 1999, 506 . 508 Appendix A. Acknowledgements 510 The following people contributed wording and concepts to this 511 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 512 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 513 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B. 514 Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh 515 Bhatnagar. 517 Appendix B. Document History 519 [[ to be removed by RFC editor before publication as an RFC ]] 521 draft-ietf-oauth-saml2-bearer-15 523 o Reference RFC 6749 and RFC 6755. 525 o Update draft-ietf-oauth-assertions reference to -06. 527 o Remove extraneous word per 528 http://www.ietf.org/mail-archive/web/oauth/current/msg10055.html 530 draft-ietf-oauth-saml2-bearer-14 532 o Add more text to intro explaining that an assertion grant type can 533 be used with or without client authentication/identification and 534 that client assertion authentication is nothing more than an 535 alternative way for a client to authenticate to the token endpoint 537 o Add examples to Sections 2.1 and 2.2 539 o Update references 541 draft-ietf-oauth-saml2-bearer-13 543 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 544 -28 546 o Changed "Description" to "Specification Document" in both 547 registration requests in IANA Considerations per changes to the 548 template in ietf-oauth-urn-sub-ns(-03) 550 o Added "(or an acceptable alias)" so that it's in both sentences 551 about Recipient and the token endpoint URL so there's no ambiguity 553 o Update area and workgroup (now Security and OAuth was Internet and 554 nothing) 556 draft-ietf-oauth-saml2-bearer-12 558 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 559 draft-ietf-oauth-assertions from -02 to -03 561 draft-ietf-oauth-saml2-bearer-11 563 o Removed text about limited lifetime access tokens and the SHOULD 564 NOT on issuing refresh tokens. The text was moved to 565 draft-ietf-oauth-assertions-02 and somewhat modified per 566 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 568 o Fixed typo/missing word per 569 http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. 571 o Added Terminology section. 573 draft-ietf-oauth-saml2-bearer-10 575 o fix a spelling mistake 577 draft-ietf-oauth-saml2-bearer-09 579 o Attempt to address an ambiguity around validation requirements 580 when the Conditions element contain a NotOnOrAfter and 581 SubjectConfirmation/SubjectConfirmationData does too. Basically 582 it needs to have at least one bearer SubjectConfirmation element 583 but that element can omit SubjectConfirmationData, if Conditions 584 has an expiry on it. Otherwise, a valid SubjectConfirmation must 585 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 586 And any SubjectConfirmationData that has those elements needs to 587 have them checked. 589 o clarified that AudienceRestriction is under Conditions (even 590 though it's implied by schema) 592 o fix a typo 594 draft-ietf-oauth-saml2-bearer-08 596 o fix some typos 598 draft-ietf-oauth-saml2-bearer-07 600 o update reference from draft-campbell-oauth-urn-sub-ns to 601 draft-ietf-oauth-urn-sub-ns 603 o Updated to reference draft-ietf-oauth-v2-20 605 draft-ietf-oauth-saml2-bearer-06 607 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 609 draft-ietf-oauth-saml2-bearer-05 611 o Allow for subject confirmation data to be optional when Conditions 612 contain audience and NotOnOrAfter 614 o Rework most of the spec to profile draft-ietf-oauth-assertions for 615 both authn and authz including (but not limited to): 617 * remove requirement for issuer to be 618 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 620 * change wording on Subject requirements 622 o using a MAY, explicitly say that the Audience can be token 623 endpoint URL of the authorization server 625 o Change title to be more generic (allowing for client authn too) 627 o added client authentication to the abstract 629 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 630 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 632 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 634 o remove scope parameter as it is defined in 635 http://tools.ietf.org/html/draft-ietf-oauth-assertions 637 o remove assertion param registration because it [should] be in 638 http://tools.ietf.org/html/draft-ietf-oauth-assertions 640 o fix typo(s) and update/add references 642 draft-ietf-oauth-saml2-bearer-04 644 o Changed the grant_type URI from 645 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 646 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 647 assertion from the path. Recent versions of draft-ietf-oauth-v2 648 no longer refer to extension grants using the word assertion so 649 this URI is more reflective of that. It also more closely aligns 650 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 651 is "http://oauth.net/grant_type/jwt/1.0/bearer". 653 o Added "case sensitive" to scope definition to align with 654 draft-ietf-oauth-v2-15/16. 656 o Updated to reference draft-ietf-oauth-v2-16 658 draft-ietf-oauth-saml2-bearer-03 660 o Cleanup of some editorial issues. 662 draft-ietf-oauth-saml2-bearer-02 664 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 665 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 666 really inherited by this spec anymore) 668 o Change definition of the assertion parameter to be more generally 669 applicable per the suggestion near the end of 670 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 672 o Editorial changes based on feedback 674 draft-ietf-oauth-saml2-bearer-01 676 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 677 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 679 o Update wording in Introduction to talk about extension grant types 680 rather than the assertion grant type which is a term no longer 681 used in OAuth 2.0 683 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 684 progress 686 o Update Parameter Registration Request to use similar terms as 687 draft-ietf-oauth-v2-12 and remove Related information part 689 o Add some text giving discretion to AS on rejecting assertions with 690 unreasonably long validity window. 692 draft-ietf-oauth-saml2-bearer-00 694 o Added Parameter Registration Request for "assertion" to IANA 695 Considerations. 697 o Changed document name to draft-ietf-oauth-saml2-bearer in 698 anticipation of becoming an OAUTH WG item. 700 o Attempt to move the entire definition of the 'assertion' parameter 701 into this draft (it will no longer be defined in OAuth 2 Protocol 702 Framework). 704 draft-campbell-oauth-saml-01 706 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 707 from -10 to -11. 709 o Updated examples. 711 o Relaxed processing rules to allow for more than one 712 SubjectConfirmation element. 714 o Removed the 'MUST NOT contain a NotBefore attribute' on 715 SubjectConfirmationData. 717 o Relaxed wording that ties the subject of the Assertion to the 718 resource owner. 720 o Added some wording about identifying the client when the subject 721 hasn't directly authenticated including an informative reference 722 to SAML V2.0 Condition for Delegation Restriction. 724 o Added a few examples to the language about verifying that the 725 Assertion is valid in all other respects. 727 o Added some wording to the introduction about the similarities to 728 Web SSO in the format and processing rules 730 o Changed the grant_type (was assertion_type) URI from 731 http://oauth.net/assertion_type/saml/2.0/bearer to 732 http://oauth.net/grant_type/assertion/saml/2.0/bearer 734 o Changed title to include "Grant Type" in it. 736 o Editorial updates based on feedback from the WG and others 737 (including capitalization of Assertion when referring to SAML). 739 draft-campbell-oauth-saml-00 741 o Initial I-D 743 Authors' Addresses 745 Brian Campbell 746 Ping Identity Corp. 748 Email: brian.d.campbell@gmail.com 750 Chuck Mortimore 751 Salesforce.com 753 Email: cmortimore@salesforce.com