idnits 2.17.1 draft-ietf-oauth-jwt-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 (July 23, 2014) is 3562 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) ** Downref: Normative reference to an Informational RFC: RFC 6755 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-30) exists of draft-ietf-oauth-dyn-reg-16 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track B. Campbell 5 Expires: January 24, 2015 Ping Identity 6 C. Mortimore 7 Salesforce 8 July 23, 2014 10 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and 11 Authorization Grants 12 draft-ietf-oauth-jwt-bearer-10 14 Abstract 16 This specification defines the use of a JSON Web Token (JWT) Bearer 17 Token as a means for requesting an OAuth 2.0 access token as well as 18 for use as a means of client authentication. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 24, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4 58 2.1. Using JWTs as Authorization Grants . . . . . . . . . . . 4 59 2.2. Using JWTs for Client Authentication . . . . . . . . . . 5 60 3. JWT Format and Processing Requirements . . . . . . . . . . . 5 61 3.1. Authorization Grant Processing . . . . . . . . . . . . . 7 62 3.2. Client Authentication Processing . . . . . . . . . . . . 8 63 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8 64 5. Interoperability Considerations . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Sub-Namespace Registration of urn:ietf:params:oauth 69 :grant-type:jwt-bearer . . . . . . . . . . . . . . . . . 10 70 8.2. Sub-Namespace Registration of urn:ietf:params:oauth 71 :client-assertion-type:jwt-bearer . . . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 76 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON) 82 [RFC7159] based security token encoding that enables identity and 83 security information to be shared across security domains. A 84 security token is generally issued by an identity provider and 85 consumed by a relying party that relies on its content to identify 86 the token's subject for security related purposes. 88 The OAuth 2.0 Authorization Framework [RFC6749] provides a method for 89 making authenticated HTTP requests to a resource using an access 90 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 Assertion Framework for OAuth 2.0 Client Authentication and 104 Authorization Grants [I-D.ietf-oauth-assertions] specification is an 105 abstract extension to OAuth 2.0 that provides a general framework for 106 the use of Assertions (a.k.a. Security Tokens) as client credentials 107 and/or authorization grants with OAuth 2.0. This specification 108 profiles the Assertion Framework for OAuth 2.0 Client Authentication 109 and Authorization Grants [I-D.ietf-oauth-assertions] specification to 110 define an extension grant type that uses a JSON Web Token (JWT) 111 Bearer Token to request an OAuth 2.0 access token as well as for use 112 as client credentials. The format and processing rules for the JWT 113 defined in this specification are intentionally similar, though not 114 identical, to those in the closely related SAML 2.0 Profile for OAuth 115 2.0 Client Authentication and Authorization Grants 116 [I-D.ietf-oauth-saml2-bearer] specification. 118 This document defines how a JSON Web Token (JWT) Bearer Token can be 119 used to request an access token when a client wishes to utilize an 120 existing trust relationship, expressed through the semantics of (and 121 digital signature or keyed message digest calculated over) the JWT, 122 without a direct user approval step at the authorization server. It 123 also defines how a JWT can be used as a client authentication 124 mechanism. The use of a security token for client authentication is 125 orthogonal to and separable from using a security token as an 126 authorization grant. They can be used either in combination or 127 separately. Client authentication using a JWT is nothing more than 128 an alternative way for a client to authenticate to the token endpoint 129 and must be used in conjunction with some grant type to form a 130 complete and meaningful protocol request. JWT authorization grants 131 may be used with or without client authentication or identification. 132 Whether or not client authentication is needed in conjunction with a 133 JWT authorization grant, as well as the supported types of client 134 authentication, are policy decisions at the discretion of the 135 authorization server. 137 The process by which the client obtains the JWT, prior to exchanging 138 it with the authorization server or using it for client 139 authentication, is out of scope. 141 1.1. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 Unless otherwise noted, all the protocol parameter names and values 148 are case sensitive. 150 1.2. Terminology 152 All terms are as defined in The OAuth 2.0 Authorization Framework 153 [RFC6749], the Assertion Framework for OAuth 2.0 Client 154 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 155 and the JSON Web Token (JWT) [JWT] specifications. 157 2. HTTP Parameter Bindings for Transporting Assertions 159 The Assertion Framework for OAuth 2.0 Client Authentication and 160 Authorization Grants [I-D.ietf-oauth-assertions] specification 161 defines generic HTTP parameters for transporting Assertions (a.k.a. 162 Security Tokens) during interactions with a token endpoint. This 163 section defines specific parameters and treatments of those 164 parameters for use with JWT bearer tokens. 166 2.1. Using JWTs as Authorization Grants 168 To use a Bearer JWT as an authorization grant, use an access token 169 request as defined in Section 4 of the Assertion Framework for OAuth 170 2.0 Client Authentication and Authorization Grants 171 [I-D.ietf-oauth-assertions] specification with the following specific 172 parameter values and encodings. 174 The value of the "grant_type" parameter MUST be 175 "urn:ietf:params:oauth:grant-type:jwt-bearer". 177 The value of the "assertion" parameter MUST contain a single JWT. 179 The "scope" parameter may be used, as defined in the Assertion 180 Framework for OAuth 2.0 Client Authentication and Authorization 181 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 182 requested scope. 184 Authentication of the client is optional, as described in 185 Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the 186 "client_id" is only needed when a form of client authentication that 187 relies on the parameter is used. 189 The following non-normative example demonstrates an Access Token 190 Request with a JWT as an authorization grant (with extra line breaks 191 for display purposes only): 193 POST /token.oauth2 HTTP/1.1 194 Host: as.example.com 195 Content-Type: application/x-www-form-urlencoded 197 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 198 &assertion=eyJhbGciOiJFUzI1NiJ9. 199 eyJpc3Mi[...omitted for brevity...]. 200 J9l-ZhwP[...omitted for brevity...] 202 2.2. Using JWTs for Client Authentication 204 To use a JWT Bearer Token for client authentication, use the 205 following parameter values and encodings. 207 The value of the "client_assertion_type" parameter MUST be 208 "urn:ietf:params:oauth:client-assertion-type:jwt-bearer". 210 The value of the "client_assertion" parameter MUST contain a single 211 JWT. 213 The following non-normative example demonstrates client 214 authentication using a JWT during the presentation of an 215 authorization code grant in an Access Token Request (with extra line 216 breaks for display purposes only): 218 POST /token.oauth2 HTTP/1.1 219 Host: as.example.com 220 Content-Type: application/x-www-form-urlencoded 222 grant_type=authorization_code& 223 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 224 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A 225 client-assertion-type%3Ajwt-bearer& 226 client_assertion=eyJhbGciOiJSUzI1NiJ9. 227 eyJpc3Mi[...omitted for brevity...]. 228 cC4hiUPo[...omitted for brevity...] 230 3. JWT Format and Processing Requirements 232 In order to issue an access token response as described in OAuth 2.0 233 [RFC6749] or to rely on a JWT for client authentication, the 234 authorization server MUST validate the JWT according to the criteria 235 below. Application of additional restrictions and policy are at the 236 discretion of the authorization server. 238 1. The JWT MUST contain an "iss" (issuer) claim that contains a 239 unique identifier for the entity that issued the JWT. In the 240 absence of an application profile specifying otherwise, 241 compliant applications MUST compare Issuer values using the 242 Simple String Comparison method defined in Section 6.2.1 of RFC 243 3986 [RFC3986]. 245 2. The JWT MUST contain a "sub" (subject) claim identifying the 246 principal that is the subject of the JWT. Two cases need to be 247 differentiated: 249 A. For the authorization grant, the subject typically 250 identifies an authorized accessor for which the access token 251 is being requested (i.e., the resource owner or an 252 authorized delegate), but in some cases, may be a 253 pseudonymous identifier or other value denoting an anonymous 254 user. 256 B. For client authentication, the subject MUST be the 257 "client_id" of the OAuth client. 259 3. The JWT MUST contain an "aud" (audience) claim containing a 260 value that identifies the authorization server as an intended 261 audience. The token endpoint URL of the authorization server 262 MAY be used as a value for an "aud" element to identify the 263 authorization server as an intended audience of the JWT. JWTs 264 that do not identify the authorization server as an intended 265 audience MUST be rejected. In the absence of an application 266 profile specifying otherwise, compliant applications MUST 267 compare the audience values using the Simple String Comparison 268 method defined in Section 6.2.1 of RFC 3986 [RFC3986]. 270 4. The JWT MUST contain an "exp" (expiration) claim that limits the 271 time window during which the JWT can be used. The authorization 272 server MUST verify that the expiration time has not passed, 273 subject to allowable clock skew between systems, and reject 274 expired JWTs. The authorization server MAY reject JWTs with an 275 "exp" claim value that is unreasonably far in the future. 277 5. The JWT MAY contain an "nbf" (not before) claim that identifies 278 the time before which the token MUST NOT be accepted for 279 processing. 281 6. The JWT MAY contain an "iat" (issued at) claim that identifies 282 the time at which the JWT was issued. The authorization server 283 MAY reject JWTs with an "iat" claim value that is unreasonably 284 far in the past. 286 7. The JWT MAY contain a "jti" (JWT ID) claim that provides a 287 unique identifier for the token. The authorization server MAY 288 ensure that JWTs are not replayed by maintaining the set of used 289 "jti" values for the length of time for which the JWT would be 290 considered valid based on the applicable "exp" instant. 292 8. The JWT MAY contain other claims. 294 9. The JWT MUST be digitally signed or have a keyed message digest 295 applied by the issuer. The authorization server MUST reject 296 JWTs with an invalid signature or keyed message digest. 298 10. The authorization server MUST verify that the JWT is valid in 299 all other respects per JSON Web Token (JWT) [JWT]. 301 3.1. Authorization Grant Processing 303 JWT authorization grants may be used with or without client 304 authentication or identification. Whether or not client 305 authentication is needed in conjunction with a JWT authorization 306 grant, as well as the supported types of client authentication, are 307 policy decisions at the discretion of the authorization server. 308 However, if client credentials are present in the request, the 309 authorization server MUST validate them. 311 If the JWT is not valid, or the current time is not within the 312 token's valid time window for use, the authorization server MUST 313 construct an error response as defined in OAuth 2.0 [RFC6749]. The 314 value of the "error" parameter MUST be the "invalid_grant" error 315 code. The authorization server MAY include additional information 316 regarding the reasons the JWT was considered invalid using the 317 "error_description" or "error_uri" parameters. 319 For example: 321 HTTP/1.1 400 Bad Request 322 Content-Type: application/json 323 Cache-Control: no-store 325 { 326 "error":"invalid_grant", 327 "error_description":"Audience validation failed" 328 } 330 3.2. Client Authentication Processing 332 If the client JWT is not valid, the authorization server MUST 333 construct an error response as defined in OAuth 2.0 [RFC6749]. The 334 value of the "error" parameter MUST be the "invalid_client" error 335 code. The authorization server MAY include additional information 336 regarding the reasons the JWT was considered invalid using the 337 "error_description" or "error_uri" parameters. 339 4. Authorization Grant Example 341 Though non-normative, the following examples illustrate what a 342 conforming JWT and access token request would look like. 344 The example shows a JWT issued and signed by the system entity 345 identified as "https://jwt-idp.example.com". The subject of the JWT 346 is identified by email address as "mike@example.com". The intended 347 audience of the JWT is "https://jwt-rp.example.net", which is an 348 identifier with which the authorization server identifies itself. 349 The JWT is sent as part of an access token request to the 350 authorization server's token endpoint at "https://authz.example.net/ 351 token.oauth2". 353 Below is an example JSON object that could be encoded to produce the 354 JWT Claims Object for a JWT: 356 {"iss":"https://jwt-idp.example.com", 357 "sub":"mailto:mike@example.com", 358 "aud":"https://jwt-rp.example.net", 359 "nbf":1300815780, 360 "exp":1300819380, 361 "http://claims.example.com/member":true} 363 The following example JSON object, used as the header of a JWT, 364 declares that the JWT is signed with the ECDSA P-256 SHA-256 365 algorithm. 367 {"alg":"ES256"} 369 To present the JWT with the claims and header shown in the previous 370 example as part of an access token request, for example, the client 371 might make the following HTTPS request (with extra line breaks for 372 display purposes only): 374 POST /token.oauth2 HTTP/1.1 375 Host: authz.example.net 376 Content-Type: application/x-www-form-urlencoded 378 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 379 &assertion=eyJhbGciOiJFUzI1NiJ9. 380 eyJpc3Mi[...omitted for brevity...]. 381 J9l-ZhwP[...omitted for brevity...] 383 5. Interoperability Considerations 385 Agreement between system entities regarding identifiers, keys, and 386 endpoints is required in order to achieve interoperable deployments 387 of this profile. Specific items that require agreement are as 388 follows: values for the issuer and audience identifiers, the location 389 of the token endpoint, the key used to apply and verify the digital 390 signature or keyed message digest over the JWT, one-time use 391 restrictions on JWT, maximum JWT lifetime allowed, and the specific 392 subject and claim requirements of the JWT. The exchange of such 393 information is explicitly out of scope for this specification. In 394 some cases, additional profiles may be created that constrain or 395 prescribe these values or specify how they are to be exchanged. 396 Examples of such profiles include the OAuth 2.0 Dynamic Client 397 Registration Core Protocol [I-D.ietf-oauth-dyn-reg], OpenID Connect 398 Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID 399 Connect Discovery 1.0 [OpenID.Discovery]. 401 6. Security Considerations 403 The security considerations described within the Assertion Framework 404 for OAuth 2.0 Client Authentication and Authorization Grants 405 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 406 [RFC6749], and the JSON Web Token (JWT) [JWT] specifications are all 407 applicable to this document. 409 The specification does not mandate replay protection for the JWT 410 usage for either the authorization grant or for client 411 authentication. It is an optional feature, which implementations may 412 employ at their own discretion. 414 7. Privacy Considerations 416 A JWT may contain privacy-sensitive information and, to prevent 417 disclosure of such information to unintended parties, should only be 418 transmitted over encrypted channels, such as TLS. In cases where it 419 is desirable to prevent disclosure of certain information the client, 420 the JWT should be be encrypted to the authorization server. 422 Deployments should determine the minimum amount of information 423 necessary to complete the exchange and include only such claims in 424 the JWT. In some cases, the "sub" (subject) claim can be a value 425 representing an anonymous or pseudonymous user, as described in 426 Section 6.3.1 of the Assertion Framework for OAuth 2.0 Client 427 Authentication and Authorization Grants [I-D.ietf-oauth-assertions]. 429 8. IANA Considerations 431 8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- 432 type:jwt-bearer 434 This specification registers the value "grant-type:jwt-bearer" in the 435 IANA urn:ietf:params:oauth registry established in An IETF URN Sub- 436 Namespace for OAuth [RFC6755]. 438 o URN: urn:ietf:params:oauth:grant-type:jwt-bearer 440 o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 442 o Change controller: IETF 444 o Specification Document: [[this document]] 446 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 447 assertion-type:jwt-bearer 449 This specification registers the value "client-assertion-type:jwt- 450 bearer" in the IANA urn:ietf:params:oauth registry established in An 451 IETF URN Sub-Namespace for OAuth [RFC6755]. 453 o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer 455 o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client 456 Authentication 458 o Change controller: IETF 460 o Specification Document: [[this document]] 462 9. References 464 9.1. Normative References 466 [I-D.ietf-oauth-assertions] 467 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 468 "Assertion Framework for OAuth 2.0 Client Authentication 469 and Authorization Grants", draft-ietf-oauth-assertions 470 (work in progress), July 2014. 472 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 473 (JWT)", draft-ietf-oauth-json-web-token (work in 474 progress), July 2014. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 480 Resource Identifier (URI): Generic Syntax", STD 66, RFC 481 3986, January 2005. 483 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 484 6749, October 2012. 486 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 487 for OAuth", RFC 6755, October 2012. 489 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 490 Interchange Format", RFC 7159, March 2014. 492 9.2. Informative References 494 [I-D.ietf-oauth-dyn-reg] 495 Richer, J., Jones, M., Bradley, J., Machulak, M., and P. 496 Hunt, "OAuth 2.0 Dynamic Client Registration Core 497 Protocol", draft-ietf-oauth-dyn-reg-16 (work in progress), 498 February 2014. 500 [I-D.ietf-oauth-saml2-bearer] 501 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 502 Profile for OAuth 2.0 Client Authentication and 503 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 504 in progress), July 2014. 506 [OpenID.Discovery] 507 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 508 Connect Discovery 1.0", February 2014. 510 [OpenID.Registration] 511 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 512 Dynamic Client Registration 1.0", February 2014. 514 Appendix A. Acknowledgements 516 This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client 517 Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer] 518 by Brian Campbell and Chuck Mortimore. 520 Appendix B. Document History 522 [[ to be removed by the RFC editor before publication as an RFC ]] 524 draft-ietf-oauth-jwt-bearer-10 526 o Added Privacy Considerations section per AD review discussion 527 http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html 528 and http://www.ietf.org/mail-archive/web/oauth/current/ 529 msg13144.html 531 draft-ietf-oauth-jwt-bearer-09 533 o Clarified some text around the treatment of subject based on the 534 rough rough consensus from the thread staring at 535 http://www.ietf.org/mail-archive/web/oauth/current/msg12630.html 537 draft-ietf-oauth-jwt-bearer-08 539 o Updated references, including replacing references to RFC 4627 540 with RFC 7159. 542 draft-ietf-oauth-jwt-bearer-07 544 o Clean up language around subject per http://www.ietf.org/mail- 545 archive/web/oauth/current/msg12250.html. 547 o As suggested in http://www.ietf.org/mail- 548 archive/web/oauth/current/msg12251.html stated that "In the 549 absence of an application profile specifying otherwise, compliant 550 applications MUST compare the audience values using the Simple 551 String Comparison method defined in Section 6.2.1 of RFC 3986." 553 o Added one-time use, maximum lifetime, and specific subject and 554 attribute requirements to Interoperability Considerations based on 555 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 557 o Remove "or its subject confirmation requirements cannot be met" 558 text. 560 o Reword security considerations and mention that replay protection 561 is not mandated based on http://www.ietf.org/mail- 562 archive/web/oauth/current/msg12259.html. 564 -06 566 o Stated that issuer and audience values SHOULD be compared using 567 the Simple String Comparison method defined in Section 6.2.1 of 568 RFC 3986 unless otherwise specified by the application. 570 -05 572 o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for 573 OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client 574 Authentication and Authorization Grants" to be more explicit about 575 the scope of the document per http://www.ietf.org/mail- 576 archive/web/oauth/current/msg11063.html. 578 o Numbered the list of processing rules. 580 o Smallish editorial cleanups to try and improve readability and 581 comprehensibility. 583 o Cleaner split out of the processing rules in cases where they 584 differ for client authentication and authorization grants. 586 o Clarified the parameters that are used/available for authorization 587 grants. 589 o Added Interoperability Considerations section. 591 o Added more explanatory context to the example in Section 4. 593 -04 595 o Changed the name of the "prn" claim to "sub" (subject) both to 596 more closely align with SAML name usage and to use a more 597 intuitive name. 599 o Added seriesInfo information to Internet Draft references. 601 -03 603 o Reference RFC 6749 and RFC 6755. 605 -02 607 o Add more text to intro explaining that an assertion/JWT grant type 608 can be used with or without client authentication/identification 609 and that client assertion/JWT authentication is nothing more than 610 an alternative way for a client to authenticate to the token 611 endpoint 613 o Add examples to Sections 2.1 and 2.2 615 o Update references 617 -01 619 o Tracked specification name changes: "The OAuth 2.0 Authorization 620 Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth 621 2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0". 623 o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and 624 draft-ietf-oauth-saml2-bearer-13. All changes were strictly 625 editorial. 627 -00 629 o Created the initial IETF draft based upon draft-jones-oauth-jwt- 630 bearer-04 with no normative changes. 632 Authors' Addresses 634 Michael B. Jones 635 Microsoft 637 Email: mbj@microsoft.com 638 URI: http://self-issued.info/ 640 Brian Campbell 641 Ping Identity 643 Email: brian.d.campbell@gmail.com 645 Chuck Mortimore 646 Salesforce 648 Email: cmortimore@salesforce.com