idnits 2.17.1 draft-ietf-oauth-assertions-03.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 2, 2012) is 4375 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 (-31) exists of draft-ietf-oauth-v2-26 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 C. Mortimore, Ed. 3 Internet-Draft Salesforce 4 Intended status: Standards Track M. Jones 5 Expires: November 3, 2012 Microsoft 6 B. Campbell 7 Ping 8 Y. Goland 9 Microsoft 10 May 2, 2012 12 OAuth 2.0 Assertion Profile 13 draft-ietf-oauth-assertions-03 15 Abstract 17 This specification provides a general framework for the use of 18 assertions as client credentials and/or authorization grants with 19 OAuth 2.0. It includes a generic mechanism for transporting 20 assertions during interactions with a token endpoint, as wells as 21 rules for the content and processing of those assertions. The intent 22 is to provide an enhanced security profile by using derived values 23 such as signatures or HMACs, as well as facilitate the use of OAuth 24 2.0 in client-server integration scenarios where the end-user may not 25 be present. 27 This specification only defines abstract message flow and assertion 28 content. Actual use requires implementation of a companion protocol 29 binding specification. Additional profile documents provide standard 30 representations in formats such as SAML and JWT. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 3, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Requirements Notation and Conventions . . . . . . . . . . . . 3 67 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Authentication vs. Authorization . . . . . . . . . . . . . . . 4 69 4. Transporting Assertions . . . . . . . . . . . . . . . . . . . 4 70 4.1. Using Assertions for Client Authentication . . . . . . . . 4 71 4.1.1. Error Responses . . . . . . . . . . . . . . . . . . . 5 72 4.2. Using Assertions as Authorization Grants . . . . . . . . . 6 73 4.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 7 74 5. Assertion Content and Processing . . . . . . . . . . . . . . . 7 75 5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 8 76 5.2. General Assertion Format and Processing Rules . . . . . . 8 77 6. Specific Assertion Format and Processing Rules . . . . . . . . 9 78 6.1. Client Authentication . . . . . . . . . . . . . . . . . . 9 79 6.2. Client Acting on Behalf of Itself . . . . . . . . . . . . 10 80 6.3. Client Acting on Behalf of a User . . . . . . . . . . . . 11 81 6.4. Client Acting on Behalf of an Anonymous User . . . . . . . 12 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 8.1. assertion Parameter Registration . . . . . . . . . . . . . 13 85 8.2. client_assertion Parameter Registration . . . . . . . . . 14 86 8.3. client_assertion_type Parameter Registration . . . . . . . 14 87 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 89 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Requirements Notation and Conventions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119] . 98 Throughout this document, values are quoted to indicate that they are 99 to be taken literally. When using these values in protocol messages, 100 the quotes MUST NOT be used as part of the value. 102 2. Overview 104 The OAuth 2.0 Authorization Protocol [I-D.ietf-oauth-v2] provides a 105 method for making authenticated HTTP requests to a resource using an 106 access token. Access tokens are issued to clients by an 107 authorization server with the (sometimes implicit) approval of the 108 resource owner. These access tokens are typically obtained by 109 exchanging an authorization grant representing authorization by the 110 resource owner or privileged administrator. Several authorization 111 grant types are defined to support a wide range of client types and 112 user experiences. OAuth also allows for the definition of new 113 extension grant types to support additional clients or to provide a 114 bridge between OAuth and other trust frameworks. Finally, OAuth 115 allows the definition of additional authentication mechanisms to be 116 used by clients when interacting with the authorization server. 118 In scenarios where security is at a premium one wants to avoid 119 sending secrets across the Internet, even on encrypted connections. 120 Instead one wants to send values derived from the secret that prove 121 to the receiver that the sender is in possession of the secret 122 without actually sending the secret. Typically the way derived 123 values are created is by generating an assertion that is then either 124 HMAC'ed or digitally signed using an agreed upon secret. By 125 validating the HMAC or digital signature on the assertion, the 126 receiver can prove to themselves that the entity that generated the 127 assertion was in possession of the secret without actually 128 communicating the secret directly. 130 This specification provides a general framework for the use of 131 assertions as client credentials and/or authorization grants with 132 OAuth 2.0. It includes a generic mechanism for transporting 133 assertions during interactions with a token endpoint, as wells as 134 rules for the content and processing of those assertions. The intent 135 is to provide an enhanced security profile by using derived values 136 such as signatures or HMACs, as well as facilitate the use of OAuth 137 2.0 in client-server integration scenarios where the end-user may not 138 be present. 140 This specification only defines abstract message flow and assertion 141 content. Actual use requires implementation of a companion protocol 142 binding specification. Additional profile documents provide standard 143 representations in formats such as SAML and JWT. 145 3. Authentication vs. Authorization 147 This specification provides a model for using assertions for 148 authentication of an OAuth client during interactions with an 149 Authorization Server, as well as the use of assertions as 150 authorization grants. It is important to note that the use of 151 assertions for client authentication is orthogonal and separable from 152 using assertions as an authorization grant and can be used either in 153 combination or in isolation. In addition, in scenarios when 154 assertion based authentication and authorization are used in 155 combination, the assertion format and processing may be redundant; 156 under such circumstances, the protocol may be optimized to present a 157 single assertion. 159 4. Transporting Assertions 161 This section defines generic HTTP parameters for transporting 162 assertions during interactions with a token endpoint. 164 4.1. Using Assertions for Client Authentication 166 In scenarios where one wants to avoid sending secrets, one wants to 167 send values derived from the secret that prove to the receiver that 168 the sender is in possession of the secret without actually sending 169 the secret. 171 For example, a client can establish a secret using an out-of-band 172 mechanism with a resource server. As part of this out-of-band 173 communication the client and resource server agree that the client 174 will authenticate itself using an assertion with agreed upon 175 parameters that will be signed by the provisioned secret. Later on, 176 the client might send an access token request to the token endpoint 177 for the resource server that includes an authorization code, as well 178 as a "client_assertion" that is signed with the previously agreed key 179 and parameters. The "client_assertion" proves to the token endpoint 180 the identity of the client and the authorization code provides the 181 link to the end-user authorization. 183 The following section defines the use of assertions as client 184 credentials as an extension of Section 2.3 of OAuth 2.0 185 [I-D.ietf-oauth-v2]. When using assertions as client credentials, 186 the client includes the assertion and related information using the 187 following HTTP request parameters: 189 client_id OPTIONAL. The client identifier as described in Section 190 2.2 of OAuth 2.0 [I-D.ietf-oauth-v2]. When present, the 191 "client_id" MUST identify the client to the authorization server. 193 client_assertion_type REQUIRED. The format of the assertion as 194 defined by the authorization server. The value MUST be an 195 absolute URI. 197 client_assertion REQUIRED. The assertion being used to authenticate 198 the client. Specific serialization of the assertion is defined by 199 profile documents. The serialization MUST be encoded for 200 transport within HTTP forms. It is RECOMMENDED that base64url be 201 used. 203 The following non-normative example demonstrates a client 204 authenticating using an assertion during an Authorization Code Access 205 Token Request as defined in Section 4.1.3 of OAuth 2.0 206 [I-D.ietf-oauth-v2] (with line breaks for display purposes only): 207 POST /token HTTP/1.1 208 Host: server.example.com 209 Content-Type: application/x-www-form-urlencoded 211 grant_type=authorization_code& 212 code=i1WsRn1uB1& 213 client_id=s6BhdRkqt3& 214 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 215 %3Aclient-assertion-type%3Asaml2-bearer& 216 client_assertion=PHNhbW...[omitted for brevity]...ZT 218 Token endpoints can differentiate between assertion based credentials 219 and other client credential types by looking for the presence of the 220 "client_assertion" and "client_assertion_type" parameters, which will 221 only be present when using assertions for client authentication. 223 4.1.1. Error Responses 225 If an assertion is invalid for any reason or if more than one client 226 authentication mechanism is used, the Authorization Server MUST 227 construct an error response as defined in OAuth 2.0 228 [I-D.ietf-oauth-v2]. The value of the "error" parameter MUST be the 229 "invalid_client" error code. The authorization server MAY include 230 additional information regarding the reasons the client assertion was 231 considered invalid using the "error_description" or "error_uri" 232 parameters. 234 For example: 235 HTTP/1.1 400 Bad Request 236 Content-Type: application/json 237 Cache-Control: no-store 239 { 240 "error":"invalid_client" 241 "error_description":"Multiple Credentials Not Allowed" 242 } 244 4.2. Using Assertions as Authorization Grants 246 An assertion can be used to request an access token when a client 247 wishes to utilize an existing trust relationship. This may be done 248 through the semantics of (and a digital signature/HMAC calculated 249 over) the assertion, and expressed to the authorization server 250 through an extension authorization grant type. The processes by 251 which authorization is previously granted, and by which the client 252 obtains the assertion prior to exchanging it with the authorization 253 server, are out of scope. 255 The following defines the use of assertions as authorization grants 256 as an extension of OAuth 2.0 [I-D.ietf-oauth-v2], Section 4.5. When 257 using assertions as authorization grants, the client includes the 258 assertion and related information using the following HTTP request 259 parameters: 261 grant_type REQUIRED. The format of the assertion as defined by the 262 authorization server. The value MUST be an absolute URI. 264 assertion REQUIRED. The assertion being used as an authorization 265 grant. Specific serialization of the assertion is defined by 266 profile documents. The serialization MUST be encoded for 267 transport within HTTP forms. It is RECOMMENDED that base64url be 268 used. 270 scope OPTIONAL. The requested scope as described in Section 3.3 of 271 OAuth 2.0 [I-D.ietf-oauth-v2]. When exchanging assertions for 272 access tokens, the authorization for the token has been previously 273 granted through some other mechanism. As such, the requested 274 scope SHOULD be equal or lesser than the scope originally granted 275 to the authorized accessor. If the scope parameter and/or value 276 is omitted, the scope SHOULD be treated as equal to the scope 277 originally granted to the authorized accessor. The Authorization 278 Server SHOULD limit the scope of the issued access token to be 279 equal or lesser than the scope originally granted to the 280 authorized accessor. 282 The following non-normative example demonstrates an assertion being 283 used as an authorization grant (with line breaks for display purposes 284 only): 285 POST /token HTTP/1.1 286 Host: server.example.com 287 Content-Type: application/x-www-form-urlencoded 289 client_id=s6BhdRkqt3& 290 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 291 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 293 An assertion used in this context is generally a short lived 294 representation of the authorization grant and authorization servers 295 SHOULD NOT issue tokens that exceed that lifetime by a significant 296 period. In practice, that will usually mean that refresh tokens are 297 not issued in response to assertion grant requests and access tokens 298 will be issued with a reasonably limited lifetime. Clients can 299 refresh an expired access token by requesting a new one using the 300 same assertion, if it is still valid, or with a new assertion. 302 4.2.1. Error Responses 304 If an assertion is not valid or has expired, the Authorization Server 305 MUST construct an error response as defined in OAuth 2.0 306 [I-D.ietf-oauth-v2]. The value of the "error" parameter MUST be the 307 "invalid_grant" error code. The authorization server MAY include 308 additional information regarding the reasons the assertion was 309 considered invalid using the "error_description" or "error_uri" 310 parameters. 312 For example: 313 HTTP/1.1 400 Bad Request 314 Content-Type: application/json 315 Cache-Control: no-store 317 { 318 "error":"invalid_grant", 319 "error_description":"Audience validation failed" 320 } 322 5. Assertion Content and Processing 324 This section provides a general content and processing model for the 325 use of assertions in OAuth 2.0 [I-D.ietf-oauth-v2]. 327 5.1. Assertion Metamodel 329 The following are entities and metadata involved in the issuance, 330 exchange and processing of assertions in OAuth 2.0. These are 331 general terms, abstract from any particular assertion format. 332 Mappings of these terms into specific representations are provided by 333 profiles of this specification. 335 Issuer The unique identifier for the entity that issued the 336 assertion. Generally this is the entity that holds the keying 337 material used to generate the assertion. In some use cases 338 Issuers may be either OAuth Clients (when assertions are self- 339 asserted) or a Security Token Service (STS) (an entity capable of 340 issuing, renewing, transforming and validating of security 341 tokens). 343 Principal A unique identifier for the subject of the assertion. 344 When using assertions for client authentication, the Principal 345 SHOULD be the "client_id" of the OAuth client. When using 346 assertions as an authorization grant, the Principal MUST identify 347 an authorized accessor for whom the access token is being 348 requested (typically the resource owner, or an authorized 349 delegate). 351 Audience A URI that identifies the party intended to process the 352 assertion. The audience SHOULD be the URL of the Token Endpoint 353 as defined in Section 3.2 of OAuth 2.0 [I-D.ietf-oauth-v2]. 355 Issued At The time at which the assertion was issued. While the 356 serialization may differ by assertion format, this is always 357 expressed in UTC with no time zone component. 359 Expires At The time at which the assertion expires. While the 360 serialization may differ by assertion format, this is always 361 expressed in UTC with no time zone component. 363 Assertion ID A nonce or unique identifier for the assertion. The 364 Assertion ID may be used by implementations requiring message de- 365 duplication for one-time use assertions. Any entity that assigns 366 an identifier MUST ensure that there is negligible probability 367 that that entity or any other entity will accidentally assign the 368 same identifier to a different data object. 370 5.2. General Assertion Format and Processing Rules 372 The following are general format and processing rules for the use of 373 assertions in OAuth: 375 o The assertion MUST contain an Issuer. The Issuer MUST identify 376 the entity that issued the assertion as recognized by the 377 Authorization Server. If an assertion is self-asserted, the 378 Issuer SHOULD be the "client_id". 380 o The assertion SHOULD contain a Principal. The Principal MUST 381 identify an authorized accessor for whom the access token is being 382 requested (typically the resource owner, or an authorized 383 delegate). When the client is acting on behalf of itself, the 384 Principal SHOULD be the "client_id". 386 o The assertion MUST contain an Audience that identifies the 387 Authorization Server as the intended audience. The Authorization 388 Server MUST verify that it is an intended audience for the 389 assertion. The Audience SHOULD be the URL of the Authorization 390 Server's Token Endpoint. 392 o The assertion MUST contain an Expires At entity that limits the 393 time window during which the assertion can be used. The 394 authorization server MUST verify that the expiration time has not 395 passed, subject to allowable clock skew between systems. The 396 authorization server SHOULD reject assertions with an Expires At 397 attribute value that is unreasonably far in the future. 399 o The assertion MAY contain an Issued At entity containing the UTC 400 time at which the assertion was issued. 402 o The assertion MAY contain an Assertion ID. An Authorization 403 Server MAY dictate that Assertion ID is mandatory. 405 o The Authorization Server MUST validate the assertion's signature 406 in order to verify the Issuer of the assertion. The algorithm 407 used to validate the assertion, and the mechanism for designating 408 the secret used to generate the assertion, are beyond the scope of 409 this specification. 411 6. Specific Assertion Format and Processing Rules 413 The following clarifies the format and processing rules defined in 414 Section 4 and Section 5 for a number of common use cases: 416 6.1. Client Authentication 418 When a client authenticates to a token service using an assertion, it 419 SHOULD do so according to Section 4.1. The following format and 420 processing rules apply. 422 o The "client_assertion_type" HTTP parameter MUST identify the 423 assertion format being used for authentication. 425 o The "client_assertion" HTTP parameter MUST contain the serialized 426 assertion in a format indicated by the "client_assertion_type" 427 parameter. 429 o The Principal SHOULD be the "client_id". 431 o The Issuer of the assertion MUST identify the entity that issued 432 the assertion as recognized by the Authorization Server. If the 433 assertion is self-asserted, the Issuer SHOULD be the "client_id". 435 o The Audience of the assertion MUST identify the Authorization 436 Server and SHOULD be the URL of the Token Endpoint. 438 o The Authorization Server MUST validate the assertion's signature 439 in order to verify the Issuer of the assertion. 441 The following non-normative example demonstrates the use of a client 442 authentication using an assertion during an Authorization Code Access 443 Token Request as defined in Section 4.1.3 of OAuth 2.0 444 [I-D.ietf-oauth-v2] (with line breaks for display purposes only): 445 POST /token HTTP/1.1 446 Host: server.example.com 447 Content-Type: application/x-www-form-urlencoded 449 grant_type=authorization_code& 450 code=i1WsRn1uB1& 451 client_id=s6BhdRkqt3& 452 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 453 %3Aclient-assertion-type%3Asaml2-bearer& 454 client_assertion=PHNhb...[omitted for brevity]...ZT4 456 6.2. Client Acting on Behalf of Itself 458 When a client is accessing resources on behalf of itself, it SHOULD 459 do so in a manner analogous to the Client Credentials flow defined in 460 Section 4.4 of OAuth 2.0 [I-D.ietf-oauth-v2]. This is a special case 461 that combines both the authentication and authorization grant usage 462 patterns. In this case, the interactions with the authorization 463 server SHOULD be treated as using an assertion for Client 464 Authentication according to Section 4.1, with the addition of a 465 grant_type parameter. The following format and processing rules 466 apply. 468 o The grant_type HTTP request parameter MUST be 469 "client_credentials". 471 o The "client_assertion_type" HTTP parameter MUST identify the 472 assertion format. 474 o The "client_assertion" HTTP parameter MUST contain the serialized 475 assertion as in a format indicated by the "client_assertion_type" 476 parameter. 478 o The Issuer of the assertion MUST identify the entity that issued 479 the assertion as recognized by the Authorization Server. If the 480 assertion is self-asserted, the Issuer SHOULD be the "client_id". 481 If the assertion was issued by a Security Token Service (STS), the 482 Issuer SHOULD identify the STS as recognized by the Authorization 483 Server. 485 o The Principal SHOULD be the "client_id". 487 o The Audience of the assertion MUST identify the Authorization 488 Server and SHOULD be the URL of the Token Endpoint. 490 o The Authorization Server MUST validate the assertion's signature 491 in order to verify the Issuer of the assertion. 493 The following non-normative example demonstrates the use of a sample 494 assertion being used for a Client Credentials Access Token Request as 495 defined in Section 4.4.2 of OAuth 2.0 [I-D.ietf-oauth-v2] (with line 496 breaks for display purposes only): 497 POST /token HTTP/1.1 498 Host: server.example.com 499 Content-Type: application/x-www-form-urlencoded 501 client_id=s6BhdRkqt3& 502 grant_type=client_credentials& 503 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth 504 %3Aclient-assertion-type%3Asaml2-bearer& 505 client_assertion=PHNhbW...[omitted for brevity]...ZT 507 6.3. Client Acting on Behalf of a User 509 When a client is accessing resources on behalf of a user, it SHOULD 510 be treated as using an assertion as an Authorization Grant according 511 to Section 4.2. The following format and processing rules apply. 513 o The grant_type HTTP request parameter MUST indicate the assertion 514 format. 516 o The assertion HTTP parameter MUST contain the serialized assertion 517 as in a format indicated by the grant_type parameter. 519 o The Issuer of the assertion MUST identify the entity that issued 520 the assertion as recognized by the Authorization Server. If the 521 assertion is self-asserted, the Issuer SHOULD be the "client_id". 522 If the assertion was issued by a Security Token Service (STS), the 523 Issuer SHOULD identify the STS as recognized by the Authorization 524 Server. 526 o The Principal MUST identify an authorized accessor for whom the 527 access token is being requested (typically the resource owner, or 528 an authorized delegate). 530 o The Audience of the assertion MUST identify the Authorization 531 Server and MAY be the URL of the Token Endpoint. 533 o The Authorization Server MUST validate the assertion's signature 534 in order to verify the Issuer of the assertion. 536 The following non-normative example demonstrates the use of a client 537 authenticating using an assertion during an Authorization Code Access 538 Token Request as defined in Section 4.1.3 of OAuth 2.0 539 [I-D.ietf-oauth-v2] (with line breaks for display purposes only): 540 POST /token HTTP/1.1 541 Host: server.example.com 542 Content-Type: application/x-www-form-urlencoded 544 client_id=s6BhdRkqt3& 545 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& 546 assertion=PHNhbWxwOl...[omitted for brevity]...ZT 548 6.4. Client Acting on Behalf of an Anonymous User 550 When a client is accessing resources on behalf of an anonymous user, 551 the following format and processing rules apply. 553 o The grant_type HTTP request parameter MUST indicate the assertion 554 format. 556 o The assertion HTTP parameter MUST contain the serialized assertion 557 as in a format indicated by the grant_type parameter. 559 o The Issuer of the assertion MUST identify the entity that issued 560 the assertion as recognized by the Authorization Server. If the 561 assertion is self-asserted, the Issuer SHOULD be the "client_id". 562 If the assertion was issued by a Security Token Service (STS), the 563 Issuer SHOULD identify the STS as recognized by the Authorization 564 Server. 566 o The Principal SHOULD indicate to the Authorization Server that the 567 client is acting on-behalf of an anonymous user as defined by the 568 Authorization Server. It is implied that authorization is based 569 upon additional criteria, such as additional attributes or claims 570 provided in the assertion. For example, a client may present an 571 assertion from a trusted issuer asserting that the bearer is over 572 18 via an included claim. In this case, no additional information 573 about the user's identity is included yet all the data needed to 574 issue an access token is present. 576 o The Audience of the assertion MUST identify the Authorization 577 Server and MAY be the URL of the Token Endpoint. 579 o The Authorization Server MUST validate the assertion's signature 580 in order to verify the Issuer of the assertion. 582 7. Security Considerations 584 Authorization Providers concerned with preventing replay attacks may 585 choose to implement using replay detection using a combination of the 586 Assertion ID and Issued At/Expires At attributes. Previously 587 processed assertions MAY be de-duped and rejected based on the 588 Assertion ID. The addition of the validity window relieves the 589 authorization server from maintaining an infinite state table of 590 processed assertion IDs. 592 Authorization Servers SHOULD consider the amount of information 593 exposed in error responses, and the risk associated with exposing 594 details of specific processing errors. In addition, Authorization 595 Servers SHOULD prevent timing attacks related to cryptographic 596 processing of the assertion. 598 There are no additional security considerations beyond those 599 described within OAuth 2.0 [I-D.ietf-oauth-v2], Section 11. 601 8. IANA Considerations 603 8.1. assertion Parameter Registration 605 The following is the parameter registration request, as defined in 606 The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol 607 [I-D.ietf-oauth-v2], for the "assertion" parameter: 609 o Parameter name: assertion 610 o Parameter usage location: client authentication, token request 612 o Change controller: IETF 614 o Specification document(s): [[this document]] 616 8.2. client_assertion Parameter Registration 618 The following is the parameter registration request, as defined in 619 The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol 620 [I-D.ietf-oauth-v2], for the "client_assertion" parameter: 622 o Parameter name: "client_assertion" 624 o Parameter usage location: client authentication, token request 626 o Change controller: IETF 628 o Specification document(s): [[this document]] 630 8.3. client_assertion_type Parameter Registration 632 The following is the parameter registration request, as defined in 633 The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol 634 [I-D.ietf-oauth-v2], for the "client_assertion_type" parameter: 636 o Parameter name: "client_assertion_type" 638 o Parameter usage location: client authentication, token request 640 o Change controller: IETF 642 o Specification document(s): [[this document]] 644 9. Normative References 646 [I-D.ietf-oauth-v2] 647 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 648 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 649 in progress), May 2012. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 Appendix A. Acknowledgements 656 The authors wish to thank the following people that have influenced 657 or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai, 658 Tony Nadalin, the authors of OAuth WRAP, and those in the OAuth 659 working group. 661 Appendix B. Document History 663 [[ to be removed by RFC editor before publication as an RFC ]] 665 draft-ietf-oauth-assertions-03 667 o updated reference to draft-ietf-oauth-v2 from -25 to -26 669 draft-ietf-oauth-assertions-02 671 o Added text about limited lifetime ATs and RTs per 672 http://www.ietf.org/mail-archive/web/oauth/current/msg08298.html. 674 o Changed the line breaks in some examples to avoid awkward 675 rendering to text format. Also removed encoded '=' padding from a 676 few examples because both known derivative specs, SAML and JWT, 677 omit the padding char in serialization/encoding. 679 o Remove section 7 on error responses and move that (somewhat 680 modified) content into subsections of section 4 broken up by 681 authn/authz per 682 http://www.ietf.org/mail-archive/web/oauth/current/msg08735.html. 684 o Rework the text about "MUST validate ... in order to establish a 685 mapping between ..." per 686 http://www.ietf.org/mail-archive/web/oauth/current/msg08872.html 687 and 688 http://www.ietf.org/mail-archive/web/oauth/current/msg08749.html. 690 o Change "The Principal MUST identify an authorized accessor. If 691 the assertion is self-issued, the Principal SHOULD be the 692 client_id" in 6.1 per 693 http://www.ietf.org/mail-archive/web/oauth/current/msg08873.html. 695 o Update reference in 4.1 to point to 2.3 (rather than 3.2) of 696 oauth-v2 (rather than self) 697 http://www.ietf.org/mail-archive/web/oauth/current/msg08874.html. 699 o Move the "Section 3 of" out of the xref to hopefully fix the link 700 in 4.1 and remove the client_id bullet from 4.2 per 701 http://www.ietf.org/mail-archive/web/oauth/current/msg08875.html. 703 o Add ref to Section 3.3 of oauth-v2 for scope definition and remove 704 some then redundant text per 705 http://www.ietf.org/mail-archive/web/oauth/current/msg08890.html. 707 o Change "The following format and processing rules SHOULD be 708 applied" to "The following format and processing rules apply" in 709 sections 6.x to remove conflicting normative qualification of 710 other normative statements per 711 http://www.ietf.org/mail-archive/web/oauth/current/msg08892.html. 713 o Add text the client_id must id the client to 4.1 and remove 714 similar text from other places per 715 http://www.ietf.org/mail-archive/web/oauth/current/msg08893.html. 717 o Remove the MUST from the text prior to the HTTP parameter 718 definitions per 719 http://www.ietf.org/mail-archive/web/oauth/current/msg08920.html. 721 o Updated examples to use grant_type and client_assertion_type 722 values from the OAuth SAML Assertion Profiles spec. 724 Authors' Addresses 726 Chuck Mortimore (editor) 727 Salesforce.com 729 Email: cmortimore@salesforce.com 731 Michael B. Jones 732 Microsoft 734 Email: mbj@microsoft.com 736 Brian Campbell 737 Ping Identity Corp. 739 Email: brian.d.campbell@gmail.com 740 Yaron Y. Goland 741 Microsoft 743 Email: yarong@microsoft.com