idnits 2.17.1 draft-ietf-oauth-jwt-bearer-09.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 (April 28, 2014) is 3644 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: October 30, 2014 Ping Identity 6 C. Mortimore 7 Salesforce 8 April 28, 2014 10 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and 11 Authorization Grants 12 draft-ietf-oauth-jwt-bearer-09 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 October 30, 2014. 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 . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . 7 63 4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8 64 5. Interoperability Considerations . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Sub-Namespace Registration of urn:ietf:params:oauth 68 :grant-type:jwt-bearer . . . . . . . . . . . . . . . . . 9 69 7.2. Sub-Namespace Registration of urn:ietf:params:oauth 70 :client-assertion-type:jwt-bearer . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 75 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 JSON Web Token (JWT) [JWT] is a JavaScript Object Notation (JSON) 81 [RFC7159] based security token encoding that enables identity and 82 security information to be shared across security domains. A 83 security token is generally issued by an identity provider and 84 consumed by a relying party that relies on its content to identify 85 the token's subject for security related purposes. 87 The OAuth 2.0 Authorization Framework [RFC6749] provides a method for 88 making authenticated HTTP requests to a resource using an access 89 token. Access tokens are issued to third-party clients by an 90 authorization server (AS) with the (sometimes implicit) approval of 91 the resource owner. In OAuth, an authorization grant is an abstract 92 term used to describe intermediate credentials that represent the 93 resource owner authorization. An authorization grant is used by the 94 client to obtain an access token. Several authorization grant types 95 are defined to support a wide range of client types and user 96 experiences. OAuth also allows for the definition of new extension 97 grant types to support additional clients or to provide a bridge 98 between OAuth and other trust frameworks. Finally, OAuth allows the 99 definition of additional authentication mechanisms to be used by 100 clients when interacting with the authorization server. 102 The Assertion Framework for OAuth 2.0 Client Authentication and 103 Authorization Grants [I-D.ietf-oauth-assertions] specification is an 104 abstract extension to OAuth 2.0 that provides a general framework for 105 the use of Assertions (a.k.a. Security Tokens) as client credentials 106 and/or authorization grants with OAuth 2.0. This specification 107 profiles the Assertion Framework for OAuth 2.0 Client Authentication 108 and Authorization Grants [I-D.ietf-oauth-assertions] specification to 109 define an extension grant type that uses a JSON Web Token (JWT) 110 Bearer Token to request an OAuth 2.0 access token as well as for use 111 as client credentials. The format and processing rules for the JWT 112 defined in this specification are intentionally similar, though not 113 identical, to those in the closely related SAML 2.0 Profile for OAuth 114 2.0 Client Authentication and Authorization Grants 115 [I-D.ietf-oauth-saml2-bearer] specification. 117 This document defines how a JSON Web Token (JWT) Bearer Token can be 118 used to request an access token when a client wishes to utilize an 119 existing trust relationship, expressed through the semantics of (and 120 digital signature or keyed message digest calculated over) the JWT, 121 without a direct user approval step at the authorization server. It 122 also defines how a JWT can be used as a client authentication 123 mechanism. The use of a security token for client authentication is 124 orthogonal to and separable from using a security token as an 125 authorization grant. They can be used either in combination or 126 separately. Client authentication using a JWT is nothing more than 127 an alternative way for a client to authenticate to the token endpoint 128 and must be used in conjunction with some grant type to form a 129 complete and meaningful protocol request. JWT authorization grants 130 may be used with or without client authentication or identification. 131 Whether or not client authentication is needed in conjunction with a 132 JWT authorization grant, as well as the supported types of client 133 authentication, are policy decisions at the discretion of the 134 authorization server. 136 The process by which the client obtains the JWT, prior to exchanging 137 it with the authorization server or using it for client 138 authentication, is out of scope. 140 1.1. Notational Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 Unless otherwise noted, all the protocol parameter names and values 147 are case sensitive. 149 1.2. Terminology 151 All terms are as defined in The OAuth 2.0 Authorization Framework 152 [RFC6749], the Assertion Framework for OAuth 2.0 Client 153 Authentication and Authorization Grants [I-D.ietf-oauth-assertions], 154 and the JSON Web Token (JWT) [JWT] specifications. 156 2. HTTP Parameter Bindings for Transporting Assertions 158 The Assertion Framework for OAuth 2.0 Client Authentication and 159 Authorization Grants [I-D.ietf-oauth-assertions] specification 160 defines generic HTTP parameters for transporting Assertions (a.k.a. 161 Security Tokens) during interactions with a token endpoint. This 162 section defines specific parameters and treatments of those 163 parameters for use with JWT bearer tokens. 165 2.1. Using JWTs as Authorization Grants 167 To use a Bearer JWT as an authorization grant, use an access token 168 request as defined in Section 4 of the Assertion Framework for OAuth 169 2.0 Client Authentication and Authorization Grants 170 [I-D.ietf-oauth-assertions] specification with the following specific 171 parameter values and encodings. 173 The value of the "grant_type" parameter MUST be 174 "urn:ietf:params:oauth:grant-type:jwt-bearer". 176 The value of the "assertion" parameter MUST contain a single JWT. 178 The "scope" parameter may be used, as defined in the Assertion 179 Framework for OAuth 2.0 Client Authentication and Authorization 180 Grants [I-D.ietf-oauth-assertions] specification, to indicate the 181 requested scope. 183 Authentication of the client is optional, as described in 184 Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the 185 "client_id" is only needed when a form of client authentication that 186 relies on the parameter is used. 188 The following non-normative example demonstrates an Access Token 189 Request with a JWT as an authorization grant (with extra line breaks 190 for display purposes only): 192 POST /token.oauth2 HTTP/1.1 193 Host: as.example.com 194 Content-Type: application/x-www-form-urlencoded 196 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 197 &assertion=eyJhbGciOiJFUzI1NiJ9. 198 eyJpc3Mi[...omitted for brevity...]. 199 J9l-ZhwP[...omitted for brevity...] 201 2.2. Using JWTs for Client Authentication 203 To use a JWT Bearer Token for client authentication, use the 204 following parameter values and encodings. 206 The value of the "client_assertion_type" parameter MUST be 207 "urn:ietf:params:oauth:client-assertion-type:jwt-bearer". 209 The value of the "client_assertion" parameter MUST contain a single 210 JWT. 212 The following non-normative example demonstrates client 213 authentication using a JWT during the presentation of an 214 authorization code grant in an Access Token Request (with extra line 215 breaks for display purposes only): 217 POST /token.oauth2 HTTP/1.1 218 Host: as.example.com 219 Content-Type: application/x-www-form-urlencoded 221 grant_type=authorization_code& 222 code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo& 223 client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A 224 client-assertion-type%3Ajwt-bearer& 225 client_assertion=eyJhbGciOiJSUzI1NiJ9. 226 eyJpc3Mi[...omitted for brevity...]. 227 cC4hiUPo[...omitted for brevity...] 229 3. JWT Format and Processing Requirements 231 In order to issue an access token response as described in OAuth 2.0 232 [RFC6749] or to rely on a JWT for client authentication, the 233 authorization server MUST validate the JWT according to the criteria 234 below. Application of additional restrictions and policy are at the 235 discretion of the authorization server. 237 1. The JWT MUST contain an "iss" (issuer) claim that contains a 238 unique identifier for the entity that issued the JWT. In the 239 absence of an application profile specifying otherwise, 240 compliant applications MUST compare Issuer values using the 241 Simple String Comparison method defined in Section 6.2.1 of RFC 242 3986 [RFC3986]. 244 2. The JWT MUST contain a "sub" (subject) claim identifying the 245 principal that is the subject of the JWT. Two cases need to be 246 differentiated: 248 A. For the authorization grant, the subject typically 249 identifies an authorized accessor for which the access token 250 is being requested (i.e., the resource owner or an 251 authorized delegate), but in some cases, may be a 252 pseudonymous identifier or other value denoting an anonymous 253 user. 255 B. For client authentication, the subject MUST be the 256 "client_id" of the OAuth client. 258 3. The JWT MUST contain an "aud" (audience) claim containing a 259 value that identifies the authorization server as an intended 260 audience. The token endpoint URL of the authorization server 261 MAY be used as a value for an "aud" element to identify the 262 authorization server as an intended audience of the JWT. JWTs 263 that do not identify the authorization server as an intended 264 audience MUST be rejected. In the absence of an application 265 profile specifying otherwise, compliant applications MUST 266 compare the audience values using the Simple String Comparison 267 method defined in Section 6.2.1 of RFC 3986 [RFC3986]. 269 4. The JWT MUST contain an "exp" (expiration) claim that limits the 270 time window during which the JWT can be used. The authorization 271 server MUST verify that the expiration time has not passed, 272 subject to allowable clock skew between systems, and reject 273 expired JWTs. The authorization server MAY reject JWTs with an 274 "exp" claim value that is unreasonably far in the future. 276 5. The JWT MAY contain an "nbf" (not before) claim that identifies 277 the time before which the token MUST NOT be accepted for 278 processing. 280 6. The JWT MAY contain an "iat" (issued at) claim that identifies 281 the time at which the JWT was issued. The authorization server 282 MAY reject JWTs with an "iat" claim value that is unreasonably 283 far in the past. 285 7. The JWT MAY contain a "jti" (JWT ID) claim that provides a 286 unique identifier for the token. The authorization server MAY 287 ensure that JWTs are not replayed by maintaining the set of used 288 "jti" values for the length of time for which the JWT would be 289 considered valid based on the applicable "exp" instant. 291 8. The JWT MAY contain other claims. 293 9. The JWT MUST be digitally signed or have a keyed message digest 294 applied by the issuer. The authorization server MUST reject 295 JWTs with an invalid signature or keyed message digest. 297 10. The authorization server MUST verify that the JWT is valid in 298 all other respects per JSON Web Token (JWT) [JWT]. 300 3.1. Authorization Grant Processing 302 JWT authorization grants may be used with or without client 303 authentication or identification. Whether or not client 304 authentication is needed in conjunction with a JWT authorization 305 grant, as well as the supported types of client authentication, are 306 policy decisions at the discretion of the authorization server. 307 However, if client credentials are present in the request, the 308 authorization server MUST validate them. 310 If the JWT is not valid, or the current time is not within the 311 token's valid time window for use, the authorization server MUST 312 construct an error response as defined in OAuth 2.0 [RFC6749]. The 313 value of the "error" parameter MUST be the "invalid_grant" error 314 code. The authorization server MAY include additional information 315 regarding the reasons the JWT was considered invalid using the 316 "error_description" or "error_uri" parameters. 318 For example: 320 HTTP/1.1 400 Bad Request 321 Content-Type: application/json 322 Cache-Control: no-store 324 { 325 "error":"invalid_grant", 326 "error_description":"Audience validation failed" 327 } 329 3.2. Client Authentication Processing 331 If the client JWT is not valid, the authorization server MUST 332 construct an error response as defined in OAuth 2.0 [RFC6749]. The 333 value of the "error" parameter MUST be the "invalid_client" error 334 code. The authorization server MAY include additional information 335 regarding the reasons the JWT was considered invalid using the 336 "error_description" or "error_uri" parameters. 338 4. Authorization Grant Example 340 Though non-normative, the following examples illustrate what a 341 conforming JWT and access token request would look like. 343 The example shows a JWT issued and signed by the system entity 344 identified as "https://jwt-idp.example.com". The subject of the JWT 345 is identified by email address as "mike@example.com". The intended 346 audience of the JWT is "https://jwt-rp.example.net", which is an 347 identifier with which the authorization server identifies itself. 348 The JWT is sent as part of an access token request to the 349 authorization server's token endpoint at "https://authz.example.net/ 350 token.oauth2". 352 Below is an example JSON object that could be encoded to produce the 353 JWT Claims Object for a JWT: 355 {"iss":"https://jwt-idp.example.com", 356 "sub":"mailto:mike@example.com", 357 "aud":"https://jwt-rp.example.net", 358 "nbf":1300815780, 359 "exp":1300819380, 360 "http://claims.example.com/member":true} 362 The following example JSON object, used as the header of a JWT, 363 declares that the JWT is signed with the ECDSA P-256 SHA-256 364 algorithm. 366 {"alg":"ES256"} 368 To present the JWT with the claims and header shown in the previous 369 example as part of an access token request, for example, the client 370 might make the following HTTPS request (with extra line breaks for 371 display purposes only): 373 POST /token.oauth2 HTTP/1.1 374 Host: authz.example.net 375 Content-Type: application/x-www-form-urlencoded 377 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer 378 &assertion=eyJhbGciOiJFUzI1NiJ9. 379 eyJpc3Mi[...omitted for brevity...]. 380 J9l-ZhwP[...omitted for brevity...] 382 5. Interoperability Considerations 384 Agreement between system entities regarding identifiers, keys, and 385 endpoints is required in order to achieve interoperable deployments 386 of this profile. Specific items that require agreement are as 387 follows: values for the issuer and audience identifiers, the location 388 of the token endpoint, the key used to apply and verify the digital 389 signature or keyed message digest over the JWT, one-time use 390 restrictions on JWT, maximum JWT lifetime allowed, and the specific 391 subject and claim requirements of the JWT. The exchange of such 392 information is explicitly out of scope for this specification. In 393 some cases, additional profiles may be created that constrain or 394 prescribe these values or specify how they are to be exchanged. 395 Examples of such profiles include the OAuth 2.0 Dynamic Client 396 Registration Core Protocol [I-D.ietf-oauth-dyn-reg], OpenID Connect 397 Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID 398 Connect Discovery 1.0 [OpenID.Discovery]. 400 6. Security Considerations 402 The security considerations described within the Assertion Framework 403 for OAuth 2.0 Client Authentication and Authorization Grants 404 [I-D.ietf-oauth-assertions], The OAuth 2.0 Authorization Framework 405 [RFC6749], and the JSON Web Token (JWT) [JWT] specifications are all 406 applicable to this document. 408 The specification does not mandate replay protection for the JWT 409 usage for either the authorization grant or for client 410 authentication. It is an optional feature, which implementations may 411 employ at their own discretion. 413 7. IANA Considerations 415 7.1. Sub-Namespace Registration of urn:ietf:params:oauth:grant-type 416 :jwt-bearer 418 This specification registers the value "grant-type:jwt-bearer" in the 419 IANA urn:ietf:params:oauth registry established in An IETF URN Sub- 420 Namespace for OAuth [RFC6755]. 422 o URN: urn:ietf:params:oauth:grant-type:jwt-bearer 424 o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 426 o Change controller: IETF 428 o Specification Document: [[this document]] 430 7.2. Sub-Namespace Registration of urn:ietf:params:oauth:client- 431 assertion-type:jwt-bearer 433 This specification registers the value "client-assertion-type:jwt- 434 bearer" in the IANA urn:ietf:params:oauth registry established in An 435 IETF URN Sub-Namespace for OAuth [RFC6755]. 437 o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer 439 o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client 440 Authentication 442 o Change controller: IETF 444 o Specification Document: [[this document]] 446 8. References 448 8.1. Normative References 450 [I-D.ietf-oauth-assertions] 451 Campbell, B., Mortimore, C., Jones, M., and Y. Goland, 452 "Assertion Framework for OAuth 2.0 Client Authentication 453 and Authorization Grants", draft-ietf-oauth-assertions 454 (work in progress), April 2014. 456 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 457 (JWT)", draft-ietf-oauth-json-web-token (work in 458 progress), March 2014. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 464 Resource Identifier (URI): Generic Syntax", STD 66, RFC 465 3986, January 2005. 467 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 468 6749, October 2012. 470 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 471 for OAuth", RFC 6755, October 2012. 473 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 474 Interchange Format", RFC 7159, March 2014. 476 8.2. Informative References 478 [I-D.ietf-oauth-dyn-reg] 479 Richer, J., Jones, M., Bradley, J., Machulak, M., and P. 480 Hunt, "OAuth 2.0 Dynamic Client Registration Core 481 Protocol", draft-ietf-oauth-dyn-reg-16 (work in progress), 482 February 2014. 484 [I-D.ietf-oauth-saml2-bearer] 485 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 486 Profile for OAuth 2.0 Client Authentication and 487 Authorization Grants", draft-ietf-oauth-saml2-bearer (work 488 in progress), April 2014. 490 [OpenID.Discovery] 491 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 492 Connect Discovery 1.0", February 2014. 494 [OpenID.Registration] 495 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 496 Dynamic Client Registration 1.0", February 2014. 498 Appendix A. Acknowledgements 500 This profile was derived from SAML 2.0 Profile for OAuth 2.0 Client 501 Authentication and Authorization Grants [I-D.ietf-oauth-saml2-bearer] 502 by Brian Campbell and Chuck Mortimore. 504 Appendix B. Document History 506 [[ to be removed by the RFC editor before publication as an RFC ]] 508 draft-ietf-oauth-jwt-bearer-09 510 o Clarified some text around the treatment of subject based on the 511 rough rough consensus from the thread staring at http:// 512 www.ietf.org/mail-archive/web/oauth/current/msg12630.html 514 draft-ietf-oauth-jwt-bearer-08 516 o Updated references, including replacing references to RFC 4627 517 with RFC 7159. 519 draft-ietf-oauth-jwt-bearer-07 521 o Clean up language around subject per http://www.ietf.org/mail- 522 archive/web/oauth/current/msg12250.html. 524 o As suggested in http://www.ietf.org/mail-archive/web/oauth/current 525 /msg12251.html stated that "In the absence of an application 526 profile specifying otherwise, compliant applications MUST compare 527 the audience values using the Simple String Comparison method 528 defined in Section 6.2.1 of RFC 3986." 530 o Added one-time use, maximum lifetime, and specific subject and 531 attribute requirements to Interoperability Considerations based on 532 http://www.ietf.org/mail-archive/web/oauth/current/msg12252.html. 534 o Remove "or its subject confirmation requirements cannot be met" 535 text. 537 o Reword security considerations and mention that replay protection 538 is not mandated based on http://www.ietf.org/mail-archive/web/ 539 oauth/current/msg12259.html. 541 -06 543 o Stated that issuer and audience values SHOULD be compared using 544 the Simple String Comparison method defined in Section 6.2.1 of 545 RFC 3986 unless otherwise specified by the application. 547 -05 549 o Changed title from "JSON Web Token (JWT) Bearer Token Profiles for 550 OAuth 2.0" to "JSON Web Token (JWT) Profile for OAuth 2.0 Client 551 Authentication and Authorization Grants" to be more explicit about 552 the scope of the document per http://www.ietf.org/mail-archive/web 553 /oauth/current/msg11063.html. 555 o Numbered the list of processing rules. 557 o Smallish editorial cleanups to try and improve readability and 558 comprehensibility. 560 o Cleaner split out of the processing rules in cases where they 561 differ for client authentication and authorization grants. 563 o Clarified the parameters that are used/available for authorization 564 grants. 566 o Added Interoperability Considerations section. 568 o Added more explanatory context to the example in Section 4. 570 -04 571 o Changed the name of the "prn" claim to "sub" (subject) both to 572 more closely align with SAML name usage and to use a more 573 intuitive name. 575 o Added seriesInfo information to Internet Draft references. 577 -03 579 o Reference RFC 6749 and RFC 6755. 581 -02 583 o Add more text to intro explaining that an assertion/JWT grant type 584 can be used with or without client authentication/identification 585 and that client assertion/JWT authentication is nothing more than 586 an alternative way for a client to authenticate to the token 587 endpoint 589 o Add examples to Sections 2.1 and 2.2 591 o Update references 593 -01 595 o Tracked specification name changes: "The OAuth 2.0 Authorization 596 Protocol" to "The OAuth 2.0 Authorization Framework" and "OAuth 597 2.0 Assertion Profile" to "Assertion Framework for OAuth 2.0". 599 o Merged in changes between draft-ietf-oauth-saml2-bearer-11 and 600 draft-ietf-oauth-saml2-bearer-13. All changes were strictly 601 editorial. 603 -00 605 o Created the initial IETF draft based upon draft-jones-oauth-jwt- 606 bearer-04 with no normative changes. 608 Authors' Addresses 610 Michael B. Jones 611 Microsoft 613 Email: mbj@microsoft.com 614 URI: http://self-issued.info/ 615 Brian Campbell 616 Ping Identity 618 Email: brian.d.campbell@gmail.com 620 Chuck Mortimore 621 Salesforce 623 Email: cmortimore@salesforce.com