idnits 2.17.00 (12 Aug 2021) /tmp/idnits54619/draft-ietf-oauth-saml2-bearer-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2012) is 3608 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: draft-ietf-oauth-assertions has been published as RFC 7521 == Outdated reference: draft-ietf-oauth-urn-sub-ns has been published as RFC 6755 ** Downref: Normative reference to an Informational draft: draft-ietf-oauth-urn-sub-ns (ref. 'I-D.ietf-oauth-urn-sub-ns') == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 Summary: 1 error (**), 0 flaws (~~), 4 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: January 4, 2013 Salesforce 6 July 3, 2012 8 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-13 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 January 4, 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 . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 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 (or an acceptable alias). The 238 authorization server MUST verify that the value of the Recipient 239 attribute matches the token endpoint URL (or an acceptable alias) 240 to which the Assertion was delivered. The 241 element MUST have a NotOnOrAfter 242 attribute that limits the window during which the Assertion can be 243 confirmed. The element MAY also contain 244 an Address attribute limiting the client address from which the 245 Assertion can be delivered. Verification of the Address is at the 246 discretion of the authorization server. 248 o The authorization server MUST verify that the NotOnOrAfter instant 249 has not passed, subject to allowable clock skew between systems. 250 An invalid NotOnOrAfter instant on the element 251 invalidates the entire Assertion. An invalid NotOnOrAfter instant 252 on a element only invalidates the 253 individual . The authorization server MAY 254 reject Assertions with a NotOnOrAfter instant that is unreasonably 255 far in the future. The authorization server MAY ensure that 256 Bearer Assertions are not replayed, by maintaining the set of used 257 ID values for the length of time for which the Assertion would be 258 considered valid based on the applicable NotOnOrAfter instant. 260 o If the Assertion issuer authenticated the subject, the Assertion 261 SHOULD contain a single representing that 262 authentication event. 264 o If the Assertion was issued with the intention that the presenter 265 act autonomously on behalf of the subject, an 266 SHOULD NOT be included. The presenter SHOULD be identified in the 267 or similar element, the element, or 268 by other available means like [OASIS.saml-deleg-cs]. 270 o Other statements, in particular elements, MAY 271 be included in the Assertion. 273 o The Assertion MUST be digitally signed by the issuer and the 274 authorization server MUST verify the signature. 276 o Encrypted elements MAY appear in place of their plain text 277 counterparts as defined in [OASIS.saml-core-2.0-os]. 279 o The authorization server MUST verify that the Assertion is valid 280 in all other respects per [OASIS.saml-core-2.0-os], such as (but 281 not limited to) evaluating all content within the Conditions 282 element including the NotOnOrAfter and NotBefore attributes, 283 rejecting unknown condition types, etc. 285 3.1. Authorization Grant Processing 287 If present, the authorization server MUST also validate the client 288 credentials. 290 If the Assertion is not valid, or its subject confirmation 291 requirements cannot be met, the authorization server MUST construct 292 an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The 293 value of the "error" parameter MUST be the "invalid_grant" error 294 code. The authorization server MAY include additional information 295 regarding the reasons the Assertion was considered invalid using the 296 "error_description" or "error_uri" parameters. 298 For example: 300 HTTP/1.1 400 Bad Request 301 Content-Type: application/json 302 Cache-Control: no-store 304 { 305 "error":"invalid_grant", 306 "error_description":"Audience validation failed" 307 } 309 3.2. Client Authentication Processing 311 If the client Assertion is not valid, or its subject confirmation 312 requirements cannot be met, the authorization server MUST construct 313 an error response as defined in OAuth 2.0 [I-D.ietf-oauth-v2]. The 314 value of the "error" parameter MUST be the "invalid_client" error 315 code. The authorization server MAY include additional information 316 regarding the reasons the Assertion was considered invalid using the 317 "error_description" or "error_uri" parameters. 319 4. Authorization Grant Example 321 Though non-normative, the following examples illustrate what a 322 conforming Assertion and access token request would look like. 324 Below is an example SAML 2.0 Assertion (whitespace formatting is for 325 display purposes only): 327 331 https://saml-idp.example.com 332 333 [...omitted for brevity...] 334 335 336 338 brian@example.com 339 340 342 345 346 347 348 349 https://saml-sp.example.net 350 351 352 353 354 355 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 356 357 358 359 361 Figure 1: Example SAML 2.0 Assertion 363 To present the Assertion shown in the previous example as part of an 364 access token request, for example, the client might make the 365 following HTTPS request (with line breaks for display purposes only): 367 POST /token.oauth2 HTTP/1.1 368 Host: authz.example.net 369 Content-Type: application/x-www-form-urlencoded 371 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 372 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 373 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 375 Figure 2: Example Request 377 5. Security Considerations 379 No additional security considerations apply beyond those described 380 within The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2], the 381 OAuth 2.0 Assertion Profile [I-D.ietf-oauth-assertions], and in the 382 Security and Privacy Considerations for the OASIS Security Assertion 383 Markup Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 385 6. IANA Considerations 387 6.1. Sub-Namespace Registration of 388 urn:ietf:params:oauth:grant-type:saml2-bearer 390 This is a request to IANA to please register the value 391 "grant-type:saml2-bearer" in the registry urn:ietf:params:oauth 392 established in An IETF URN Sub-Namespace for OAuth 393 [I-D.ietf-oauth-urn-sub-ns]. 395 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 397 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 398 OAuth 2.0 400 o Change controller: IETF 402 o Specification Document: [[this document]] 404 6.2. Sub-Namespace Registration of 405 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 407 This is a request to IANA to please register the value 408 "client-assertion-type:saml2-bearer" in the registry 409 urn:ietf:params:oauth established in An IETF URN Sub-Namespace for 410 OAuth [I-D.ietf-oauth-urn-sub-ns]. 412 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 414 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 415 Client Authentication 417 o Change controller: IETF 419 o Specification Document: [[this document]] 421 7. References 423 7.1. Normative References 425 [I-D.ietf-oauth-assertions] 426 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 427 "Assertion Framework for OAuth 2.0", 428 draft-ietf-oauth-assertions-04 (work in progress), 429 July 2012. 431 [I-D.ietf-oauth-urn-sub-ns] 432 Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 433 for OAuth", draft-ietf-oauth-urn-sub-ns-05 (work in 434 progress), June 2012. 436 [I-D.ietf-oauth-v2] 437 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 438 2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work 439 in progress), June 2012. 441 [OASIS.saml-core-2.0-os] 442 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 443 "Assertions and Protocol for the OASIS Security Assertion 444 Markup Language (SAML) V2.0", OASIS Standard saml-core- 445 2.0-os, March 2005. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 451 Encodings", RFC 4648, October 2006. 453 7.2. Informative References 455 [OASIS.saml-deleg-cs] 456 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 457 Restriction", Nov 2009. 459 [OASIS.saml-profiles-2.0-os] 460 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 461 P., Philpott, R., and E. Maler, "Profiles for the OASIS 462 Security Assertion Markup Language (SAML) V2.0", OASIS 463 Standard OASIS.saml-profiles-2.0-os, March 2005. 465 [OASIS.saml-sec-consider-2.0-os] 466 Hirsch, F., Philpott, R., and E. Maler, "Security and 467 Privacy Considerations for the OASIS Security Markup 468 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 469 2.0-os, March 2005. 471 [W3C.REC-html401-19991224] 472 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 473 Specification", World Wide Web Consortium 474 Recommendation REC-html401-19991224, December 1999, 475 . 477 Appendix A. Acknowledgements 479 The following people contributed wording and concepts to this 480 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 481 Hammer, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 482 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael B. 483 Jones, Hannes Tschofenig, David Waite, Phil Hunt, and Mukesh 484 Bhatnagar. 486 Appendix B. Document History 488 [[ to be removed by RFC editor before publication as an RFC ]] 490 draft-ietf-oauth-saml2-bearer-13 492 o Update references: oauth-assertions-04, oauth-urn-sub-ns-05, oauth 493 -28 495 o Changed "Description" to "Specification Document" in both 496 registration requests in IANA Considerations per changes to the 497 template in ietf-oauth-urn-sub-ns(-03) 499 o Added "(or an acceptable alias)" so that it's in both sentences 500 about Recipient and the token endpoint URL so there's no ambiguity 502 o (now Security and OAuth was Internet and nothing) 504 draft-ietf-oauth-saml2-bearer-12 506 o updated reference to draft-ietf-oauth-v2 from -25 to -26 and 507 draft-ietf-oauth-assertions from -02 to -03 509 draft-ietf-oauth-saml2-bearer-11 511 o Removed text about limited lifetime access tokens and the SHOULD 512 NOT on issuing refresh tokens. The text was moved to 513 draft-ietf-oauth-assertions-02 and somewhat modified per 514 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 516 o Fixed typo/missing word per 517 http://www.ietf.org/mail-archive/web/oauth/current/msg08733.html. 519 o Added Terminology section. 521 draft-ietf-oauth-saml2-bearer-10 523 o fix a spelling mistake 525 draft-ietf-oauth-saml2-bearer-09 527 o Attempt to address an ambiguity around validation requirements 528 when the Conditions element contain a NotOnOrAfter and 529 SubjectConfirmation/SubjectConfirmationData does too. Basically 530 it needs to have at least one bearer SubjectConfirmation element 531 but that element can omit SubjectConfirmationData, if Conditions 532 has an expiry on it. Otherwise, a valid SubjectConfirmation must 533 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 534 And any SubjectConfirmationData that has those elements needs to 535 have them checked. 537 o clarified that AudienceRestriction is under Conditions (even 538 though it's implied by schema) 540 o fix a typo 542 draft-ietf-oauth-saml2-bearer-08 543 o fix some typos 545 draft-ietf-oauth-saml2-bearer-07 547 o update reference from draft-campbell-oauth-urn-sub-ns to 548 draft-ietf-oauth-urn-sub-ns 550 o Updated to reference draft-ietf-oauth-v2-20 552 draft-ietf-oauth-saml2-bearer-06 554 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 556 draft-ietf-oauth-saml2-bearer-05 558 o Allow for subject confirmation data to be optional when Conditions 559 contain audience and NotOnOrAfter 561 o Rework most of the spec to profile draft-ietf-oauth-assertions for 562 both authn and authz including (but not limited to): 564 * remove requirement for issuer to be 565 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 567 * change wording on Subject requirements 569 o using a MAY, explicitly say that the Audience can be token 570 endpoint URL of the authorization server 572 o Change title to be more generic (allowing for client authn too) 574 o added client authentication to the abstract 576 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 577 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 579 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 581 o remove scope parameter as it is defined in 582 http://tools.ietf.org/html/draft-ietf-oauth-assertions 584 o remove assertion param registration because it [should] be in 585 http://tools.ietf.org/html/draft-ietf-oauth-assertions 587 o fix typo(s) and update/add references 589 draft-ietf-oauth-saml2-bearer-04 590 o Changed the grant_type URI from 591 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 592 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 593 assertion from the path. Recent versions of draft-ietf-oauth-v2 594 no longer refer to extension grants using the word assertion so 595 this URI is more reflective of that. It also more closely aligns 596 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 597 is "http://oauth.net/grant_type/jwt/1.0/bearer". 599 o Added "case sensitive" to scope definition to align with 600 draft-ietf-oauth-v2-15/16. 602 o Updated to reference draft-ietf-oauth-v2-16 604 draft-ietf-oauth-saml2-bearer-03 606 o Cleanup of some editorial issues. 608 draft-ietf-oauth-saml2-bearer-02 610 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 611 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 612 really inherited by this spec anymore) 614 o Change definition of the assertion parameter to be more generally 615 applicable per the suggestion near the end of 616 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 618 o Editorial changes based on feedback 620 draft-ietf-oauth-saml2-bearer-01 622 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 623 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 625 o Update wording in Introduction to talk about extension grant types 626 rather than the assertion grant type which is a term no longer 627 used in OAuth 2.0 629 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 630 progress 632 o Update Parameter Registration Request to use similar terms as 633 draft-ietf-oauth-v2-12 and remove Related information part 635 o Add some text giving discretion to AS on rejecting assertions with 636 unreasonably long validity window. 638 o Added Parameter Registration Request for "assertion" to IANA 639 Considerations. 641 o Changed document name to draft-ietf-oauth-saml2-bearer in 642 anticipation of becoming an OAUTH WG item. 644 o Attempt to move the entire definition of the 'assertion' parameter 645 into this draft (it will no longer be defined in OAuth 2 Protocol 646 Framework). 648 draft-campbell-oauth-saml-01 650 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 651 from -10 to -11. 653 o Updated examples. 655 o Relaxed processing rules to allow for more than one 656 SubjectConfirmation element. 658 o Removed the 'MUST NOT contain a NotBefore attribute' on 659 SubjectConfirmationData. 661 o Relaxed wording that ties the subject of the Assertion to the 662 resource owner. 664 o Added some wording about identifying the client when the subject 665 hasn't directly authenticated including an informative reference 666 to SAML V2.0 Condition for Delegation Restriction. 668 o Added a few examples to the language about verifying that the 669 Assertion is valid in all other respects. 671 o Added some wording to the introduction about the similarities to 672 Web SSO in the format and processing rules 674 o Changed the grant_type (was assertion_type) URI from 675 http://oauth.net/assertion_type/saml/2.0/bearer to 676 http://oauth.net/grant_type/assertion/saml/2.0/bearer 678 o Changed title to include "Grant Type" in it. 680 o Editorial updates based on feedback from the WG and others 681 (including capitalization of Assertion when referring to SAML). 683 draft-campbell-oauth-saml-00 684 o Initial I-D 686 Authors' Addresses 688 Brian Campbell 689 Ping Identity Corp. 691 Email: brian.d.campbell@gmail.com 693 Chuck Mortimore 694 Salesforce.com 696 Email: cmortimore@salesforce.com