idnits 2.17.1 draft-ietf-oauth-jwt-bearer-12.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 (November 12, 2014) is 3415 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 (-40) exists of draft-ietf-jose-json-web-algorithms-36 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-30) exists of draft-ietf-oauth-dyn-reg-20 Summary: 1 error (**), 0 flaws (~~), 3 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: May 16, 2015 Ping Identity 6 C. Mortimore 7 Salesforce 8 November 12, 2014 10 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and 11 Authorization Grants 12 draft-ietf-oauth-jwt-bearer-12 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 May 16, 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. The differences arise 117 where the structure and semantics of JWTs differ from SAML 118 assertions. JWTs, for example, have no direct equivalent to the 119 or elements of SAML 120 assertions. 122 This document defines how a JSON Web Token (JWT) Bearer Token can be 123 used to request an access token when a client wishes to utilize an 124 existing trust relationship, expressed through the semantics of (and 125 digital signature or Message Authentication Code calculated over) the 126 JWT, without a direct user approval step at the authorization server. 127 It also defines how a JWT can be used as a client authentication 128 mechanism. The use of a security token for client authentication is 129 orthogonal to and separable from using a security token as an 130 authorization grant. They can be used either in combination or 131 separately. Client authentication using a JWT is nothing more than 132 an alternative way for a client to authenticate to the token endpoint 133 and must be used in conjunction with some grant type to form a 134 complete and meaningful protocol request. JWT authorization grants 135 may be used with or without client authentication or identification. 136 Whether or not client authentication is needed in conjunction with a 137 JWT authorization grant, as well as the supported types of client 138 authentication, are policy decisions at the discretion of the 139 authorization server. 141 The process by which the client obtains the JWT, prior to exchanging 142 it with the authorization server or using it for client 143 authentication, is out of scope. 145 1.1. Notational Conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 Unless otherwise noted, all the protocol parameter names and values 152 are case sensitive. 154 1.2. Terminology 156 All terms are as defined in The OAuth 2.0 Authorization Framework 157 [RFC6749], the Assertion Framework for OAuth 2.0 Client 158 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 159 and the JSON Web Token (JWT) [JWT] specifications. 161 2. HTTP Parameter Bindings for Transporting Assertions 163 The Assertion Framework for OAuth 2.0 Client Authentication and 164 Authorization Grants [I-D.ietf-oauth-assertions] specification 165 defines generic HTTP parameters for transporting Assertions (a.k.a. 166 Security Tokens) during interactions with a token endpoint. This 167 section defines specific parameters and treatments of those 168 parameters for use with JWT bearer tokens. 170 2.1. Using JWTs as Authorization Grants 172 To use a Bearer JWT as an authorization grant, the client uses an 173 access token request as defined in Section 4 of the Assertion 174 Framework for OAuth 2.0 Client Authentication and Authorization 175 Grants [I-D.ietf-oauth-assertions] specification with the following 176 specific parameter values and encodings. 178 The value of the "grant_type" is "urn:ietf:params:oauth:grant- 179 type:jwt-bearer". 181 The value of the "assertion" parameter MUST contain a single JWT. 183 The "scope" parameter may be used, as defined in the Assertion 184 Framework for OAuth 2.0 Client Authentication and Authorization 185 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 186 requested scope. 188 Authentication of the client is optional, as described in 189 Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the 190 "client_id" is only needed when a form of client authentication that 191 relies on the parameter is used. 193 The following example demonstrates an Access Token Request with a JWT 194 as an authorization grant (with extra line breaks for display 195 purposes only): 197 POST /token.oauth2 HTTP/1.1 198 Host: as.example.com 199 Content-Type: application/x-www-form-urlencoded 201 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 202 &assertion=eyJhbGciOiJFUzI1NiJ9. 203 eyJpc3Mi[...omitted for brevity...]. 204 J9l-ZhwP[...omitted for brevity...] 206 2.2. Using JWTs for Client Authentication 208 To use a JWT Bearer Token for client authentication, the client uses 209 the following parameter values and encodings. 211 The value of the "client_assertion_type" is 212 "urn:ietf:params:oauth:client-assertion-type:jwt-bearer". 214 The value of the "client_assertion" parameter contains a single JWT. 215 It MUST NOT contain more than one JWT. 217 The following example demonstrates client authentication using a JWT 218 during the presentation of an authorization code grant in an Access 219 Token Request (with extra line breaks for display purposes only): 221 POST /token.oauth2 HTTP/1.1 222 Host: as.example.com 223 Content-Type: application/x-www-form-urlencoded 225 grant_type=authorization_code& 226 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 227 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A 228 client-assertion-type%3Ajwt-bearer& 229 client_assertion=eyJhbGciOiJSUzI1NiJ9. 230 eyJpc3Mi[...omitted for brevity...]. 231 cC4hiUPo[...omitted for brevity...] 233 3. JWT Format and Processing Requirements 235 In order to issue an access token response as described in OAuth 2.0 236 [RFC6749] or to rely on a JWT for client authentication, the 237 authorization server MUST validate the JWT according to the criteria 238 below. Application of additional restrictions and policy are at the 239 discretion of the authorization server. 241 1. The JWT MUST contain an "iss" (issuer) claim that contains a 242 unique identifier for the entity that issued the JWT. In the 243 absence of an application profile specifying otherwise, 244 compliant applications MUST compare Issuer values using the 245 Simple String Comparison method defined in Section 6.2.1 of RFC 246 3986 [RFC3986]. 248 2. The JWT MUST contain a "sub" (subject) claim identifying the 249 principal that is the subject of the JWT. Two cases need to be 250 differentiated: 252 A. For the authorization grant, the subject typically 253 identifies an authorized accessor for which the access token 254 is being requested (i.e., the resource owner or an 255 authorized delegate), but in some cases, may be a 256 pseudonymous identifier or other value denoting an anonymous 257 user. 259 B. For client authentication, the subject MUST be the 260 "client_id" of the OAuth client. 262 3. The JWT MUST contain an "aud" (audience) claim containing a 263 value that identifies the authorization server as an intended 264 audience. The token endpoint URL of the authorization server 265 MAY be used as a value for an "aud" element to identify the 266 authorization server as an intended audience of the JWT. The 267 Authorization Server MUST reject any JWT that does not contain 268 its own identity as the intended audience In the absence of an 269 application profile specifying otherwise, compliant applications 270 MUST compare the audience values using the Simple String 271 Comparison method defined in Section 6.2.1 of RFC 3986 272 [RFC3986]. As noted in Section 5, the precise strings to be 273 used as the audience for a given Authorization Server must be 274 configured out-of-band by the Authorization Server and the 275 Issuer of the JWT. 277 4. The JWT MUST contain an "exp" (expiration) claim that limits the 278 time window during which the JWT can be used. The authorization 279 server MUST reject any JWT with an expiration time that has 280 passed, subject to allowable clock skew between systems. Note 281 that the authorization server may reject JWTs with an "exp" 282 claim value that is unreasonably far in the future. 284 5. The JWT MAY contain an "nbf" (not before) claim that identifies 285 the time before which the token MUST NOT be accepted for 286 processing. 288 6. The JWT MAY contain an "iat" (issued at) claim that identifies 289 the time at which the JWT was issued. Note that the 290 authorization server may reject JWTs with an "iat" claim value 291 that is unreasonably far in the past. 293 7. The JWT MAY contain a "jti" (JWT ID) claim that provides a 294 unique identifier for the token. The authorization server MAY 295 ensure that JWTs are not replayed by maintaining the set of used 296 "jti" values for the length of time for which the JWT would be 297 considered valid based on the applicable "exp" instant. 299 8. The JWT MAY contain other claims. 301 9. The JWT MUST be digitally signed or have a Message 302 Authentication Code applied by the issuer. The authorization 303 server MUST reject JWTs with an invalid signature or Message 304 Authentication Code. 306 10. The authorization server MUST reject a JWT that is not valid in 307 all other respects per JSON Web Token (JWT) [JWT]. 309 3.1. Authorization Grant Processing 311 JWT authorization grants may be used with or without client 312 authentication or identification. Whether or not client 313 authentication is needed in conjunction with a JWT authorization 314 grant, as well as the supported types of client authentication, are 315 policy decisions at the discretion of the authorization server. 316 However, if client credentials are present in the request, the 317 authorization server MUST validate them. 319 If the JWT is not valid, or the current time is not within the 320 token's valid time window for use, the authorization server 321 constructs an error response as defined in OAuth 2.0 [RFC6749]. The 322 value of the "error" parameter MUST be the "invalid_grant" error 323 code. The authorization server MAY include additional information 324 regarding the reasons the JWT was considered invalid using the 325 "error_description" or "error_uri" parameters. 327 For example: 329 HTTP/1.1 400 Bad Request 330 Content-Type: application/json 331 Cache-Control: no-store 333 { 334 "error":"invalid_grant", 335 "error_description":"Audience validation failed" 336 } 338 3.2. Client Authentication Processing 340 If the client JWT is not valid, the authorization server constructs 341 an error response as defined in OAuth 2.0 [RFC6749]. The value of 342 the "error" parameter MUST be the "invalid_client" error code. The 343 authorization server MAY include additional information regarding the 344 reasons the JWT was considered invalid using the "error_description" 345 or "error_uri" parameters. 347 4. Authorization Grant Example 349 The following examples illustrate what a conforming JWT and an access 350 token request would look like. 352 The example shows a JWT issued and signed by the system entity 353 identified as "https://jwt-idp.example.com". The subject of the JWT 354 is identified by email address as "mike@example.com". The intended 355 audience of the JWT is "https://jwt-rp.example.net", which is an 356 identifier with which the authorization server identifies itself. 357 The JWT is sent as part of an access token request to the 358 authorization server's token endpoint at "https://authz.example.net/ 359 token.oauth2". 361 Below is an example JSON object that could be encoded to produce the 362 JWT Claims Object for a JWT: 364 {"iss":"https://jwt-idp.example.com", 365 "sub":"mailto:mike@example.com", 366 "aud":"https://jwt-rp.example.net", 367 "nbf":1300815780, 368 "exp":1300819380, 369 "http://claims.example.com/member":true} 371 The following example JSON object, used as the header of a JWT, 372 declares that the JWT is signed with the ECDSA P-256 SHA-256 373 algorithm. 375 {"alg":"ES256"} 377 To present the JWT with the claims and header shown in the previous 378 example as part of an access token request, for example, the client 379 might make the following HTTPS request (with extra line breaks for 380 display purposes only): 382 POST /token.oauth2 HTTP/1.1 383 Host: authz.example.net 384 Content-Type: application/x-www-form-urlencoded 386 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 387 &assertion=eyJhbGciOiJFUzI1NiJ9. 388 eyJpc3Mi[...omitted for brevity...]. 389 J9l-ZhwP[...omitted for brevity...] 391 5. Interoperability Considerations 393 Agreement between system entities regarding identifiers, keys, and 394 endpoints is required in order to achieve interoperable deployments 395 of this profile. Specific items that require agreement are as 396 follows: values for the issuer and audience identifiers, the location 397 of the token endpoint, the key used to apply and verify the digital 398 signature or Message Authentication Code over the JWT, one-time use 399 restrictions on the JWT, maximum JWT lifetime allowed, and the 400 specific subject and claim requirements of the JWT. The exchange of 401 such information is explicitly out of scope for this specification. 402 In some cases, additional profiles may be created that constrain or 403 prescribe these values or specify how they are to be exchanged. 404 Examples of such profiles include the OAuth 2.0 Dynamic Client 405 Registration Core Protocol [I-D.ietf-oauth-dyn-reg], OpenID Connect 406 Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID 407 Connect Discovery 1.0 [OpenID.Discovery]. 409 The "RS256" algorithm, from [I-D.ietf-jose-json-web-algorithms], is a 410 mandatory to implement JSON Web Signature algorithm for this profile. 412 6. Security Considerations 414 The security considerations described within the Assertion Framework 415 for OAuth 2.0 Client Authentication and Authorization Grants 416 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 417 [RFC6749], and the JSON Web Token (JWT) [JWT] specifications are all 418 applicable to this document. 420 The specification does not mandate replay protection for the JWT 421 usage for either the authorization grant or for client 422 authentication. It is an optional feature, which implementations may 423 employ at their own discretion. 425 7. Privacy Considerations 427 A JWT may contain privacy-sensitive information and, to prevent 428 disclosure of such information to unintended parties, should only be 429 transmitted over encrypted channels, such as TLS. In cases where it 430 is desirable to prevent disclosure of certain information to the 431 client, the JWT should be be encrypted to the authorization server. 433 Deployments should determine the minimum amount of information 434 necessary to complete the exchange and include only such claims in 435 the JWT. In some cases, the "sub" (subject) claim can be a value 436 representing an anonymous or pseudonymous user, as described in 437 Section 6.3.1 of the Assertion Framework for OAuth 2.0 Client 438 Authentication and Authorization Grants [I-D.ietf-oauth-assertions]. 440 8. IANA Considerations 442 8.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant- 443 type:jwt-bearer 445 This specification registers the value "grant-type:jwt-bearer" in the 446 IANA urn:ietf:params:oauth registry established in An IETF URN Sub- 447 Namespace for OAuth [RFC6755]. 449 o URN: urn:ietf:params:oauth:grant-type:jwt-bearer 451 o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 453 o Change controller: IESG 455 o Specification Document: [[this document]] 457 8.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 458 assertion-type:jwt-bearer 460 This specification registers the value "client-assertion-type:jwt- 461 bearer" in the IANA urn:ietf:params:oauth registry established in An 462 IETF URN Sub-Namespace for OAuth [RFC6755]. 464 o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer 466 o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client 467 Authentication 469 o Change controller: IESG 471 o Specification Document: [[this document]] 473 9. References 475 9.1. Normative References 477 [I-D.ietf-jose-json-web-algorithms] 478 Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose- 479 json-web-algorithms-36 (work in progress), October 2014. 481 [I-D.ietf-oauth-assertions] 482 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 483 "Assertion Framework for OAuth 2.0 Client Authentication 484 and Authorization Grants", draft-ietf-oauth-assertions 485 (work in progress), October 2014. 487 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 488 (JWT)", draft-ietf-oauth-json-web-token (work in 489 progress), October 2014. 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 495 Resource Identifier (URI): Generic Syntax", STD 66, RFC 496 3986, January 2005. 498 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 499 6749, October 2012. 501 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 502 Interchange Format", RFC 7159, March 2014. 504 9.2. Informative References 506 [I-D.ietf-oauth-dyn-reg] 507 Richer, J., Jones, M., Bradley, J., Machulak, M., and P. 508 Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 509 draft-ietf-oauth-dyn-reg-20 (work in progress), August 510 2014. 512 [I-D.ietf-oauth-saml2-bearer] 513 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 514 Profile for OAuth 2.0 Client Authentication and 515 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 516 in progress), November 2014. 518 [OpenID.Discovery] 519 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 520 Connect Discovery 1.0", February 2014. 522 [OpenID.Registration] 523 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 524 Dynamic Client Registration 1.0", February 2014. 526 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 527 for OAuth", RFC 6755, October 2012. 529 Appendix A. Acknowledgements 531 This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client 532 Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer] 533 by Brian Campbell and Chuck Mortimore. 535 Appendix B. Document History 537 [[ to be removed by the RFC editor before publication as an RFC ]] 539 draft-ietf-oauth-jwt-bearer-12 541 o Fix typo per http://www.ietf.org/mail-archive/web/oauth/current/ 542 msg13790.html 544 draft-ietf-oauth-jwt-bearer-11 546 o Changes/suggestions from IESG reviews. 548 draft-ietf-oauth-jwt-bearer-10 550 o Added Privacy Considerations section per AD review discussion 551 http://www.ietf.org/mail-archive/web/oauth/current/msg13148.html 552 and http://www.ietf.org/mail-archive/web/oauth/current/ 553 msg13144.html 555 draft-ietf-oauth-jwt-bearer-09 557 o Clarified some text around the treatment of subject based on the 558 rough rough consensus from the thread staring at 559 http://www.ietf.org/mail-archive/web/oauth/current/msg12630.html 561 draft-ietf-oauth-jwt-bearer-08 563 o Updated references, including replacing references to RFC 4627 564 with RFC 7159. 566 o Clean up language around subject per http://www.ietf.org/mail- 567 archive/web/oauth/current/msg12250.html. 569 o As suggested in http://www.ietf.org/mail- 570 archive/web/oauth/current/msg12251.html stated that "In the 571 absence of an application profile specifying otherwise, compliant 572 applications MUST compare the audience values using the Simple 573 String Comparison method defined in Section 6.2.1 of RFC 3986." 575 o Added one-time use, maximum lifetime, and specific subject and 576 attribute requirements to Interoperability Considerations based on 577 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 579 o Remove "or its subject confirmation requirements cannot be met" 580 text. 582 o Reword security considerations and mention that replay protection 583 is not mandated based on http://www.ietf.org/mail- 584 archive/web/oauth/current/msg12259.html. 586 -06 588 o Stated that issuer and audience values SHOULD be compared using 589 the Simple String Comparison method defined in Section 6.2.1 of 590 RFC 3986 unless otherwise specified by the application. 592 -05 594 o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for 595 OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client 596 Authentication and Authorization Grants" to be more explicit about 597 the scope of the document per http://www.ietf.org/mail- 598 archive/web/oauth/current/msg11063.html. 600 o Numbered the list of processing rules. 602 o Smallish editorial cleanups to try and improve readability and 603 comprehensibility. 605 o Cleaner split out of the processing rules in cases where they 606 differ for client authentication and authorization grants. 608 o Clarified the parameters that are used/available for authorization 609 grants. 611 o Added Interoperability Considerations section. 613 o Added more explanatory context to the example in Section 4. 615 -04 617 o Changed the name of the "prn" claim to "sub" (subject) both to 618 more closely align with SAML name usage and to use a more 619 intuitive name. 621 o Added seriesInfo information to Internet Draft references. 623 -03 625 o Reference RFC 6749 and RFC 6755. 627 -02 629 o Add more text to intro explaining that an assertion/JWT grant type 630 can be used with or without client authentication/identification 631 and that client assertion/JWT authentication is nothing more than 632 an alternative way for a client to authenticate to the token 633 endpoint 635 o Add examples to Sections 2.1 and 2.2 637 o Update references 639 -01 641 o Tracked specification name changes: "The OAuth 2.0 Authorization 642 Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth 643 2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0". 645 o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and 646 draft-ietf-oauth-saml2-bearer-13. All changes were strictly 647 editorial. 649 -00 651 o Created the initial IETF draft based upon draft-jones-oauth-jwt- 652 bearer-04 with no normative changes. 654 Authors' Addresses 656 Michael B. Jones 657 Microsoft 659 Email: mbj@microsoft.com 660 URI: http://self-issued.info/ 661 Brian Campbell 662 Ping Identity 664 Email: brian.d.campbell@gmail.com 666 Chuck Mortimore 667 Salesforce 669 Email: cmortimore@salesforce.com