idnits 2.17.1 draft-ietf-oauth-saml2-bearer-10.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 (Jan 2012) is 4483 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Corp. 4 Intended status: Standards Track C. Mortimore 5 Expires: July 4, 2012 Salesforce.com 6 Jan 2012 8 SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 9 draft-ietf-oauth-saml2-bearer-10 11 Abstract 13 This specification defines the use of a SAML 2.0 Bearer Assertion as 14 means for requesting an OAuth 2.0 access token as well as for use as 15 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 July 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 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 54 2.1. Using SAML Assertions as Authorization Grants . . . . . . 4 55 2.2. Using SAML Assertions for Client Authentication . . . . . 4 56 3. Assertion Format and Processing Requirements . . . . . . . . . 5 57 3.1. Authorization Grant Processing . . . . . . . . . . . . . . 7 58 3.2. Client Authentication Processing . . . . . . . . . . . . . 8 59 4. Authorization Grant Example (non-normative) . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 6.1. Sub-Namespace Registration of 63 urn:ietf:params:oauth:grant-type:saml2-bearer . . . . . . 10 64 6.2. Sub-Namespace Registration of 65 urn:ietf:params:oauth:client-assertion-type:saml2-bearer . 10 66 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 67 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 The Security Assertion Markup Language (SAML) 2.0 76 [OASIS.saml-core-2.0-os] is an XML-based framework that allows 77 identity and security information to be shared across security 78 domains. The SAML specification, while primarily targeted at 79 providing cross domain Web browser single sign-on, was also designed 80 to be modular and extensible to facilitate use in other contexts. 82 The Assertion, an XML security token, is a fundamental construct of 83 SAML that is often adopted for use in other protocols and 84 specifications. An Assertion is generally issued by an identity 85 provider and consumed by a service provider who relies on its content 86 to identify the Assertion's subject for security related purposes. 88 The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a 89 method for making authenticated HTTP requests to a resource using an 90 access token. Access tokens are issued to third-party clients by an 91 authorization server (AS) with the (sometimes implicit) approval of 92 the resource owner. In OAuth, an authorization grant is an abstract 93 term used to describe intermediate credentials that represent the 94 resource owner authorization. An authorization grant is used by the 95 client to obtain an access token. Several authorization grant types 96 are defined to support a wide range of client types and user 97 experiences. OAuth also allows for the definition of new extension 98 grant types to support additional clients or to provide a bridge 99 between OAuth and other trust frameworks. Finally, OAuth allows the 100 definition of additional authentication mechanisms to be used by 101 clients when interacting with the authorization server. 103 The OAuth 2.0 Assertion Profile [I-D.ietf.oauth-assertions] is an 104 abstract extension to OAuth 2.0 that provides a general framework for 105 the use of assertions as client credentials and/or authorization 106 grants with OAuth 2.0. This specification profiles the OAuth 2.0 107 Assertion Profile [I-D.ietf.oauth-assertions] to define an extension 108 grant type that uses a SAML 2.0 Bearer Assertion to request an OAuth 109 2.0 access token as well as for use as client credentials. The 110 format and processing rules for the SAML Assertion defined in this 111 specification are intentionally similar, though not identical, to 112 those in the Web Browser SSO Profile defined in SAML Profiles 113 [OASIS.saml-profiles-2.0-os]. This specification is reusing, to the 114 extent reasonable, concepts and patterns from that well-established 115 Profile. 117 This document defines how a SAML Assertion can be used to request an 118 access token when a client wishes to utilize an existing trust 119 relationship, expressed through the semantics of (and digital 120 signature calculated over) the SAML Assertion, without a direct user 121 approval step at the authorization server. It also defines how a 122 SAML Assertion can be used as a client authentication mechanism. The 123 use of an Assertion for client authentication is orthogonal and 124 separable from using an Assertion as an authorization grant and the 125 two can be used either in combination or in isolation. 127 The process by which the client obtains the SAML Assertion, prior to 128 exchanging it with the authorization server or using it for client 129 authentication, is out of scope. 131 1.1. Notational Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 Unless otherwise noted, all the protocol parameter names and values 138 are case sensitive. 140 2. HTTP Parameter Bindings for Transporting Assertions 142 The OAuth 2.0 Assertion Profile [I-D.ietf.oauth-assertions] defines 143 generic HTTP parameters for transporting assertions during 144 interactions with a token endpoint. This section defines the values 145 of those parameters for use with SAML 2.0 Bearer Assertions. 147 2.1. Using SAML Assertions as Authorization Grants 149 To use a SAML Bearer Assertion as an authorization grant, use the 150 following parameter values and encodings. 152 The value of "grant_type" parameter MUST be 153 "urn:ietf:params:oauth:grant-type:saml2-bearer" 155 The value of the "assertion" parameter MUST contain a single SAML 2.0 156 Assertion. The SAML Assertion XML data MUST be encoded using 157 base64url, where the encoding adheres to the definition in Section 5 158 of RFC4648 [RFC4648] and where the padding bits are set to zero. To 159 avoid the need for subsequent encoding steps (by "application/ 160 x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the 161 base64url encoded data SHOULD NOT be line wrapped and pad characters 162 ("=") SHOULD NOT be included. 164 2.2. Using SAML Assertions for Client Authentication 166 To use a SAML Bearer Assertion for client authentication grant, use 167 the following parameter values and encodings. 169 The value of "client_assertion_type" parameter MUST be 170 "urn:ietf:params:oauth:client-assertion-type:saml2-bearer" 172 The value of the "client_assertion" parameter MUST contain a single 173 SAML 2.0 Assertion. The SAML Assertion XML data MUST be encoded 174 using base64url, where the encoding adheres to the definition in 175 Section 5 of RFC4648 [RFC4648] and where the padding bits are set to 176 zero. To avoid the need for subsequent encoding steps (by 177 "application/x-www-form-urlencoded" [W3C.REC-html401-19991224], for 178 example), the base64url encoded data SHOULD NOT be line wrapped and 179 pad characters ("=") SHOULD NOT be included. 181 3. Assertion Format and Processing Requirements 183 In order to issue an access token response as described in The OAuth 184 2.0 Authorization Protocol [I-D.ietf.oauth-v2] or to rely on an 185 assertion for client authentication, the authorization server MUST 186 validate the Assertion according to the criteria below. Application 187 of additional restrictions and policy are at the discretion of the 188 authorization server. 190 o The Assertion's element MUST contain a unique identifier 191 for the entity that issued the Assertion. 193 o The Assertion MUST contain element with an 194 element with an element 195 containing a URI reference that identifies the authorization 196 server, or the service provider SAML entity of its controlling 197 domain, as an intended audience. The token endpoint URL of the 198 authorization server MAY be used as an acceptable value for an 199 element. The authorization server MUST verify that it 200 is an intended audience for the Assertion. 202 o The Assertion MUST contain a element. The subject MAY 203 identify the resource owner for whom the access token is being 204 requested. For client authentication, the Subject MUST be the 205 client_id of the OAuth client. When using assertions as an 206 authorization grant, the Subject SHOULD identify an authorized 207 accessor for whom the access token is being requested (typically 208 the resource owner, or an authorized delegate). Additional 209 information identifying the subject/principal of the transaction 210 MAY be included in an . 212 o The Assertion MUST have an expiry that limits the time window 213 during which it can be used. The expiry can be expressed either 214 as the NotOnOrAfter attribute of the element or as 215 the NotOnOrAfter attribute of a suitable 216 element. 218 o The element MUST contain at least one 219 element that allows the authorization server 220 to confirm it as a Bearer Assertion. Such a 221 element MUST have a Method attribute with a value of 222 "urn:oasis:names:tc:SAML:2.0:cm:bearer". The 223 element MUST contain a 224 element, unless the Assertion has a 225 suitable NotOnOrAfter attribute on the element, in 226 which case the element MAY be omitted. 227 When present, the element MUST have a 228 Recipient attribute with a value indicating the token endpoint URL 229 of the authorization server. The authorization server MUST verify 230 that the value of the Recipient attribute matches the token 231 endpoint URL (or an acceptable alias) to which the Assertion was 232 delivered. The element MUST have a 233 NotOnOrAfter attribute that limits the window during which the 234 Assertion can be confirmed. The element 235 MAY also contain an Address attribute limiting the client address 236 from which the Assertion can be delivered. Verification of the 237 Address is at the discretion of the authorization server. 239 o The authorization server MUST verify that occurrences of the 240 NotOnOrAfter instant has not passed, subject to allowable clock 241 skew between systems. An invalid NotOnOrAfter instant on the 242 element invalidates the entire assertion. An invalid 243 NotOnOrAfter instant on a element only 244 invalidates the individual . The 245 authorization server MAY reject assertions with a NotOnOrAfter 246 instant that is unreasonably far in the future. The authorization 247 server MAY ensure that Bearer Assertions are not replayed, by 248 maintaining the set of used ID values for the length of time for 249 which the Assertion would be considered valid based on the 250 applicable NotOnOrAfter instant. 252 o If the Assertion issuer authenticated the subject, the Assertion 253 SHOULD contain a single representing that 254 authentication event. 256 o If the Assertion was issued with the intention that the presenter 257 act autonomously on behalf of the subject, an 258 SHOULD NOT be included. The presenter SHOULD be identified in the 259 or similar element, the element, or 260 by other available means like [OASIS.saml-deleg-cs]. 262 o Other statements, in particular elements, MAY 263 be included in the Assertion. 265 o The Assertion MUST be digitally signed by the issuer and the 266 authorization server MUST verify the signature. 268 o Encrypted elements MAY appear in place of their plain text 269 counterparts as defined in [OASIS.saml-core-2.0-os]. 271 o The authorization server MUST verify that the Assertion is valid 272 in all other respects per [OASIS.saml-core-2.0-os], such as (but 273 not limited to) evaluating all content within the Conditions 274 element including the NotOnOrAfter and NotBefore attributes, 275 rejecting unknown condition types, etc. 277 3.1. Authorization Grant Processing 279 If present, the authorization server MUST also validate the client 280 credentials. 282 Authorization servers SHOULD issue access tokens with a limited 283 lifetime and require clients to refresh them by requesting a new 284 access token using the same assertion, if it is still valid, or with 285 a new assertion. The authorization server SHOULD NOT issue a refresh 286 token. 288 If the Assertion is not valid, or its subject confirmation 289 requirements cannot be met, the authorization server MUST construct 290 an error response as defined in [I-D.ietf.oauth-v2]. The value of 291 the error parameter MUST be the "invalid_grant" error code. The 292 authorization server MAY include additional information regarding the 293 reasons the Assertion was considered invalid using the 294 error_description or error_uri parameters. 296 For example: 298 HTTP/1.1 400 Bad Request 299 Content-Type: application/json 300 Cache-Control: no-store 302 { 303 "error":"invalid_grant", 304 "error_description":"Audience validation failed" 305 } 307 3.2. Client Authentication Processing 309 If the client Assertion is not valid, or its subject confirmation 310 requirements cannot be met, the authorization server MUST construct 311 an error response as defined in [I-D.ietf.oauth-v2]. The value of 312 the error parameter MUST be the "invalid_client" error code. The 313 authorization server MAY include additional information regarding the 314 reasons the Assertion was considered invalid using the 315 error_description or error_uri parameters. 317 4. Authorization Grant Example (non-normative) 319 Though non-normative, the following examples illustrate what a 320 conforming Assertion and access token request would look like. 322 Below is an example SAML 2.0 Assertion (whitespace formatting is for 323 display purposes only): 325 329 https://saml-idp.example.com 330 331 [...omitted for brevity...] 332 333 334 336 brian@example.com 337 338 340 343 344 345 346 347 https://saml-sp.example.net 348 349 350 351 352 353 urn:oasis:names:tc:SAML:2.0:ac:classes:X509 354 355 356 357 359 Figure 1: Example SAML 2.0 Assertion 361 To present the Assertion shown in the previous example as part of an 362 access token request, for example, the client might make the 363 following HTTPS request (line breaks are for display purposes only): 365 POST /token.oauth2 HTTP/1.1 366 Host: authz.example.net 367 Content-Type: application/x-www-form-urlencoded 369 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- 370 bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU 371 [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- 373 Figure 2: Example Request 375 5. Security Considerations 377 No additional considerations beyond those described within the OAuth 378 2.0 Protocol Framework [I-D.ietf.oauth-v2] and in the Security and 379 Privacy Considerations for the OASIS Security Assertion Markup 380 Language (SAML) V2.0 [OASIS.saml-sec-consider-2.0-os]. 382 6. IANA Considerations 384 6.1. Sub-Namespace Registration of 385 urn:ietf:params:oauth:grant-type:saml2-bearer 387 This is a request to IANA to please register the value grant- 388 type:saml2-bearer in the registry urn:ietf:params:oauth established 389 in [I-D.ietf.oauth-urn-sub-ns] 391 o URN: urn:ietf:params:oauth:grant-type:saml2-bearer 393 o Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for 394 OAuth 2.0 396 o Change controller: IETF 398 o Description: [[this document]] 400 6.2. Sub-Namespace Registration of 401 urn:ietf:params:oauth:client-assertion-type:saml2-bearer 403 This is a request to IANA to please register the value client- 404 assertion-type:saml2-bearer in the registry urn:ietf:params:oauth 405 established in [I-D.ietf.oauth-urn-sub-ns] 406 o URN: urn:ietf:params:oauth:client-assertion-type:saml2-bearer 408 o Common Name: SAML 2.0 Bearer Assertion Profile for OAuth 2.0 409 Client Authentication 411 o Change controller: IETF 413 o Description: [[this document]] 415 Appendix A. Contributors 417 The following people contributed wording and concepts to this 418 document: Paul Madsen, Patrick Harding, Peter Motykowski, Eran 419 Hammer-Lahav, Peter Saint-Andre, Ian Barnett, Eric Fazendin, Torsten 420 Lodderstedt, Susan Harper, Scott Tomilson, Scott Cantor, Michael 421 Jones, Hannes Tschofenig, David Waite and Mukesh Bhatnagar. 423 Appendix B. Document History 425 [[ to be removed by RFC editor before publication as an RFC ]] 427 draft-ietf-oauth-saml2-bearer-10 429 o fix a spelling mistake 431 draft-ietf-oauth-saml2-bearer-09 433 o Attempt to address an ambiguity around validation requirements 434 when the Conditions element contain a NotOnOrAfter and 435 SubjectConfirmation/SubjectConfirmationData does too. Basically 436 it needs to have at least one bearer SubjectConfirmation element 437 but that element can omit SubjectConfirmationData, if Conditions 438 has an expiry on it. Otherwise, a valid SubjectConfirmation must 439 have a SubjectConfirmationData with Recipient and NotOnOrAfter. 440 And any SubjectConfirmationData that has those elements needs to 441 have them checked. 443 o clarified that AudienceRestriction is under Conditions (even 444 though it's implied by schema) 446 o fix a typo 448 draft-ietf-oauth-saml2-bearer-08 450 o fix some typos 451 o update reference from draft-campbell-oauth-urn-sub-ns to 452 draft-ietf-oauth-urn-sub-ns 454 o Updated to reference draft-ietf-oauth-v2-20 456 draft-ietf-oauth-saml2-bearer-06 458 o Fix three typos NamseID->NameID and (2x) Namspace->Namespace 460 draft-ietf-oauth-saml2-bearer-05 462 o Allow for subject confirmation data to be optional when Conditions 463 contain audience and NotOnOrAfter 465 o Rework most of the spec to profile draft-ietf-oauth-assertions for 466 both authn and authz including (but not limited to): 468 * remove requirement for issuer to be 469 urn:oasis:names:tc:SAML:2.0:nameid-format:entity 471 * change wording on Subject requirements 473 o using a MAY, explicitly say that the Audience can be token 474 endpoint URL of the authorization server 476 o Change title to be more generic (allowing for client authn too) 478 o added client authentication to the abstract 480 o register and use urn:ietf:params:oauth:grant-type:saml2-bearer for 481 grant type rather than http://oauth.net/grant_type/saml/2.0/bearer 483 o register urn:ietf:params:oauth:client-assertion-type:saml2-bearer 485 o remove scope parameter as it is defined in 486 http://tools.ietf.org/html/draft-ietf-oauth-assertions 488 o remove assertion param registration because it [should] be in 489 http://tools.ietf.org/html/draft-ietf-oauth-assertions 491 o fix typo(s) and update/add references 493 draft-ietf-oauth-saml2-bearer-04 495 o Changed the grant_type URI from 496 "http://oauth.net/grant_type/assertion/saml/2.0/bearer" to 497 "http://oauth.net/grant_type/saml/2.0/bearer" - dropping the word 498 assertion from the path. Recent versions of draft-ietf-oauth-v2 499 no longer refer to extension grants using the word assertion so 500 this URI is more reflective of that. It also more closely aligns 501 with the grant type URI in draft-jones-oauth-jwt-bearer-00 which 502 is "http://oauth.net/grant_type/jwt/1.0/bearer". 504 o Added "case sensitive" to scope definition to align with 505 draft-ietf-oauth-v2-15/16. 507 o Updated to reference draft-ietf-oauth-v2-16 509 draft-ietf-oauth-saml2-bearer-03 511 o Cleanup of some editorial issues. 513 draft-ietf-oauth-saml2-bearer-02 515 o Added scope parameter with text copied from draft-ietf-oauth-v2-12 516 (the reorg of draft-ietf-oauth-v2-12 made it so scope wasn't 517 really inherited by this spec anymore) 519 o Change definition of the assertion parameter to be more generally 520 applicable per the suggestion near the end of 521 http://www.ietf.org/mail-archive/web/oauth/current/msg05253.html 523 o Editorial changes based on feedback 525 draft-ietf-oauth-saml2-bearer-01 527 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 528 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) 530 o Update wording in Introduction to talk about extension grant types 531 rather than the assertion grant type which is a term no longer 532 used in OAuth 2.0 534 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in 535 progress 537 o Update Parameter Registration Request to use similar terms as 538 draft-ietf-oauth-v2-12 and remove Related information part 540 o Add some text giving discretion to AS on rejecting assertions with 541 unreasonably long validity window. 543 draft-ietf-oauth-saml2-bearer-00 544 o Added Parameter Registration Request for "assertion" to IANA 545 Considerations. 547 o Changed document name to draft-ietf-oauth-saml2-bearer in 548 anticipation of becoming a OAUTH WG item. 550 o Attempt to move the entire definition of the 'assertion' parameter 551 into this draft (it will no longer be defined in OAuth 2 Protocol 552 Framework). 554 draft-campbell-oauth-saml-01 556 o Updated to reference draft-ietf-oauth-v2-11 and reflect changes 557 from -10 to -11. 559 o Updated examples. 561 o Relaxed processing rules to allow for more than one 562 SubjectConfirmation element. 564 o Removed the 'MUST NOT contain a NotBefore attribute' on 565 SubjectConfirmationData. 567 o Relaxed wording that ties the subject of the Assertion to the 568 resource owner. 570 o Added some wording about identifying the client when the subject 571 hasn't directly authenticated including an informative reference 572 to SAML V2.0 Condition for Delegation Restriction. 574 o Added a few examples to the language about verifying that the 575 Assertion is valid in all other respects. 577 o Added some wording to the introduction about the similarities to 578 Web SSO in the format and processing rules 580 o Changed the grant_type (was assertion_type) URI from 581 http://oauth.net/assertion_type/saml/2.0/bearer to 582 http://oauth.net/grant_type/assertion/saml/2.0/bearer 584 o Changed title to include "Grant Type" in it. 586 o Editorial updates based on feedback from the WG and others 587 (including capitalization of Assertion when referring to SAML). 589 draft-campbell-oauth-saml-00 590 o Initial I-D 592 7. References 594 7.1. Normative References 596 [I-D.ietf.oauth-assertions] 597 Mortimore, C., Ed., Campbell, B., Jones, M., and Y. 598 Goland, "OAuth 2.0 Assertion Profile", 599 ID draft-ietf-oauth-assertions-00 (work in progress), 600 July 2011. 602 [I-D.ietf.oauth-urn-sub-ns] 603 Campbell, B., Ed. and H. Tschofenig, "An IETF URN Sub- 604 Namespace for OAuth", ID draft-ietf-oauth-urn-sub-ns-00 605 (work in progress), Aug 2011. 607 [I-D.ietf.oauth-v2] 608 Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The 609 OAuth 2.0 Authorization Protocol", 610 ID draft-ietf-oauth-v2-16 (work in progress), May 2011. 612 [OASIS.saml-core-2.0-os] 613 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 614 "Assertions and Protocol for the OASIS Security Assertion 615 Markup Language (SAML) V2.0", OASIS Standard saml-core- 616 2.0-os, March 2005. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 622 Encodings", RFC 4648, October 2006. 624 7.2. Informative References 626 [OASIS.saml-deleg-cs] 627 Cantor, S., Ed., "SAML V2.0 Condition for Delegation 628 Restriction", Nov 2009. 630 [OASIS.saml-profiles-2.0-os] 631 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 632 P., Philpott, R., and E. Maler, "Profiles for the OASIS 633 Security Assertion Markup Language (SAML) V2.0", OASIS 634 Standard OASIS.saml-profiles-2.0-os, March 2005. 636 [OASIS.saml-sec-consider-2.0-os] 637 Hirsch, F., Philpott, R., and E. Maler, "Security and 638 Privacy Considerations for the OASIS Security Markup 639 Language (SAML) V2.0", OASIS Standard saml-sec-consider- 640 2.0-os, March 2005. 642 [W3C.REC-html401-19991224] 643 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 644 Specification", World Wide Web Consortium 645 Recommendation REC-html401-19991224, December 1999, 646 . 648 Authors' Addresses 650 Brian Campbell (editor) 651 Ping Identity Corp. 653 Email: brian.d.campbell@gmail.com 655 Chuck Mortimore 656 Salesforce.com 658 Email: cmortimore@salesforce.com