idnits 2.17.1 draft-mortimore-oauth-assertions-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2011) is 4690 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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: December 18, 2011 MSFT 6 B. Campbell 7 Ping 8 Y. Goland 9 MSFT 10 June 16, 2011 12 OAuth 2.0 Assertion Profile 13 draft-mortimore-oauth-assertions-00 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 messsage 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 December 18, 2011. 49 Copyright Notice 51 Copyright (c) 2011 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.2. Using Assertions as Authorization Grants . . . . . . . . . 5 72 5. Assertion Content and Proccessing . . . . . . . . . . . . . . 6 73 5.1. Assertion Metamodel . . . . . . . . . . . . . . . . . . . 7 74 5.2. General Assertion Format and Processing Rules . . . . . . 8 75 6. Specific Assertion Format and Processing Rules . . . . . . . . 8 76 6.1. Client authentication . . . . . . . . . . . . . . . . . . 9 77 6.2. Client acting on behalf of itself . . . . . . . . . . . . 9 78 6.3. Client acting on behalf of a user . . . . . . . . . . . . 11 79 6.4. Client acting on behalf of an anonymous user . . . . . . . 12 80 7. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 13 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 10. Normative References . . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Requirements Notation and Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119] . 92 Throughout this document, values are quoted to indicate that they are 93 to be taken literally. When using these values in protocol messages, 94 the quotes MUST NOT be used as part of the value. 96 2. Overview 98 The OAuth 2.0 Authorization Protocol [I-D.ietf.oauth-v2] provides a 99 method for making authenticated HTTP requests to a resource using an 100 access token. Access tokens are issued to clients by an 101 authorization server with the (sometimes implicit) approval of the 102 resource owner. These access tokens are typically obtained by 103 exchanging an authorization grant representing authorization by the 104 resource owner or privliged administrator. Several authorization 105 grant types are defined to support a wide range of client types and 106 user experiences. OAuth also allows for the definition of new 107 extension grant types to support additional clients or to provide a 108 bridge between OAuth and other trust frameworks. Finally, OAuth 109 allows the definition of additional authentication mechanisms to be 110 used by clients when interacting with the authorization server. 112 In scenarios where security is at a premium one wants to avoid 113 sending secrets across the Internet, even on encrypted connections. 114 Instead one wants to send values derived from the secret that prove 115 to the receiver that the sender is in possession of the secret 116 without actually sending the secret. Typically the way derived 117 values are created is by generating an assertion that is then either 118 HMAC'd or digitally signed using an agreed upon secret. By 119 validating the HMAC or digital signature on the assertion, the 120 receiver can prove to themselves that the entity that generated the 121 assertion was in possession of the secret without actually 122 communicating the secret directly. 124 This specification provides a general framework for the use of 125 assertions as client credentials and/or authorization grants with 126 OAuth 2.0. It includes a generic mechanism for transporting 127 assertions during interactions with a token endpoint, as wells as 128 rules for the content and processing of those assertions. The intent 129 is to provide an enhanced security profile by using derived values 130 such as signatures or HMACs, as well as facilitate the use of OAuth 131 2.0 in client-server integration scenarios where the end-user may not 132 be present. 134 This specification only defines abstract messsage flow and assertion 135 content. Actual use requires implementation of a companion protocol 136 binding specification. Additional profile documents provide standard 137 representations in formats such as SAML and JWT. 139 3. Authentication vs Authorization 141 This specification provides a model for using assertions for 142 authentication of an OAuth client during interactions with an 143 Authorization Server, as well as the use of assertions as 144 authorization grants. It is important to note that the use of 145 assertions for client authentication is orthogonal and separable from 146 using assertions as an authorization grant and can be used either in 147 combination or in isolation. In addition, in scenarios when 148 assertion based authentication and authorization are used in 149 combination, the assertion format and processing may be redundant; 150 under such circumstances, the protocol may be optimized to present a 151 single assertion. 153 4. Transporting Assertions 155 This section defines generic HTTP parameters for transporting 156 assertions during interactions with a token endpoint. 158 4.1. Using Assertions for Client Authentication 160 In scenarios where one wants to avoid sending secrets, one wants to 161 send values derived from the secret that prove to the receiver that 162 the sender is in possession of the secret without actually sending 163 the secret. 165 For example, a client can establish a secret using an out-of-band 166 mechanism with a resource server. As part of this out-of-band 167 communication the client and resource server agree that the client 168 will authenticate itself using an assertion with agreed upon 169 parameters that will be signed by the provisioned secret. Later on, 170 the client might send an access token request to the token endpoint 171 for the resource server that includes an authorization code, as well 172 as a client_assertion that is signed with the previously agreed key 173 and parameters. The client_assertion proves to the token endpoint 174 the identity of the client and the authorization code provides the 175 link to the end-user authorization. 177 The following section defines the use of assertions as client 178 credentials as an extension of Section 3.2 of OAuth 2.0 179 [I-D.ietf.oauth-v2]. When using assertions as client credentials, 180 the client MUST include the assertion using the following HTTP 181 request parameters: 183 client_id REQUIRED. The client identifier as described in Section 3 184 of OAuth 2.0 [I-D.ietf.oauth-v2]. 186 client_assertion_type REQUIRED. The format of the assertion as 187 defined by the authorization server. The value MUST be an 188 absolute URI. 190 client_assertion REQUIRED. The assertion being used to authenticate 191 the client. Specific serialization of the assertion is defined by 192 profile documents. The serialization MUST be encoded for 193 transport within HTTP forms. It is RECOMMENDED that base64url be 194 used. 196 The following non-normative example demonstrates a client 197 authenticating using an assertion during a Authorization Code Access 198 Token Request as defined in Section 4.1.3 of OAuth 2.0 199 [I-D.ietf.oauth-v2]. (line breaks are for display purposes only): 200 POST /token HTTP/1.1 201 Host: server.example.com 202 Content-Type: application/x-www-form-urlencoded 204 grant_type=authorization_code& 205 code=i1WsRn1uB1& 206 client_id=s6BhdRkqt3& 207 client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 208 client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT 210 The client MUST NOT include the client_credential using more than one 211 mechanism. Token endpoints can differentiate between client 212 assertion credentials and other client credential types by looking 213 for the presence of the client_assertion and client_assertion_type 214 attributes which will only be present with client assertion 215 credentials. See section 7 for more details 217 4.2. Using Assertions as Authorization Grants 219 An assertion can be used to request an access token when a client 220 wishes to utilize an existing trust relationship. This may be done 221 through the semantics of (and a digital signature/HMAC calculated 222 over) the assertion, without direct user approval at the 223 authorization server, and expressed through an extension 224 authorization grant type. The processes by which authorization is 225 previously granted, and by which the client obtains the assertion 226 prior to exchanging it with the authorization server, are out of 227 scope. 229 The following defines the use of assertions as authorization grants 230 as an extension of OAuth 2.0 [I-D.ietf.oauth-v2], section 4.5. When 231 using assertions as authorization grants, the client MUST include the 232 assertion using the following HTTP request parameters: 234 client_id REQUIRED. The client identifier as described in Section 3 235 of OAuth 2.0 [I-D.ietf.oauth-v2]. 237 grant_type REQUIRED. The format of the assertion as defined by the 238 authorization server. The value MUST be an absolute URI. 240 assertion REQUIRED. The assertion being used as an authorization 241 grant. Specific serialization of the assertion is defined by 242 profile documents. The serialization MUST be encoded for 243 transport within HTTP forms. It is RECOMMENDED that base64url be 244 used. 246 scope OPTIONAL. The request MAY contain a "scope" parameter. The 247 scope of the access request is expressed as a list of space- 248 delimited strings. The value is defined by the authorization 249 server. If the value contains multiple space- delimited strings, 250 their order does not matter, and each string adds an additional 251 access range to the requested scope. When exchanging assertions 252 for access_tokens, the authorization for the token has been 253 previously granted through some other mechanism. As such, the 254 requested scope SHOULD be equal or lesser than the scope 255 originally granted to the authorized accessor. If the scope 256 parameter and/or value is omitted, the scope SHOULD be treated as 257 equal to the scope originally granted to the authorized accessor. 258 The Authorization Server SHOULD limit the scope of the issued 259 access token to be equal or lesser than the scope originally 260 granted to the authorized accessor. 262 The following non-normative example demonstrates an assertion being 263 used as an authorization grant. (line breaks are for display purposes 264 only): 265 POST /token HTTP/1.1 266 Host: server.example.com 267 Content-Type: application/x-www-form-urlencoded 269 client_id=s6BhdRkqt3& 270 grant_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 271 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 273 5. Assertion Content and Proccessing 275 This section provides a general content and processing model for the 276 use of assertions in OAuth 2.0 [I-D.ietf.oauth-v2]. 278 5.1. Assertion Metamodel 280 The following are entities and metadata involved in the issuance, 281 exchange and processing of assertions in OAuth 2.0. These are 282 general terms, abstract from any particular assertion format. 283 Mappings of these terms into specific representations are provided by 284 profiles of this specification. 286 Issuer The unique identifier for the entity that issued the 287 assertion. Generally this is the entity that holds the keying 288 material used to generate the assertion. In some use-cases 289 Issuers may be either OAuth Clients (when assertions are self- 290 asserted ) or a Security Token Service (an entity capable of 291 issuing, renewing, transforming and validating of security 292 tokens). 294 Principal A unique identifier for the subject of the assertion. 295 When using assertions for client authentication, the Principal 296 SHOULD be the client_id of the OAuth client. When using 297 assertions as an authorization grant, the Principal MUST identify 298 an authorized accessor for whom the access token is being 299 requested (typically the resource owner, or an authorized 300 delegate). 302 Audience A URI that identifies the Authorization Server as the 303 intended audience. The audience SHOULD be the URL of the Token 304 Endpoint as defined in section 2.2 of OAuth 2.0 305 [I-D.ietf.oauth-v2]. 307 Issued At The time at which the assertion was issued. While the 308 serialization may differ by assertion format, this is always 309 expressed in UTC with no time zone component. 311 Expires At The time at which the assertion expires. While the 312 serialization may differ by assertion format, this is always 313 expressed in UTC with no time zone component. 315 Assertion ID A nonce or unique identifier for the assertion. The 316 Assertion ID may be used by implementations requiring message de- 317 duplication for one-time use assertions. Any entity that assigns 318 an identifier MUST ensure that there is negligible probability 319 that that entity or any other entity will accidentally assign the 320 same identifier to a different data object. 322 5.2. General Assertion Format and Processing Rules 324 The following are general format and processing rules for the use of 325 assertions in OAuth: 327 o The assertion MUST contain an Issuer. The Issuer MUST identify 328 the entity that issued the assertion as recognized by the 329 Authorization Server. If an assertion is self-asserted, the 330 Issuer SHOULD be the client_id. 332 o The assertion SHOULD contain a Principal. The Principal MUST 333 identify an authorized accessor for whom the access token is being 334 requested ( typically the resource owner, or an authorized 335 delegate ) When the client is acting on behalf of itself, the 336 Principal SHOULD be the client_id. 338 o The assertion MUST contain an Audience that identifies the 339 Authorization Server as the intended audience. The Authorization 340 Server MUST verify that it is an intended audience for the 341 assertion. The Audience SHOULD be the URL of the Authorization 342 Server's Token Endpoint. 344 o The assertion MUST contain an Expires At entity that limits the 345 time window during which the assertion can be used. The 346 authorization server MUST verify that the expiration time has not 347 passed, subject to allowable clock skew between systems. The 348 authorization server SHOULD reject assertions with an Expires At 349 attribute value that is unreasonably far in the future. 351 o The assertion MAY contain an Issued At entity containing the UTC 352 time at which the assertion was issued. 354 o The assertion MAY contain a Assertion ID. An Authorization Server 355 MAY dictate that Assertion ID is mandatory. 357 o The Authorization Server MUST validate the assertion in order to 358 establish a mapping between the Issuer and the secret used to 359 generate the assertion. The algortihm used to validate the 360 assertion, and the mechanism for designating the secret used to 361 generate assertion is out-of-scope for this specification. 363 6. Specific Assertion Format and Processing Rules 365 The following clarifies the format and processing rules defined in 366 section 4 and section 5 for a number of common use-cases: 368 6.1. Client authentication 370 When a client authenticates to a token service using an assertion, it 371 SHOULD do so according to section 4.1. The following format and 372 processing rules SHOULD be applied: 374 o The client_id HTTP parameter MUST identify the client to the 375 authorization server. 377 o The client_assertion_type HTTP parameter MUST identify the 378 assertion format being used for authentication. 380 o The client_assertion HTTP parameter MUST contain the serialized 381 assertion as in a format indicated by the client_assertion_type 382 parameter. 384 o The Issuer of the assertion MUST identify the entity that issued 385 the assertion as recognized by the Authorization Server. If the 386 assertion is self-asserted, the Issuer SHOULD be the client_id. 388 o The Principal MUST identify an authorized accessor. If the 389 assertion is self-issued, the Principal SHOULD be the client_id. 391 o The Audience of the assertion MUST identify the Authorization 392 Server and SHOULD be the URL of the Token Endpoint. 394 o The Authorization Server MUST validate the assertion in order to 395 establish a mapping between the Issuer and the secret used to 396 generate the assertion. 398 The following non-normative example demonstrates the use of a client 399 authenticating using an assertion during a Authorization Code Access 400 Token Request as defined in Section 4.1.3 of OAuth 2.0 401 [I-D.ietf.oauth-v2]. (line breaks are for display purposes only): 402 POST /token HTTP/1.1 403 Host: server.example.com 404 Content-Type: application/x-www-form-urlencoded 406 grant_type=authorization_code& 407 code=i1WsRn1uB1& 408 client_id=s6BhdRkqt3& 409 client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 410 client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 412 6.2. Client acting on behalf of itself 414 When a client is accessing resources on behalf of itself, it SHOULD 415 do so in a manner analagous to the Client Credentials flow defined in 416 Section 4.4 of OAuth 2.0 [I-D.ietf.oauth-v2]. This is a special case 417 that combines both the authentication and authorization grant usage 418 patterns. In this case, the interactions with the authorization 419 server SHOULD be treated as using an assertion for Client 420 Authentication according to section 4.1, with the addition of a 421 grant_type parameter. The following format and processing rules 422 SHOULD be applied. 424 o The client_id HTTP parameter MUST identify the client to the 425 authorization server. 427 o The grant_type HTTP request parameter MUST be 428 "client_credentials". 430 o The client_assertion_type HTTP parameter MUST identify the 431 assertion format. 433 o The client_assertion HTTP parameter MUST contain the serialized 434 assertion as in a format indicated by the client_assertion_type 435 parameter. 437 o The Issuer of the assertion MUST identify the entity that issued 438 the assertion as recognized by the Authorization Server. If the 439 assertion is self-asserted, the Issuer SHOULD be the client_id. 440 If the assertion was issued by a Security Token Service, the 441 Issuer SHOULD identify the STS as recognized by the Authorization 442 Server. 444 o The Principal SHOULD be the client_id. 446 o The Audience of the assertion MUST identify the Authorization 447 Server and SHOULD be the URL of the Token Endpoint. 449 o The Authorization Server MUST validate the assertion in order to 450 establish a mapping between the Issuer and the secret used to 451 generate the assertion. 453 The following non-normative example demonstrates the use of a sample 454 assertion being used for a Client Credentials Access Token Request as 455 defined in Section 4.4.2 of OAuth 2.0 [I-D.ietf.oauth-v2]. (line 456 breaks are for display purposes only): 458 POST /token HTTP/1.1 459 Host: server.example.com 460 Content-Type: application/x-www-form-urlencoded 462 client_id=s6BhdRkqt3& 463 grant_type=client_credentials& 464 client_assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 465 client_assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D 467 6.3. Client acting on behalf of a user 469 When a client is accessing resources on behalf of a user, it SHOULD 470 be treated as using an assertion as an Authorization Grant according 471 to section 4.2. The following format and processing rules SHOULD be 472 applied: 474 o The client_id HTTP parameter MUST identify the client to the 475 authorization server. 477 o The grant_type HTTP request parameter MUST indicate the assertion 478 format. 480 o The assertion HTTP parameter MUST contain the serialized assertion 481 as in a format indicated by the grant_type parameter. 483 o The Issuer of the assertion MUST identify the entity that issued 484 the assertion as recognized by the Authorization Server. If the 485 assertion is self-asserted, the Issuer SHOULD be the client_id. 486 If the assertion was issued by a STS, the Issuer SHOULD identify 487 the STS as recognized by the Authorization Server. 489 o The Principal MUST identify an authorized accessor for whom the 490 access token is being requested (typically the resource owner, or 491 an authorized delegate). 493 o The Audience of the assertion MUST identify the Authorization 494 Server and MAY be the URL of the Token Endpoint. 496 o The Authorization Server MUST validate the assertion in order to 497 establish a mapping between the Issuer and the secret used to 498 generate the assertion. 500 The following non-normative example demonstrates the use of a client 501 authenticating using an assertion during a Authorization Code Access 502 Token Request as defined in Section 4.1.3 of OAuth 2.0 503 [I-D.ietf.oauth-v2]. (line breaks are for display purposes only): 505 POST /token HTTP/1.1 506 Host: server.example.com 507 Content-Type: application/x-www-form-urlencoded 509 client_id=s6BhdRkqt3& 510 grant_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& 511 assertion=PHNhbWxwOl...[omitted for brevity]...ZT4%3D 513 6.4. Client acting on behalf of an anonymous user 515 When a client is accessing resources on behalf of an anonymous user, 516 the following format and processing rules SHOULD be applied: 518 o The client_id HTTP parameter MUST identify the client to the 519 authorization server. 521 o The grant_type HTTP request parameter MUST indicate the assertion 522 format. 524 o The assertion HTTP parameter MUST contain the serialized assertion 525 as in a format indicated by the grant_type parameter. 527 o The Issuer of the assertion MUST identify the entity that issued 528 the assertion as recognized by the Authorization Server. If the 529 assertion is self-asserted, the Issuer SHOULD be the client_id. 530 If the assertion was issued by a Security Token Service, the 531 Issuer SHOULD identify the STS as recognized by the Authorization 532 Server. 534 o The Principal SHOULD indicate to the Authorization Server that the 535 client is acting on-behalf of an anonymous user as defined by the 536 Authorization Server. It is implied that authorizaion is based 537 upon additional criteria, such as additional attributes or claims 538 provided in the assertion. For example, a client may present an 539 assertion from a trusted issuer asserting that the bearer is over 540 18 via an included claim. In this case, no additional information 541 about the user's identity is included yet all the data needed to 542 issue an access token is present. 544 o The Audience of the assertion MUST identify the Authorization 545 Server and MAY be the URL of the Token Endpoint. 547 o The Authorization Server MUST validate the assertion in order to 548 establish a mapping between the Issuer and the secret used to 549 generate the assertion. 551 7. Error Responses 553 If an assertion is not valid or has expired, the Authorization Server 554 MUST construct an error response as defined in OAuth 2.0 555 [I-D.ietf.oauth-v2]. The value of the error parameter MUST be the 556 "invalid_grant" error code. The authorization server MAY include 557 additional information regarding the reasons the assertion was 558 considered invalid using the "error_description" or "error_uri" 559 parameters. 561 For example: 562 HTTP/1.1 400 Bad Request 563 Content-Type: application/json 564 Cache-Control: no-store 566 { 567 "error":"invalid_grant", 568 "error_description":"Audience validation failed" 569 } 571 A client MUST NOT include client credentials using more than one 572 mechanism. Token endpoints can differentiate between assertion based 573 credentials and other client credential types by looking for the 574 presence of the client_assertion and client_assertion_type attributes 575 which will only be present when using assertions for client 576 authentication. If more than one mechanism is used, the 577 Authorization Server MUST construct an error response as defined in 578 OAuth 2.0 [I-D.ietf.oauth-v2]. The value of the error parameter MUST 579 be the "invalid_client" error code. The authorization server MAY 580 include additional information regarding the reasons the client was 581 considered invalid using the "error_description" or "error_uri" 582 parameters. 584 For example: 585 HTTP/1.1 400 Bad Request 586 Content-Type: application/json 587 Cache-Control: no-store 589 { 590 "error":"invalid_client" 591 "error_description":"Multiple Credentials Not Allowed" 592 } 594 8. Security Considerations 596 No additional considerations beyond those described within the OAuth 597 2.0 Protocol Framework [I-D.ietf.oauth-v2]. 599 9. Acknowledgements 601 The authors wish to thank the following people that have influenced 602 or contributed this specification: Paul Madsen, Eric Sachs, Jian Cai, 603 Tony Nadlin, the authors of OAuth WRAP, and those in the OAuth 2 604 working group. 606 10. Normative References 608 [I-D.ietf.oauth-v2] 609 Hammer-Lahav, E., "The OAuth 2.0 Authorization Protocol", 610 April 2011. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 Authors' Addresses 617 Chuck Mortimore (editor) 618 Salesforce.com 620 Email: cmortimore@salesforce.com 622 Michael B. Jones 623 Microsoft 625 Email: mbj@microsoft.com 627 Brian Campbell 628 Ping Identity 630 Email: bcampbell@pingidentity.com 632 Yaron Goland 633 Microsoft 635 Email: yarong@microsoft.com