idnits 2.17.1 draft-ietf-oauth-saml2-bearer-12.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 (May 3, 2012) is 4373 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-03 == Outdated reference: A later version (-06) exists of draft-ietf-oauth-urn-sub-ns-02 ** Downref: Normative reference to an Informational draft: draft-ietf-oauth-urn-sub-ns (ref. 'I-D.ietf-oauth-urn-sub-ns') == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-26 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 B. Campbell, Ed. 3 Internet-Draft Ping Identity 4 Intended status: Standards Track C. Mortimore 5 Expires: November 4, 2012 Salesforce 6 May 3, 2012 8 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-12 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 November 4, 2012. 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 . . . . . . . . . 5 58 3.1. Authorization Grant Processing . . . . . . . . . . . . . . 7 59 3.2. Client Authentication Processing . . . . . . . . . . . . . 8 60 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 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 and 125 separable from using an Assertion as an authorization grant and the 126 two can be used either in combination or in isolation. 128 The process by which the client obtains the SAML Assertion, prior to 129 exchanging it with the authorization server or using it for client 130 authentication, is out of scope. 132 1.1. Notational Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 Unless otherwise noted, all the protocol parameter names and values 139 are case sensitive. 141 1.2. Terminology 143 All terms are as defined in The OAuth 2.0 Authorization Protocol 144 [I-D.ietf-oauth-v2], OAuth 2.0 Assertion Profile 145 [I-D.ietf-oauth-assertions], and Security Assertion Markup Language 146 (SAML) 2.0 [OASIS.saml-core-2.0-os]. 148 2. HTTP Parameter Bindings for Transporting Assertions 150 The OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions] defines 151 generic HTTP parameters for transporting Assertions during 152 interactions with a token endpoint. This section defines the values 153 of those parameters for use with SAML 2.0 Bearer Assertions. 155 2.1. Using SAML Assertions as Authorization Grants 157 To use a SAML Bearer Assertion as an authorization grant, use the 158 following parameter values and encodings. 160 The value of the "grant_type" parameter MUST be 161 "urn:ietf:params:oauth:grant-type:saml2-bearer". 163 The value of the "assertion" parameter MUST contain a single SAML 2.0 164 Assertion. The SAML Assertion XML data MUST be encoded using 165 base64url, where the encoding adheres to the definition in Section 5 166 of RFC4648 [RFC4648] and where the padding bits are set to zero. To 167 avoid the need for subsequent encoding steps (by "application/ 168 x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the 169 base64url encoded data SHOULD NOT be line wrapped and pad characters 170 ("=") SHOULD NOT be included. 172 2.2. Using SAML Assertions for Client Authentication 174 To use a SAML Bearer Assertion for client authentication grant, use 175 the following parameter values and encodings. 177 The value of the "client_assertion_type" parameter MUST be 178 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer". 180 The value of the "client_assertion" parameter MUST contain a single 181 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 182 using base64url, where the encoding adheres to the definition in 183 Section 5 of RFC4648 [RFC4648] and where the padding bits are set to 184 zero. To avoid the need for subsequent encoding steps (by 185 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 186 example), the base64url encoded data SHOULD NOT be line wrapped and 187 pad characters ("=") SHOULD NOT be included. 189 3. Assertion Format and Processing Requirements 191 In order to issue an access token response as described in The OAuth 192 2.0 Authorization Protocol [I-D.ietf-oauth-v2] or to rely on an 193 Assertion for client authentication, the authorization server MUST 194 validate the Assertion according to the criteria below. Application 195 of additional restrictions and policy are at the discretion of the 196 authorization server. 198 o The Assertion's element MUST contain a unique identifier 199 for the entity that issued the Assertion. 201 o The Assertion MUST contain element with an 202 element with an element 203 containing a URI reference that identifies the authorization 204 server, or the service provider SAML entity of its controlling 205 domain, as an intended audience. The token endpoint URL of the 206 authorization server MAY be used as an acceptable value for an 207 element. The authorization server MUST verify that it 208 is an intended audience for the Assertion. 210 o The Assertion MUST contain a element. The subject MAY 211 identify the resource owner for whom the access token is being 212 requested. For client authentication, the Subject MUST be the 213 "client_id" of the OAuth client. When using an Assertion as an 214 authorization grant, the Subject SHOULD identify an authorized 215 accessor for whom the access token is being requested (typically 216 the resource owner, or an authorized delegate). Additional 217 information identifying the subject/principal of the transaction 218 MAY be included in an . 220 o The Assertion MUST have an expiry that limits the time window 221 during which it can be used. The expiry can be expressed either 222 as the NotOnOrAfter attribute of the element or as 223 the NotOnOrAfter attribute of a suitable 224 element. 226 o The element MUST contain at least one 227 element that allows the authorization server 228 to confirm it as a Bearer Assertion. Such a 229 element MUST have a Method attribute with a value of 230 "urn:oasis:names:tc:SAML:2.0:cm:bearer". The 231 element MUST contain a 232 element, unless the Assertion has a 233 suitable NotOnOrAfter attribute on the element, in 234 which case the element MAY be omitted. 235 When present, the element MUST have a 236 Recipient attribute with a value indicating the token endpoint URL 237 of the authorization server. The authorization server MUST verify 238 that the value of the Recipient attribute matches the token 239 endpoint URL (or an acceptable alias) to which the Assertion was 240 delivered. The element MUST have a 241 NotOnOrAfter attribute that limits the window during which the 242 Assertion can be confirmed. The element 243 MAY also contain an Address attribute limiting the client address 244 from which the Assertion can be delivered. Verification of the 245 Address is at the discretion of the authorization server. 247 o The authorization server MUST verify that the NotOnOrAfter instant 248 has not passed, subject to allowable clock skew between systems. 249 An invalid NotOnOrAfter instant on the element 250 invalidates the entire Assertion. An invalid NotOnOrAfter instant 251 on a element only invalidates the 252 individual . The authorization server MAY 253 reject Assertions with a NotOnOrAfter instant that is unreasonably 254 far in the future. The authorization server MAY ensure that 255 Bearer Assertions are not replayed, by maintaining the set of used 256 ID values for the length of time for which the Assertion would be 257 considered valid based on the applicable NotOnOrAfter instant. 259 o If the Assertion issuer authenticated the subject, the Assertion 260 SHOULD contain a single representing that 261 authentication event. 263 o If the Assertion was issued with the intention that the presenter 264 act autonomously on behalf of the subject, an 265 SHOULD NOT be included. The presenter SHOULD be identified in the 266 or similar element, the element, or 267 by other available means like [OASIS.saml-deleg-cs]. 269 o Other statements, in particular elements, MAY 270 be included in the Assertion. 272 o The Assertion MUST be digitally signed by the issuer and the 273 authorization server MUST verify the signature. 275 o Encrypted elements MAY appear in place of their plain text 276 counterparts as defined in [OASIS.saml-core-2.0-os]. 278 o The authorization server MUST verify that the Assertion is valid 279 in all other respects per [OASIS.saml-core-2.0-os], such as (but 280 not limited to) evaluating all content within the Conditions 281 element including the NotOnOrAfter and NotBefore attributes, 282 rejecting unknown condition types, etc. 284 3.1. Authorization Grant Processing 286 If present, the authorization server MUST also validate the client 287 credentials. 289 If the Assertion is not valid, or its subject confirmation 290 requirements cannot be met, the authorization server MUST construct 291 an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The 292 value of the "error" parameter MUST be the "invalid_grant" error 293 code. The authorization server MAY include additional information 294 regarding the reasons the Assertion was considered invalid using the 295 "error_description" or "error_uri" parameters. 297 For example: 299 HTTP/1.1 400 Bad Request 300 Content-Type: application/json 301 Cache-Control: no-store 303 { 304 "error":"invalid_grant", 305 "error_description":"Audience validation failed" 306 } 308 3.2. Client Authentication Processing 310 If the client Assertion is not valid, or its subject confirmation 311 requirements cannot be met, the authorization server MUST construct 312 an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The 313 value of the "error" parameter MUST be the "invalid_client" error 314 code. The authorization server MAY include additional information 315 regarding the reasons the Assertion was considered invalid using the 316 "error_description" or "error_uri" parameters. 318 4. Authorization Grant Example 320 Though non-normative, the following examples illustrate what a 321 conforming Assertion and access token request would look like. 323 Below is an example SAML 2.0 Assertion (whitespace formatting is for 324 display purposes only): 326 330 https://saml-idp.example.com 331 332 [...omitted for brevity...] 333 334 335 337 brian@example.com 338 339 341 344 345 346 347 348 https://saml-sp.example.net 349 350 351 352 353 354 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 355 356 357 358 360 Figure 1: Example SAML 2.0 Assertion 362 To present the Assertion shown in the previous example as part of an 363 access token request, for example, the client might make the 364 following HTTPS request (with line breaks for display purposes only): 366 POST /token.oauth2 HTTP/1.1 367 Host: authz.example.net 368 Content-Type: application/x-www-form-urlencoded 370 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 371 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 372 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 374 Figure 2: Example Request 376 5. Security Considerations 378 No additional security considerations apply beyond those described 379 within The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2], the 380 OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions], and in the 381 Security and Privacy Considerations for the OASIS Security Assertion 382 Markup Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 384 6. IANA Considerations 386 6.1. Sub-Namespace Registration of 387 urn:ietf:params:oauth:grant-type:saml2-bearer 389 This is a request to IANA to please register the value 390 "grant-type:saml2-bearer" in the registry urn:ietf:params:oauth 391 established in An IETF URN Sub-Namespace for OAuth 392 [I-D.ietf-oauth-urn-sub-ns]. 394 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 396 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 397 OAuth 2.0 399 o Change controller: IETF 401 o Description: [[this document]] 403 6.2. Sub-Namespace Registration of 404 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 406 This is a request to IANA to please register the value 407 "client-assertion-type:saml2-bearer" in the registry 408 urn:ietf:params:oauth established in An IETF URN Sub-Namespace for 409 OAuth [I-D.ietf-oauth-urn-sub-ns]. 411 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 413 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 414 Client Authentication 416 o Change controller: IETF 418 o Description: [[this document]] 420 7. References 422 7.1. Normative References 424 [I-D.ietf-oauth-assertions] 425 Jones, M., Campbell, B., and Y. Goland, "OAuth 2.0 426 Assertion Profile", draft-ietf-oauth-assertions-03 (work 427 in progress), May 2012. 429 [I-D.ietf-oauth-urn-sub-ns] 430 Tschofenig, H., "An IETF URN Sub-Namespace for OAuth", 431 draft-ietf-oauth-urn-sub-ns-02 (work in progress), 432 January 2012. 434 [I-D.ietf-oauth-v2] 435 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 436 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 437 in progress), May 2012. 439 [OASIS.saml-core-2.0-os] 440 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 441 "Assertions and Protocol for the OASIS Security Assertion 442 Markup Language (SAML) V2.0", OASIS Standard saml-core- 443 2.0-os, March 2005. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 449 Encodings", RFC 4648, October 2006. 451 7.2. Informative References 453 [OASIS.saml-deleg-cs] 454 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 455 Restriction", Nov 2009. 457 [OASIS.saml-profiles-2.0-os] 458 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 459 P., Philpott, R., and E. Maler, "Profiles for the OASIS 460 Security Assertion Markup Language (SAML) V2.0", OASIS 461 Standard OASIS.saml-profiles-2.0-os, March 2005. 463 [OASIS.saml-sec-consider-2.0-os] 464 Hirsch, F., Philpott, R., and E. Maler, "Security and 465 Privacy Considerations for the OASIS Security Markup 466 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 467 2.0-os, March 2005. 469 [W3C.REC-html401-19991224] 470 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 471 Specification", World Wide Web Consortium 472 Recommendation REC-html401-19991224, December 1999, 473 . 475 Appendix A. Acknowledgements 477 The following people contributed wording and concepts to this 478 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 479 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 480 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B. 481 Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh 482 Bhatnagar. 484 Appendix B. Document History 486 [[ to be removed by RFC editor before publication as an RFC ]] 488 draft-ietf-oauth-saml2-bearer-12 490 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 491 draft-ietf-oauth-assertions from -02 to -03 493 draft-ietf-oauth-saml2-bearer-11 495 o Removed text about limited lifetime access tokens and the SHOULD 496 NOT on issuing refresh tokens. The text was moved to 497 draft-ietf-oauth-assertions-02 and somewhat modified per 498 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 500 o Fixed typo/missing word per 501 http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. 503 o Added Terminology section. 505 draft-ietf-oauth-saml2-bearer-10 507 o fix a spelling mistake 509 draft-ietf-oauth-saml2-bearer-09 511 o Attempt to address an ambiguity around validation requirements 512 when the Conditions element contain a NotOnOrAfter and 513 SubjectConfirmation/SubjectConfirmationData does too. Basically 514 it needs to have at least one bearer SubjectConfirmation element 515 but that element can omit SubjectConfirmationData, if Conditions 516 has an expiry on it. Otherwise, a valid SubjectConfirmation must 517 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 518 And any SubjectConfirmationData that has those elements needs to 519 have them checked. 521 o clarified that AudienceRestriction is under Conditions (even 522 though it's implied by schema) 524 o fix a typo 526 draft-ietf-oauth-saml2-bearer-08 528 o fix some typos 530 draft-ietf-oauth-saml2-bearer-07 532 o update reference from draft-campbell-oauth-urn-sub-ns to 533 draft-ietf-oauth-urn-sub-ns 535 o Updated to reference draft-ietf-oauth-v2-20 537 draft-ietf-oauth-saml2-bearer-06 539 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 541 draft-ietf-oauth-saml2-bearer-05 543 o Allow for subject confirmation data to be optional when Conditions 544 contain audience and NotOnOrAfter 546 o Rework most of the spec to profile draft-ietf-oauth-assertions for 547 both authn and authz including (but not limited to): 549 * remove requirement for issuer to be 550 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 552 * change wording on Subject requirements 554 o using a MAY, explicitly say that the Audience can be token 555 endpoint URL of the authorization server 557 o Change title to be more generic (allowing for client authn too) 559 o added client authentication to the abstract 561 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 562 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 564 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 566 o remove scope parameter as it is defined in 567 http://tools.ietf.org/html/draft-ietf-oauth-assertions 569 o remove assertion param registration because it [should] be in 570 http://tools.ietf.org/html/draft-ietf-oauth-assertions 572 o fix typo(s) and update/add references 574 draft-ietf-oauth-saml2-bearer-04 576 o Changed the grant_type URI from 577 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 578 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 579 assertion from the path. Recent versions of draft-ietf-oauth-v2 580 no longer refer to extension grants using the word assertion so 581 this URI is more reflective of that. It also more closely aligns 582 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 583 is "http://oauth.net/grant_type/jwt/1.0/bearer". 585 o Added "case sensitive" to scope definition to align with 586 draft-ietf-oauth-v2-15/16. 588 o Updated to reference draft-ietf-oauth-v2-16 590 draft-ietf-oauth-saml2-bearer-03 592 o Cleanup of some editorial issues. 594 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 595 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 596 really inherited by this spec anymore) 598 o Change definition of the assertion parameter to be more generally 599 applicable per the suggestion near the end of 600 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 602 o Editorial changes based on feedback 604 draft-ietf-oauth-saml2-bearer-01 606 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 607 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 609 o Update wording in Introduction to talk about extension grant types 610 rather than the assertion grant type which is a term no longer 611 used in OAuth 2.0 613 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 614 progress 616 o Update Parameter Registration Request to use similar terms as 617 draft-ietf-oauth-v2-12 and remove Related information part 619 o Add some text giving discretion to AS on rejecting assertions with 620 unreasonably long validity window. 622 draft-ietf-oauth-saml2-bearer-00 624 o Added Parameter Registration Request for "assertion" to IANA 625 Considerations. 627 o Changed document name to draft-ietf-oauth-saml2-bearer in 628 anticipation of becoming an OAUTH WG item. 630 o Attempt to move the entire definition of the 'assertion' parameter 631 into this draft (it will no longer be defined in OAuth 2 Protocol 632 Framework). 634 draft-campbell-oauth-saml-01 636 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 637 from -10 to -11. 639 o Updated examples. 641 o Relaxed processing rules to allow for more than one 642 SubjectConfirmation element. 644 o Removed the 'MUST NOT contain a NotBefore attribute' on 645 SubjectConfirmationData. 647 o Relaxed wording that ties the subject of the Assertion to the 648 resource owner. 650 o Added some wording about identifying the client when the subject 651 hasn't directly authenticated including an informative reference 652 to SAML V2.0 Condition for Delegation Restriction. 654 o Added a few examples to the language about verifying that the 655 Assertion is valid in all other respects. 657 o Added some wording to the introduction about the similarities to 658 Web SSO in the format and processing rules 660 o Changed the grant_type (was assertion_type) URI from 661 http://oauth.net/assertion_type/saml/2.0/bearer to 662 http://oauth.net/grant_type/assertion/saml/2.0/bearer 664 o Changed title to include "Grant Type" in it. 666 o Editorial updates based on feedback from the WG and others 667 (including capitalization of Assertion when referring to SAML). 669 draft-campbell-oauth-saml-00 671 o Initial I-D 673 Authors' Addresses 675 Brian Campbell (editor) 676 Ping Identity Corp. 678 Email: brian.d.campbell@gmail.com 680 Chuck Mortimore 681 Salesforce.com 683 Email: cmortimore@salesforce.com