idnits 2.17.1 draft-ietf-oauth-saml2-bearer-14.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 (September 14, 2012) is 4241 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-05 ** Downref: Normative reference to an Informational draft: draft-ietf-oauth-urn-sub-ns (ref. 'I-D.ietf-oauth-urn-sub-ns') 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: March 18, 2013 Salesforce 6 September 14, 2012 8 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-14 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 March 18, 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 . 11 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-oauth-v2] provides a 90 method for making authenticated HTTP requests to a resource using an 91 access 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 [I-D.ietf-oauth-v2], OAuth 2.0 Assertion Profile 154 [I-D.ietf-oauth-assertions], and Security Assertion Markup Language 155 (SAML) 2.0 [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 grant, use 195 the 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 [I-D.ietf-oauth-v2] or to rely on an 228 Assertion for client authentication, the authorization server MUST 229 validate the Assertion according to the criteria below. Application 230 of additional restrictions and policy are at the discretion of the 231 authorization 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 [I-D.ietf-oauth-v2]. The 328 value of the "error" parameter MUST be the "invalid_grant" error 329 code. The authorization server MAY include additional information 330 regarding the 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 [I-D.ietf-oauth-v2]. The 349 value of the "error" parameter MUST be the "invalid_client" error 350 code. The authorization server MAY include additional information 351 regarding the 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 [I-D.ietf-oauth-v2], the 417 OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions], and in the 418 Security and Privacy Considerations for the OASIS Security Assertion 419 Markup 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 429 [I-D.ietf-oauth-urn-sub-ns]. 431 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 433 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 434 OAuth 2.0 436 o Change controller: IETF 438 o Specification Document: [[this document]] 440 6.2. Sub-Namespace Registration of 441 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 443 This is a request to IANA to please register the value 444 "client-assertion-type:saml2-bearer" in the registry 445 urn:ietf:params:oauth established in An IETF URN Sub-Namespace for 446 OAuth [I-D.ietf-oauth-urn-sub-ns]. 448 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 450 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 451 Client Authentication 453 o Change controller: IETF 455 o Specification Document: [[this document]] 457 7. References 459 7.1. Normative References 461 [I-D.ietf-oauth-assertions] 462 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 463 "Assertion Framework for OAuth 2.0", 464 draft-ietf-oauth-assertions-05 (work in progress), 465 September 2012. 467 [I-D.ietf-oauth-urn-sub-ns] 468 Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 469 for OAuth", draft-ietf-oauth-urn-sub-ns-06 (work in 470 progress), July 2012. 472 [I-D.ietf-oauth-v2] 473 Hardt, D., "The OAuth 2.0 Authorization Framework", 474 draft-ietf-oauth-v2-31 (work in progress), August 2012. 476 [OASIS.saml-core-2.0-os] 477 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 478 "Assertions and Protocol for the OASIS Security Assertion 479 Markup Language (SAML) V2.0", OASIS Standard saml-core- 480 2.0-os, March 2005. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 486 Encodings", RFC 4648, October 2006. 488 7.2. Informative References 490 [OASIS.saml-deleg-cs] 491 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 492 Restriction", Nov 2009. 494 [OASIS.saml-profiles-2.0-os] 495 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 496 P., Philpott, R., and E. Maler, "Profiles for the OASIS 497 Security Assertion Markup Language (SAML) V2.0", OASIS 498 Standard OASIS.saml-profiles-2.0-os, March 2005. 500 [OASIS.saml-sec-consider-2.0-os] 501 Hirsch, F., Philpott, R., and E. Maler, "Security and 502 Privacy Considerations for the OASIS Security Markup 503 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 504 2.0-os, March 2005. 506 [W3C.REC-html401-19991224] 507 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 508 Specification", World Wide Web Consortium 509 Recommendation REC-html401-19991224, December 1999, 510 . 512 Appendix A. Acknowledgements 514 The following people contributed wording and concepts to this 515 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 516 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 517 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B. 518 Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh 519 Bhatnagar. 521 Appendix B. Document History 523 [[ to be removed by RFC editor before publication as an RFC ]] 525 draft-ietf-oauth-saml2-bearer-14 527 o Add more text to intro explaining that an assertion grant type can 528 be used with or without client authentication/identification and 529 that client assertion authentication is nothing more than an 530 alternative way for a client to authenticate to the token endpoint 532 o Add examples to Sections 2.1 and 2.2 533 o Update references 535 draft-ietf-oauth-saml2-bearer-13 537 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 538 -28 540 o Changed "Description" to "Specification Document" in both 541 registration requests in IANA Considerations per changes to the 542 template in ietf-oauth-urn-sub-ns(-03) 544 o Added "(or an acceptable alias)" so that it's in both sentences 545 about Recipient and the token endpoint URL so there's no ambiguity 547 o Update area and workgroup (now Security and OAuth was Internet and 548 nothing) 550 draft-ietf-oauth-saml2-bearer-12 552 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 553 draft-ietf-oauth-assertions from -02 to -03 555 draft-ietf-oauth-saml2-bearer-11 557 o Removed text about limited lifetime access tokens and the SHOULD 558 NOT on issuing refresh tokens. The text was moved to 559 draft-ietf-oauth-assertions-02 and somewhat modified per 560 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 562 o Fixed typo/missing word per 563 http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. 565 o Added Terminology section. 567 draft-ietf-oauth-saml2-bearer-10 569 o fix a spelling mistake 571 draft-ietf-oauth-saml2-bearer-09 573 o Attempt to address an ambiguity around validation requirements 574 when the Conditions element contain a NotOnOrAfter and 575 SubjectConfirmation/SubjectConfirmationData does too. Basically 576 it needs to have at least one bearer SubjectConfirmation element 577 but that element can omit SubjectConfirmationData, if Conditions 578 has an expiry on it. Otherwise, a valid SubjectConfirmation must 579 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 580 And any SubjectConfirmationData that has those elements needs to 581 have them checked. 583 o clarified that AudienceRestriction is under Conditions (even 584 though it's implied by schema) 586 o fix a typo 588 draft-ietf-oauth-saml2-bearer-08 590 o fix some typos 592 draft-ietf-oauth-saml2-bearer-07 594 o update reference from draft-campbell-oauth-urn-sub-ns to 595 draft-ietf-oauth-urn-sub-ns 597 o Updated to reference draft-ietf-oauth-v2-20 599 draft-ietf-oauth-saml2-bearer-06 601 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 603 draft-ietf-oauth-saml2-bearer-05 605 o Allow for subject confirmation data to be optional when Conditions 606 contain audience and NotOnOrAfter 608 o Rework most of the spec to profile draft-ietf-oauth-assertions for 609 both authn and authz including (but not limited to): 611 * remove requirement for issuer to be 612 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 614 * change wording on Subject requirements 616 o using a MAY, explicitly say that the Audience can be token 617 endpoint URL of the authorization server 619 o Change title to be more generic (allowing for client authn too) 621 o added client authentication to the abstract 623 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 624 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 626 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 627 o remove scope parameter as it is defined in 628 http://tools.ietf.org/html/draft-ietf-oauth-assertions 630 o remove assertion param registration because it [should] be in 631 http://tools.ietf.org/html/draft-ietf-oauth-assertions 633 o fix typo(s) and update/add references 635 draft-ietf-oauth-saml2-bearer-04 637 o Changed the grant_type URI from 638 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 639 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 640 assertion from the path. Recent versions of draft-ietf-oauth-v2 641 no longer refer to extension grants using the word assertion so 642 this URI is more reflective of that. It also more closely aligns 643 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 644 is "http://oauth.net/grant_type/jwt/1.0/bearer". 646 o Added "case sensitive" to scope definition to align with 647 draft-ietf-oauth-v2-15/16. 649 o Updated to reference draft-ietf-oauth-v2-16 651 draft-ietf-oauth-saml2-bearer-03 653 o Cleanup of some editorial issues. 655 draft-ietf-oauth-saml2-bearer-02 657 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 658 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 659 really inherited by this spec anymore) 661 o Change definition of the assertion parameter to be more generally 662 applicable per the suggestion near the end of 663 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 665 o Editorial changes based on feedback 667 draft-ietf-oauth-saml2-bearer-01 669 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 670 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 672 o Update wording in Introduction to talk about extension grant types 673 rather than the assertion grant type which is a term no longer 674 used in OAuth 2.0 676 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 677 progress 679 o Update Parameter Registration Request to use similar terms as 680 draft-ietf-oauth-v2-12 and remove Related information part 682 o Add some text giving discretion to AS on rejecting assertions with 683 unreasonably long validity window. 685 draft-ietf-oauth-saml2-bearer-00 687 o Added Parameter Registration Request for "assertion" to IANA 688 Considerations. 690 o Changed document name to draft-ietf-oauth-saml2-bearer in 691 anticipation of becoming an OAUTH WG item. 693 o Attempt to move the entire definition of the 'assertion' parameter 694 into this draft (it will no longer be defined in OAuth 2 Protocol 695 Framework). 697 draft-campbell-oauth-saml-01 699 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 700 from -10 to -11. 702 o Updated examples. 704 o Relaxed processing rules to allow for more than one 705 SubjectConfirmation element. 707 o Removed the 'MUST NOT contain a NotBefore attribute' on 708 SubjectConfirmationData. 710 o Relaxed wording that ties the subject of the Assertion to the 711 resource owner. 713 o Added some wording about identifying the client when the subject 714 hasn't directly authenticated including an informative reference 715 to SAML V2.0 Condition for Delegation Restriction. 717 o Added a few examples to the language about verifying that the 718 Assertion is valid in all other respects. 720 o Added some wording to the introduction about the similarities to 721 Web SSO in the format and processing rules 723 o Changed the grant_type (was assertion_type) URI from 724 http://oauth.net/assertion_type/saml/2.0/bearer to 725 http://oauth.net/grant_type/assertion/saml/2.0/bearer 727 o Changed title to include "Grant Type" in it. 729 o Editorial updates based on feedback from the WG and others 730 (including capitalization of Assertion when referring to SAML). 732 draft-campbell-oauth-saml-00 734 o Initial I-D 736 Authors' Addresses 738 Brian Campbell 739 Ping Identity Corp. 741 Email: brian.d.campbell@gmail.com 743 Chuck Mortimore 744 Salesforce.com 746 Email: cmortimore@salesforce.com