idnits 2.17.1 draft-jones-json-web-token-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 270 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2011) is 4749 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) -- Looks like a reference, but probably isn't: '123' on line 867 -- Looks like a reference, but probably isn't: '34' on line 867 -- Looks like a reference, but probably isn't: '97' on line 867 -- Looks like a reference, but probably isn't: '108' on line 867 -- Looks like a reference, but probably isn't: '103' on line 867 -- Looks like a reference, but probably isn't: '58' on line 867 -- Looks like a reference, but probably isn't: '82' on line 774 -- Looks like a reference, but probably isn't: '83' on line 867 -- Looks like a reference, but probably isn't: '50' on line 867 -- Looks like a reference, but probably isn't: '53' on line 867 -- Looks like a reference, but probably isn't: '54' on line 867 -- Looks like a reference, but probably isn't: '125' on line 867 -- Looks like a reference, but probably isn't: '1' on line 811 -- Looks like a reference, but probably isn't: '0' on line 915 -- Looks like a reference, but probably isn't: '69' on line 867 -- Possible downref: Non-RFC (?) normative reference: ref. 'JWS' ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'USA15' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track D. Balfanz 5 Expires: September 29, 2011 Google 6 J. Bradley 7 independent 8 Y. Goland 9 Microsoft 10 J. Panzer 11 Google 12 N. Sakimura 13 Nomura Research Institute 14 P. Tarjan 15 Facebook 16 March 28, 2011 18 JSON Web Token (JWT) 19 draft-jones-json-web-token-03 21 Abstract 23 JSON Web Token (JWT) is a means of representing claims to be 24 transferred between two parties. The claims in a JWT are encoded as 25 a JSON object that is digitally signed using a JSON Web Signature 26 (JWS) and optionally encrypted using JSON Web Encryption (JWE). 28 The suggested pronunciation of JWT is the same as the English word 29 "jot". 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 29, 2011. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 5 74 3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Reserved Claim Names . . . . . . . . . . . . . . . . . . . 7 77 4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . . 9 78 4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 9 79 5. JWT Header . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Rules for Creating and Validating a JWT . . . . . . . . . . . 10 81 7. Base64url encoding as used by JWTs . . . . . . . . . . . . . . 12 82 8. Signing JWTs with Cryptographic Algorithms . . . . . . . . . . 12 83 9. Unsigned JWTs . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 11.1. Unicode Comparison Security Issues . . . . . . . . . . . . 14 87 12. Open Issues and Things To Be Done (TBD) . . . . . . . . . . . 14 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 16 92 A.1. JWT using HMAC SHA-256 . . . . . . . . . . . . . . . . . . 16 93 A.2. JWT using RSA SHA-256 . . . . . . . . . . . . . . . . . . 18 94 A.3. JWT using ECDSA P-256 SHA-256 . . . . . . . . . . . . . . 20 95 Appendix B. Notes on implementing base64url encoding without 96 padding . . . . . . . . . . . . . . . . . . . . . . . 22 97 Appendix C. Relationship of JWTs to SAML Tokens . . . . . . . . . 23 98 Appendix D. Relationship of JWTs to Simple Web Tokens (SWTs) . . 23 99 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 23 100 Appendix F. Document History . . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 JSON Web Token (JWT) is a compact token format intended for space 106 constrained environments such as HTTP Authorization headers and URI 107 query parameters. JWTs encode claims to be transmitted as a JSON 108 object (as defined in RFC 4627 [RFC4627]) that is base64url encoded 109 and digitally signed. Signing is accomplished using a JSON Web 110 Signature (JWS) [JWS]. JWTs may also be optionally encrypted using 111 JSON Web Encryption (JWE) [JWE]. 113 The suggested pronunciation of JWT is the same as the English word 114 "jot". 116 2. Terminology 118 JSON Web Token (JWT) A string consisting of three JWT Token 119 Segments: the JWT Header Segment, the JWT Claim Segment, and the 120 JWT Crypto Segment, in that order, with the segments being 121 separated by period ('.') characters. 123 JWT Token Segment One of the three parts that make up a JSON Web 124 Token (JWT). JWT Token Segments are always base64url encoded 125 values. 127 JWT Header Segment A JWT Token Segment containing a base64url 128 encoded JSON object that describes the cryptographic operations 129 applied to the JWT Header Segment and the JWT Claim Segment. The 130 JWT Header Segment is the JWS Header Input for creating a JSON Web 131 Signature (JWS) [JWS] for the JWT. 133 JWT Claim Segment A JWT Token Segment containing a base64url encoded 134 JSON object that encodes the claims contained in the JWT. The JWT 135 Claim Segment is the JWS Payload Input for creating a JSON Web 136 Signature (JWS) [JWS] for the JWT. 138 JWT Crypto Segment A JWT Token Segment containing base64url encoded 139 cryptographic material that secures the contents of the JWT Header 140 Segment and the JWT Claim Segment. The JWT Crypto Segment is the 141 JWS Crypto Output for a JSON Web Signature (JWS) [JWS] created for 142 the JWT. 144 Decoded JWT Header Segment A JWT Header Segment that has been 145 base64url decoded back into a JSON object. 147 Decoded JWT Claim Segment A JWT Claim Segment that has been 148 base64url decoded back into a JSON object. 150 Decoded JWT Crypto Segment A JWT Crypto Segment that has been 151 base64url decoded back into cryptographic material. 153 Claim Names The names of the members of the JSON object represented 154 in a JWT Claim Segment. 156 Claim Values The values of the members of the JSON object 157 represented in a JWT Claim Segment. 159 Base64url Encoding For the purposes of this specification, this term 160 always refers to the he URL- and filename-safe Base64 encoding 161 described in RFC 4648 [RFC4648], Section 5, with the '=' padding 162 characters omitted, as permitted by Section 3.2. 164 3. JSON Web Token (JWT) Overview 166 JWTs represent a set of claims as a JSON object that is base64url 167 encoded and digitally signed and optionally encrypted. As per RFC 168 4627 [RFC4627] Section 2.2, the JSON object consists of zero or more 169 name/value pairs (or members), where the names are strings and the 170 values are arbitrary JSON values. These members are the claims 171 represented by the JWT. The JSON object is base64url encoded to 172 produce the JWT Claim Segment. 174 The member names within the Decoded JWT Claim Segment are referred to 175 as Claim Names. These names MUST be unique. The corresponding 176 values are referred to as Claim Values. 178 The JWT Claim Object is signed in the manner described in JSON Web 179 Signature (JWS) [JWS] and optionally encrypted in the manner 180 described in JSON Web Encryption (JWE) [JWE]. The JWT Claim Object 181 is the JWS Payload Input. The JWT Header Object is the JWS Header 182 Input. The JWT Crypto Segment is the corresponding JWS Crypto 183 Output. 185 A JWT is represented as the concatenation of the JWT Header Segment, 186 the JWT Claim Segment, and the JWT Crypto Segment, in that order, 187 with the segments being separated by period ('.') characters. 189 3.1. Example JWT 191 The following is an example of a JSON object that can be encoded to 192 produce a JWT Claim Segment: 194 {"iss":"joe", 195 "exp":1300819380, 196 "http://example.com/is_root":true} 198 Base64url encoding the UTF-8 representation of the JSON object yields 199 this JWT Claim Segment: 200 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 202 The following example JSON header object declares that the encoded 203 object is a JSON Web Token (JWT) and the JWT Header Segment and the 204 JWT Claim Segment are signed using the HMAC SHA-256 algorithm: 205 {"typ":"JWT", 206 "alg":"HS256"} 208 Base64url encoding the UTF-8 representation of the JSON header object 209 yields this JWT Header Segment value: 210 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 212 Signing the UTF-8 representation of the JWT Header Segment and JWT 213 Claim Segment with the HMAC SHA-256 algorithm and base64url encoding 214 the result, as per Appendix A.1, in the manner specified in [JWS], 215 yields this JWT Crypto Segment value: 216 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 218 Concatenating these segments in the order Header.Claims.Signature 219 with period characters between the segments yields this complete JWT 220 (with line breaks for display purposes only): 221 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 222 . 223 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 224 . 225 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 227 This computation is illustrated in more detail in Appendix A.1. 229 4. JWT Claims 231 A JWT contains a set of claims represented as a base64url encoded 232 JSON object. Note however, that the set of claims a JWT must contain 233 to be considered valid is context-dependent and is outside the scope 234 of this specification. When used in a security-related context, 235 implementations MUST understand and support all of the claims 236 present; otherwise, the JWT MUST be rejected for processing. 238 There are three classes of JWT Claim Names: Reserved Claim Names, 239 Public Claim Names, and Private Claim Names. 241 4.1. Reserved Claim Names 243 The following claim names are reserved. None of the claims defined 244 in the table below are intended to be mandatory, but rather, provide 245 a starting point for a set of useful, interoperable claims. All the 246 names are short because a core goal of JWTs is for the tokens to be 247 compact. 249 +-------+---------+--------------+----------------------------------+ 250 | Claim | JSON | Claim Syntax | Claim Semantics | 251 | Name | Value | | | 252 | | Type | | | 253 +-------+---------+--------------+----------------------------------+ 254 | exp | integer | IntDate | The "exp" (expiration time) | 255 | | | | claim identifies the expiration | 256 | | | | time on or after which the token | 257 | | | | MUST NOT be accepted for | 258 | | | | processing. The processing of | 259 | | | | the "exp" claim requires that | 260 | | | | the current date/time MUST be | 261 | | | | before the expiration date/time | 262 | | | | listed in the "exp" claim. | 263 | | | | Implementers MAY provide for | 264 | | | | some small leeway, usually no | 265 | | | | more than a few minutes, to | 266 | | | | account for clock skew. This | 267 | | | | claim is OPTIONAL. | 268 | iat | integer | IntDate | The "iat" (issued at) claim | 269 | | | | identifies the UTC time at which | 270 | | | | the JWT was issued. The | 271 | | | | processing of the "iat" claim | 272 | | | | requires that the current | 273 | | | | date/time MUST be after the | 274 | | | | issued date/time listed in the | 275 | | | | "iat" claim. Implementers MAY | 276 | | | | provide for some small leeway, | 277 | | | | usually no more than a few | 278 | | | | minutes, to account for clock | 279 | | | | skew. This claim is OPTIONAL. | 280 | iss | string | StringAndURI | The "iss" (issuer) claim | 281 | | | | identifies the principal that | 282 | | | | issued the JWT. The processing | 283 | | | | of this claim is generally | 284 | | | | application specific. The "iss" | 285 | | | | value is case sensitive. This | 286 | | | | claim is OPTIONAL. | 287 | aud | string | StringAndURI | The "aud" (audience) claim | 288 | | | | identifies the audience that the | 289 | | | | JWT is intended for. The | 290 | | | | principal intended to process | 291 | | | | the JWT MUST be identified by | 292 | | | | the value of the audience claim. | 293 | | | | If the principal processing the | 294 | | | | claim does not identify itself | 295 | | | | with the identifier in the "aud" | 296 | | | | claim value then the JWT MUST be | 297 | | | | rejected. The interpretation of | 298 | | | | the contents of the audience | 299 | | | | value is generally application | 300 | | | | specific. The "aud" value is | 301 | | | | case sensitive. This claim is | 302 | | | | OPTIONAL. | 303 | typ | string | String | The "typ" (type) claim is used | 304 | | | | to declare a type for the | 305 | | | | contents of this JWT. The "typ" | 306 | | | | value is case sensitive. This | 307 | | | | claim is OPTIONAL. | 308 +-------+---------+--------------+----------------------------------+ 310 Table 1: Reserved Claim Definitions 312 Additional reserved claim names MAY be defined via the IANA JSON Web 313 Token Claims registry, as per Section 10. The syntax values used 314 above are defined as follows: 316 +--------------+----------------------------------------------------+ 317 | Syntax Name | Syntax Definition | 318 +--------------+----------------------------------------------------+ 319 | IntDate | The number of seconds from 1970-01-01T0:0:0Z as | 320 | | measured in UTC until the desired date/time. See | 321 | | RFC 3339 [RFC3339] for details regarding | 322 | | date/times in general and UTC in particular. | 323 | String | Any string value MAY be used. | 324 | StringAndURI | Any string value MAY be used but a value | 325 | | containing a ":" character MUST be a URI as | 326 | | defined in RFC 3986 [RFC3986]. | 327 +--------------+----------------------------------------------------+ 329 Table 2: Claim Syntax Definitions 331 4.2. Public Claim Names 333 Claim names can be defined at will by those using JWTs. However, in 334 order to prevent collisions, any new claim name SHOULD either be 335 defined in the IANA JSON Web Token Claims registry or be defined as a 336 URI that contains a collision resistant namespace. Examples of 337 collision resistant namespaces include: 339 o Domain Names, 341 o Object Identifiers (OIDs) as defined in the ITU-T X 660 and X 670 342 Recommendation series or 344 o Universally Unique IDentifier (UUID) as defined in RFC 4122 345 [RFC4122]. 347 In each case, the definer of the name or value MUST take reasonable 348 precautions to make sure they are in control of the part of the 349 namespace they use to define the claim name. 351 4.3. Private Claim Names 353 A producer and consumer of a JWT may agree to any claim name that is 354 not a Reserved Name Section 4.1 or a Public Name Section 4.2. Unlike 355 Public Names, these private names are subject to collision and should 356 be used with caution. 358 5. JWT Header 360 The members of the JSON object represented by the Decoded JWT Header 361 Segment describe the cryptographic operations applied to the JWT 362 Header Segment and the JWT Claim Segment and optionally, additional 363 properties of the JWT. The JWT Header Segment is used as the JWS 364 Header Input for signing. The format of the header and the 365 cryptographic operations applied MUST be as specified in JSON Web 366 Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE]. 368 Implementations MUST understand the entire contents of the header; 369 otherwise, the JWT MUST be rejected for processing. 371 JWS Header Parameters are defined by [JWS]. This specification 372 further specifies the use of the following header parameters when the 373 JWS Header Input is a JWT Header Segment. 375 +----------+--------+-----------+-----------------------------------+ 376 | Header | JSON | Header | Header Parameter Semantics | 377 | Paramete | Value | Parameter | | 378 | rName | Type | Syntax | | 379 +----------+--------+-----------+-----------------------------------+ 380 | typ | string | String | The "typ" (type) header parameter | 381 | | | | MAY be used to declare that this | 382 | | | | data structure is a JWT. If a | 383 | | | | "typ" parameter is present, it is | 384 | | | | RECOMMENDED that its value be | 385 | | | | either "JWT" or | 386 | | | | "http://openid.net/specs/jwt/1.0" | 387 | | | | .Use of this header parameter is | 388 | | | | OPTIONAL. | 389 +----------+--------+-----------+-----------------------------------+ 391 Table 3: Reserved Header Parameter Usage 393 6. Rules for Creating and Validating a JWT 395 To create a JWT, one MUST follow these steps: 397 1. Create a JSON object containing the desired claims. Note that 398 white space is explicitly allowed in the representation and no 399 canonicalization is performed before encoding. 401 2. Translate this JSON object's Unicode code points into UTF-8, as 402 defined in RFC 3629 [RFC3629]. This is the Decoded JWT Claim 403 Segment. 405 3. Base64url encode the Decoded JWT Claim Segment. This encoding 406 becomes the JWT Claim Segment. 408 4. Create a JSON object containing a set of desired header 409 parameters that conform to the [JWS] and [JWE] specifications. 410 Note that white space is explicitly allowed in the representation 411 and no canonicalization is performed before encoding. 413 5. Translate this JSON object's Unicode code points into UTF-8, as 414 defined in RFC 3629 [RFC3629]. This is the Decoded JWT Header 415 Segment. 417 6. Base64url encode the UTF-8 representation of this JSON object as 418 defined in this specification (without padding). This encoding 419 becomes a JWT Header Segment. 421 7. Unless the "alg" value is ""none"", sign and optionally encrypt 422 the JWT Header Segment and JWT Claim Segment values in the manner 423 described in the [JWS] and [JWE] specifications; the JWT Header 424 Segment is used as the JWS Header Input and the JWT Claim Segment 425 is used as the JWS Payload Input; the resulting JWS Crypto Output 426 is used as the JWT Claim Segment. Otherwise, if the "alg" value 427 is ""none"", the JWT Claim Segment is the empty string. 429 8. Concatenate the JWT Header Segment, the JWT Claim Segment, and 430 the JWT Crypto Segment in that order, separating each by period 431 characters, to create the JWT. 433 When validating a JWT the following steps MUST be taken. If any of 434 the listed steps fails then the token MUST be rejected for 435 processing. 437 1. The JWT MUST contain two period characters. 439 2. The JWT MUST be split on the two period characters resulting in 440 three segment strings. The first segment is the JWT Header 441 Segment; the second is the JWT Claim Segment; the third is the 442 JWT Crypto Segment. 444 3. The JWT Claim Segment MUST be successfully base64url decoded 445 following the restriction given in this specification that no 446 padding characters have been used. 448 4. The Decoded JWT Claim Segment MUST be completely valid JSON 449 syntax conforming to RFC 4627 [RFC4627]. 451 5. When used in a security-related context, the Decoded JWT Claim 452 Segment MUST be validated to only include claims whose syntax 453 and semantics are both understood and supported. 455 6. The JWT Header Segment MUST be successfully base64url decoded 456 following the restriction given in this specification that no 457 padding characters have been used. 459 7. The Decoded JWT Header Segment MUST be completely valid JSON 460 syntax conforming to RFC 4627 [RFC4627]. 462 8. The JWT Crypto Segment MUST be successfully base64url decoded 463 following the restriction given in this specification that no 464 padding characters have been used. 466 9. The JWT Header Segment MUST be validated to only include 467 parameters and values whose syntax and semantics are both 468 understood and supported. 470 10. Unless the "alg" value is ""none"", the JWT Crypto Segment MUST 471 be successfully validated against the JWT Header Segment and JWT 472 Claim Segment in the manner defined by the [JWS] and [JWE] 473 specifications; otherwise the JWT Crypto Segment MUST be the 474 empty string. 476 Processing a JWT inevitably requires comparing known strings to 477 values in the token. For example, in checking what the algorithm is, 478 the Unicode string encoding "alg" will be checked against the member 479 names in the Decoded JWT Header Segment to see if there is a matching 480 header parameter name. A similar process occurs when determining if 481 the value of the "alg" header parameter represents a supported 482 algorithm. Comparing Unicode strings, however, has significant 483 security implications, as per Section 11. 485 Comparisons between JSON strings and other Unicode strings MUST be 486 performed as specified below: 488 1. Remove any JSON applied escaping to produce an array of Unicode 489 code points. 491 2. Unicode Normalization [USA15] MUST NOT be applied at any point to 492 either the JSON string or to the string it is to be compared 493 against. 495 3. Comparisons between the two strings MUST be performed as a 496 Unicode code point to code point equality comparison. 498 7. Base64url encoding as used by JWTs 500 JWTs make use of the base64url encoding as defined in RFC 4648 501 [RFC4648]. As allowed by Section 3.2 of the RFC, this specification 502 mandates that base64url encoding when used with JWTs MUST NOT use 503 padding. The reason for this restriction is that the padding 504 character ('=') is not URL safe. 506 For notes on implementing base64url encoding without padding, see 507 Appendix B. 509 8. Signing JWTs with Cryptographic Algorithms 511 JWTs use JSON Web Signatures (JWSs) [JWS] and JSON Web Encryption 512 (JWE) [JWE] to sign and optionally encrypt the contents of the JWT 513 Header Segment and the JWT Claim Segment to produce the JWT Crypto 514 Segment Value. 516 Of the JWS signing algorithms, only HMAC SHA-256 MUST be implemented 517 by conforming JWT implementations. It is RECOMMENDED that 518 implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 519 algorithms. Support for other algorithms is OPTIONAL. 521 9. Unsigned JWTs 523 To support use cases where the JWT content is secured by a means 524 other than a signature contained within the token (such as signature 525 on a data structure containing the token), JWTs MAY also be created 526 without a signature. Unsigned JWTs MUST use the "alg" value ""none"" 527 and use the empty string as the JWT Crypto Segment value. 529 10. IANA Considerations 531 This specification calls for: 533 o A new IANA registry entitled "JSON Web Token Claims" for reserved 534 claim names is defined in Section 4.1. Inclusion in the registry 535 is RFC Required in the RFC 5226 [RFC5226] sense for reserved JWT 536 claim names that are intended to be interoperable between 537 implementations. The registry will just record the reserved claim 538 name and a pointer to the RFC that defines it. This specification 539 defines inclusion of the claim names defined in Table 1. 541 11. Security Considerations 543 TBD: Lots of work to do here. We need to remember to look into any 544 issues relating to security and JSON parsing. One wonders just how 545 secure most JSON parsing libraries are. Were they ever hardened for 546 security scenarios? If not, what kind of holes does that open up? 547 Also, we need to walk through the JSON standard and see what kind of 548 issues we have especially around comparison of names. For instance, 549 comparisons of claim names and other parameters must occur after they 550 are unescaped. Need to also put in text about: Importance of keeping 551 secrets secret. Rotating keys. Strengths and weaknesses of the 552 different algorithms. 554 TBD: Need to put in text about why strict JSON validation is 555 necessary. Basically, that if malformed JSON is received then the 556 intent of the sender is impossible to reliably discern. While in 557 non-security contexts it's o.k. to be generous in what one accepts, 558 in security contexts this can lead to serious security holes. For 559 example, malformed JSON might indicate that someone has managed to 560 find a security hole in the issuer's code and is leveraging it to get 561 the issuer to issue "bad" tokens whose content the attacker can 562 control. 564 TBD: Write about need to secure token content if a signature is not 565 contained in the JWT itself. 567 11.1. Unicode Comparison Security Issues 569 Claim names in JWTs are Unicode strings. For security reasons, the 570 representations of these names must be compared verbatim after 571 performing any escape processing (as per RFC 4627 [RFC4627], Section 572 2.5). 574 This means, for instance, that these JSON strings must compare as 575 being equal ("JWT", "\u004aWT"), whereas these must all compare as 576 being not equal to the first set or to each other ("jwt", "Jwt", 577 "JW\u0074"). 579 JSON strings MAY contain characters outside the Unicode Basic 580 Multilingual Plane. For instance, the G clef character (U+1D11E) may 581 be represented in a JSON string as "\uD834\uDD1E". Ideally, JWT 582 implementations SHOULD ensure that characters outside the Basic 583 Multilingual Plane are preserved and compared correctly; 584 alternatively, if this is not possible due to these characters 585 exercising limitations present in the underlying JSON implementation, 586 then input containing them MUST be rejected. 588 12. Open Issues and Things To Be Done (TBD) 590 The following items remain to be done in this draft (and related 591 drafts): 593 o Consider whether we really want to allow private claim names and 594 that are not registered with IANA and are not in collision- 595 resistant namespaces. Eventually this could result in interop 596 nightmares where you need to have different code to talk to 597 different endpoints that "knows" about each endpoints' private 598 parameters. 600 o Clarify the optional ability to provide type information for JWTs 601 and/or their segments. Specifically, clarify the intended use of 602 the "typ" Header Parameter and the "typ" claim, whether they 603 convey syntax or semantics, and indeed, whether this is the right 604 approach. Also clarify the relationship between these type values 605 and MIME [RFC2045] types. 607 o Finish the Security Considerations section. 609 o Sort out what to do with the IANA registries if this is first 610 standardized as an OpenID specification. 612 o Write a companion specification that contains the former JWT JSON 613 Serialization. 615 13. References 617 13.1. Normative References 619 [JWS] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, 620 J., Sakimura, N., and P. Tarjan, "JSON Web Signature 621 (JWS)", March 2011. 623 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 624 Extensions (MIME) Part One: Format of Internet Message 625 Bodies", RFC 2045, November 1996. 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 631 Internet: Timestamps", RFC 3339, July 2002. 633 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 634 10646", STD 63, RFC 3629, November 2003. 636 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 637 Resource Identifier (URI): Generic Syntax", STD 66, 638 RFC 3986, January 2005. 640 [RFC4627] Crockford, D., "The application/json Media Type for 641 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 643 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 644 Encodings", RFC 4648, October 2006. 646 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 647 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 648 May 2008. 650 [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode 651 Normalization Forms", Unicode Standard Annex 15, 09 2009. 653 13.2. Informative References 655 [CanvasApp] 656 Facebook, "Canvas Applications", 2010. 658 [JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", 659 September 2010. 661 [JWE] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 662 Encryption (JWE)", March 2011. 664 [MagicSignatures] 665 Panzer (editor), J., Laurie, B., and D. Balfanz, "Magic 666 Signatures", August 2010. 668 [OASIS.saml-core-2.0-os] 669 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 670 "Assertions and Protocol for the OASIS Security Assertion 671 Markup Language (SAML) V2.0", OASIS Standard saml-core- 672 2.0-os, March 2005. 674 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 675 Language) XML-Signature Syntax and Processing", RFC 3275, 676 March 2002. 678 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 679 Unique IDentifier (UUID) URN Namespace", RFC 4122, 680 July 2005. 682 [SWT] Hardt, D. and Y. Goland, "Simple Web Token (SWT)", 683 Version 0.9.5.1, November 2009. 685 [W3C.CR-xml11-20021015] 686 Cowan, J., "Extensible Markup Language (XML) 1.1", W3C 687 CR CR-xml11-20021015, October 2002. 689 Appendix A. JWT Examples 691 This section provides several examples of JWTs. The cryptographic 692 operations for these examples are detailed in the JSON Web Signature 693 (JWS) [JWS] specification. 695 A.1. JWT using HMAC SHA-256 697 The Decoded JWT Claim Segment used in this example is: 699 {"iss":"joe", 700 "exp":1300819380, 701 "http://example.com/is_root":true} 703 Note that white space is explicitly allowed in Decoded JWT Claim 704 Segments and no canonicalization is performed before encoding. The 705 following byte array contains the UTF-8 characters for the Decoded 706 JWT Claim Segment: 708 [123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 709 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 710 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 711 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 712 111, 116, 34, 58, 116, 114, 117, 101, 125] 714 Base64url encoding the above yields the JWT Claim Segment value: 715 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 717 The following example JSON header object declares that the data 718 structure is a JSON Web Token (JWT) and the JWT Header Segment and 719 JWT Crypto Segment are signed using the HMAC SHA-256 algorithm: 720 {"typ":"JWT", 721 "alg":"HS256"} 723 The following byte array contains the UTF-8 characters for the 724 Decoded JWT Header Segment: 726 [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 727 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] 729 Base64url encoding this UTF-8 representation yields this JWT Header 730 Segment value: 731 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 733 This example uses the key represented by the following byte array: 735 [3, 35, 53, 75, 43, 15, 165, 188, 131, 126, 6, 101, 119, 123, 166, 736 143, 90, 179, 40, 230, 240, 84, 201, 40, 169, 15, 132, 178, 210, 80, 737 46, 191, 211, 251, 90, 146, 210, 6, 71, 239, 150, 138, 180, 195, 119, 738 98, 61, 34, 61, 46, 33, 114, 5, 46, 79, 8, 192, 205, 154, 245, 103, 739 208, 128, 163] 741 Signing the JWT Header Segment and JWT Claim Segment with this key in 742 the manner specified by [JWS] yields this JWT Crypto Segment value: 743 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 745 Combining these segments in the order Header.Claims.Signature with 746 period characters between the segments yields this complete JWT (with 747 line breaks for display purposes only): 748 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 749 . 750 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 751 . 752 dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk 754 A.2. JWT using RSA SHA-256 756 The Decoded JWT Claim Segment used in this example is the same as in 757 the previous example: 758 {"iss":"joe", 759 "exp":1300819380, 760 "http://example.com/is_root":true} 762 Since the JWT Claim Segment will therefore be the same, its 763 computation is not repeated here. However, the Decoded JWT Header 764 Segment is different in two ways: First, because a different 765 algorithm is being used, the "alg" value is different. Second, for 766 illustration purposes only, the optional "typ" parameter is not used. 767 (This difference is not related to the signature algorithm employed.) 768 The Decoded JWT Header Segment used is: 769 {"alg":"RS256"} 771 The following byte array contains the UTF-8 characters for the 772 Decoded JWT Header Segment: 774 [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125] 776 Base64url encoding this UTF-8 representation yields this JWT Header 777 Segment value: 778 eyJhbGciOiJSUzI1NiJ9 780 The RSA key consists of a public part (n, e), and a private exponent 781 d. The values of the RSA key used in this example, presented as the 782 byte arrays representing big endian integers are: 784 +-----------+-------------------------------------------------------+ 785 | Parameter | Value | 786 | Name | | 787 +-----------+-------------------------------------------------------+ 788 | n | [161, 248, 22, 10, 226, 227, 201, 180, 101, 206, 141, | 789 | | 45, 101, 98, 99, 54, 43, 146, 125, 190, 41, 225, 240, | 790 | | 36, 119, 252, 22, 37, 204, 144, 161, 54, 227, 139, | 791 | | 217, 52, 151, 197, 182, 234, 99, 221, 119, 17, 230, | 792 | | 124, 116, 41, 249, 86, 176, 251, 138, 143, 8, 154, | 793 | | 220, 75, 105, 137, 60, 193, 51, 63, 83, 237, 208, 25, | 794 | | 184, 119, 132, 37, 47, 236, 145, 79, 228, 133, 119, | 795 | | 105, 89, 75, 234, 66, 128, 211, 44, 15, 85, 191, 98, | 796 | | 148, 79, 19, 3, 150, 188, 110, 155, 223, 110, 189, | 797 | | 210, 189, 163, 103, 142, 236, 160, 198, 104, 247, 1, | 798 | | 179, 141, 191, 251, 56, 200, 52, 44, 226, 254, 109, | 799 | | 39, 250, 222, 74, 90, 72, 116, 151, 157, 212, 185, | 800 | | 207, 154, 222, 196, 199, 91, 5, 133, 44, 44, 15, 94, | 801 | | 248, 165, 193, 117, 3, 146, 249, 68, 232, 237, 100, | 802 | | 193, 16, 198, 182, 71, 96, 154, 164, 120, 58, 235, | 803 | | 156, 108, 154, 215, 85, 49, 48, 80, 99, 139, 131, | 804 | | 102, 92, 111, 111, 122, 130, 163, 150, 112, 42, 31, | 805 | | 100, 27, 130, 211, 235, 242, 57, 34, 25, 73, 31, 182, | 806 | | 134, 135, 44, 87, 22, 245, 10, 248, 53, 141, 154, | 807 | | 139, 157, 23, 195, 64, 114, 143, 127, 135, 216, 154, | 808 | | 24, 216, 252, 171, 103, 173, 132, 89, 12, 46, 207, | 809 | | 117, 147, 57, 54, 60, 7, 3, 77, 111, 96, 111, 158, | 810 | | 33, 224, 84, 86, 202, 229, 233, 161] | 811 | e | [1, 0, 1] | 812 | d | [18, 174, 113, 164, 105, 205, 10, 43, 195, 126, 82, | 813 | | 108, 69, 0, 87, 31, 29, 97, 117, 29, 100, 233, 73, | 814 | | 112, 123, 98, 89, 15, 157, 11, 165, 124, 150, 60, 64, | 815 | | 30, 63, 207, 47, 44, 211, 189, 236, 136, 229, 3, 191, | 816 | | 198, 67, 155, 11, 40, 200, 47, 125, 55, 151, 103, 31, | 817 | | 82, 19, 238, 216, 193, 90, 37, 216, 213, 206, 160, 2, | 818 | | 94, 227, 171, 46, 139, 127, 121, 33, 111, 198, 59, | 819 | | 234, 86, 39, 83, 180, 6, 68, 198, 161, 81, 39, 217, | 820 | | 178, 149, 69, 64, 160, 187, 225, 163, 5, 86, 152, 45, | 821 | | 78, 159, 222, 95, 100, 37, 241, 77, 75, 113, 52, 65, | 822 | | 181, 93, 199, 59, 155, 74, 237, 204, 146, 172, 227, | 823 | | 146, 126, 55, 245, 125, 12, 253, 94, 117, 129, 250, | 824 | | 81, 44, 143, 73, 97, 169, 235, 11, 128, 248, 168, 7, | 825 | | 70, 114, 138, 85, 255, 70, 71, 31, 52, 37, 6, 59, | 826 | | 157, 83, 100, 47, 94, 222, 30, 132, 214, 19, 8, 26, | 827 | | 250, 92, 34, 208, 81, 40, 91, 214, 59, 148, 59, 86, | 828 | | 93, 137, 138, 5, 104, 84, 19, 229, 60, 60, 108, 101, | 829 | | 37, 255, 31, 227, 78, 61, 220, 112, 240, 213, 100, | 830 | | 80, 253, 164, 139, 161, 46, 16, 78, 157, 235, 159, | 831 | | 184, 24, 129, 225, 196, 189, 242, 93, 146, 71, 244, | 832 | | 80, 200, 101, 146, 121, 104, 231, 115, 52, 244, 65, | 833 | | 79, 117, 167, 80, 225, 57, 84, 110, 58, 138, 115, | 834 | | 157] | 835 +-----------+-------------------------------------------------------+ 837 Signing the JWT Header Segment and JWT Claim Segment with this key in 838 the manner specified by [JWS] yields this JWT Crypto Segment value: 839 cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw 841 Combining these segments in the order Header.Claims.Signature with 842 period characters between the segments yields this complete JWT (with 843 line breaks for display purposes only): 844 eyJhbGciOiJSUzI1NiJ9 845 . 846 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 847 . 848 cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw 850 A.3. JWT using ECDSA P-256 SHA-256 852 The Decoded JWT Claim Segment used in this example is the same as in 853 the previous examples: 854 {"iss":"joe", 855 "exp":1300819380, 856 "http://example.com/is_root":true} 858 Since the JWT Claim Segment will therefore be the same, its 859 computation is not repeated here. However, the Decoded JWT Header 860 Segment is differs from the previous example because a different 861 algorithm is being used. The Decoded JWT Header Segment used is: 862 {"alg":"ES256"} 864 The following byte array contains the UTF-8 characters for the 865 Decoded JWT Header Segment: 867 [123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125] 869 Base64url encoding this UTF-8 representation yields this JWT Header 870 Segment value: 871 eyJhbGciOiJFUzI1NiJ9 873 The ECDSA key consists of a public part, the EC point (x, y), and a 874 private part d. The values of the ECDSA key used in this example, 875 presented as the byte arrays representing big endian integers are: 877 +-----------+-------------------------------------------------------+ 878 | Parameter | Value | 879 | Name | | 880 +-----------+-------------------------------------------------------+ 881 | x | [127, 205, 206, 39, 112, 246, 196, 93, 65, 131, 203, | 882 | | 238, 111, 219, 75, 123, 88, 7, 51, 53, 123, 233, 239, | 883 | | 19, 186, 207, 110, 60, 123, 209, 84, 69] | 884 | y | [199, 241, 68, 205, 27, 189, 155, 126, 135, 44, 223, | 885 | | 237, 185, 238, 185, 244, 179, 105, 93, 110, 169, 11, | 886 | | 36, 173, 138, 70, 35, 40, 133, 136, 229, 173] | 887 | d | [142, 155, 16, 158, 113, 144, 152, 191, 152, 4, 135, | 888 | | 223, 31, 93, 119, 233, 203, 41, 96, 110, 190, 210, | 889 | | 38, 59, 95, 87, 194, 19, 223, 132, 244, 178] | 890 +-----------+-------------------------------------------------------+ 892 Signing the JWT Header Segment and JWT Claim Segment with this key in 893 the manner specified by [JWS] yields this JWT Crypto Segment value: 894 DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q 896 Combining these segments in the order Header.Claims.Signature with 897 period characters between the segments yields this complete JWT (with 898 line breaks for display purposes only): 899 eyJhbGciOiJFUzI1NiJ9 900 . 901 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 902 . 903 DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q 904 Appendix B. Notes on implementing base64url encoding without padding 906 This appendix describes how to implement base64url encoding and 907 decoding functions without padding based upon standard base64 908 encoding and decoding functions that do use padding. 910 To be concrete, example C# code implementing these functions is shown 911 below. Similar code could be used in other languages. 912 static string base64urlencode(byte [] arg) 913 { 914 string s = Convert.ToBase64String(arg); // Standard base64 encoder 915 s = s.Split('=')[0]; // Remove any trailing '='s 916 s = s.Replace('+', '-'); // 62nd char of encoding 917 s = s.Replace('/', '_'); // 63rd char of encoding 918 return s; 919 } 921 static byte [] base64urldecode(string arg) 922 { 923 string s = arg; 924 s = s.Replace('-', '+'); // 62nd char of encoding 925 s = s.Replace('_', '/'); // 63rd char of encoding 926 switch (s.Length % 4) // Pad with trailing '='s 927 { 928 case 0: break; // No pad chars in this case 929 case 2: s += "=="; break; // Two pad chars 930 case 3: s += "="; break; // One pad char 931 default: throw new System.Exception( 932 "Illegal base64url string!"); 933 } 934 return Convert.FromBase64String(s); // Standard base64 decoder 935 } 937 As per the example code above, the number of '=' padding characters 938 that needs to be added to the end of a base64url encoded string 939 without padding to turn it into one with padding is a deterministic 940 function of the length of the encoded string. Specifically, if the 941 length mod 4 is 0, no padding is added; if the length mod 4 is 2, two 942 '=' padding characters are added; if the length mod 4 is 3, one '=' 943 padding character is added; if the length mod 4 is 1, the input is 944 malformed. 946 An example correspondence between unencoded and encoded values 947 follows. The byte sequence below encodes into the string below, 948 which when decoded, reproduces the byte sequence. 949 3 236 255 224 193 950 A-z_4ME 952 Appendix C. Relationship of JWTs to SAML Tokens 954 SAML 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating 955 tokens with much greater expressivity and more security options than 956 supported by JWTs. However, the cost of this flexibility and 957 expressiveness is both size and complexity. In addition, SAML's use 958 of XML [W3C.CR-xml11-20021015] and XML DSIG [RFC3275] only 959 contributes to the size of SAML tokens. 961 JWTs are intended to provide a simple token format that is small 962 enough to fit into HTTP headers and query arguments in URIs. It does 963 this by supporting a much simpler token model than SAML and using the 964 JSON [RFC4627] object encoding syntax. It also supports securing 965 tokens using Hash-based Message Authentication Codes (HMACs) and 966 digital signatures using a smaller (and less flexible) format than 967 XML DSIG. 969 Therefore, while JWTs can do some of the things SAML tokens do, JWTs 970 are not intended as a full replacement for SAML tokens, but rather as 971 a compromise token format to be used when space is at a premium. 973 Appendix D. Relationship of JWTs to Simple Web Tokens (SWTs) 975 Both JWTs and Simple Web Tokens SWT [SWT], at their core, enable sets 976 of claims to be communicated between applications. For SWTs, both 977 the claim names and claim values are strings. For JWTs, while claim 978 names are strings, claim values can be any JSON type. Both token 979 types offer cryptographic protection of their content: SWTs with HMAC 980 SHA-256 and JWTs with a choice of algorithms, including HMAC SHA-256, 981 RSA SHA-256, and ECDSA P-256 SHA-256. 983 Appendix E. Acknowledgements 985 The authors acknowledge that the design of JWTs was intentionally 986 influenced by the design and simplicity of Simple Web Tokens [SWT] 987 and ideas for JSON tokens that Dick Hardt discussed within the OpenID 988 community. 990 Solutions for signing JSON content were previously explored by Magic 991 Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas 992 Applications [CanvasApp], all of which influenced this draft. 994 Appendix F. Document History 996 -03 997 o Added "http://openid.net/specs/jwt/1.0" as a token type identifier 998 URI for JWTs. 1000 o Added "iat" (issued at) claim. 1002 o Changed RSA SHA-256 from MUST be supported to RECOMMENDED that it 1003 be supported. Rationale: Several people have objected to the 1004 requirement for implementing RSA SHA-256, some because they will 1005 only be using HMACs and symmetric keys, and others because they 1006 only want to use ECDSA when using asymmetric keys, either for 1007 security or key length reasons, or both. 1009 o Defined "alg" value ""none"" to represent unsigned JWTs. 1011 -02 1013 o Split signature specification out into separate 1014 draft-jones-json-web-signature-00. This split introduced no 1015 semantic changes. 1017 o The JWT Compact Serialization is now the only token serialization 1018 format specified in this draft. The JWT JSON Serialization can 1019 continue to be defined in a companion specification. 1021 -01 1023 o Draft incorporating consensus decisions reached at IIW. 1025 -00 1027 o Public draft published before November 2010 IIW based upon the 1028 JSON token convergence proposal incorporating input from several 1029 implementers of related specifications. 1031 Authors' Addresses 1033 Michael B. Jones 1034 Microsoft 1036 Email: mbj@microsoft.com 1037 URI: http://self-issued.info/ 1038 Dirk Balfanz 1039 Google 1041 Email: balfanz@google.com 1043 John Bradley 1044 independent 1046 Email: ve7jtb@ve7jtb.com 1048 Yaron Y. Goland 1049 Microsoft 1051 Email: yarong@microsoft.com 1053 John Panzer 1054 Google 1056 Email: jpanzer@google.com 1058 Nat Sakimura 1059 Nomura Research Institute 1061 Email: n-sakimura@nri.co.jp 1063 Paul Tarjan 1064 Facebook 1066 Email: pt@fb.com