idnits 2.17.1 draft-miller-json-constrained-notation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (May 18, 2017) is 2535 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '1' on line 796 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Miller 3 Internet-Draft 4 Intended status: Standards Track P. Saint-Andre 5 Expires: November 19, 2017 Filament 6 May 18, 2017 8 JSON Constrained Notation (JSCN) 9 draft-miller-json-constrained-notation-00 11 Abstract 13 This specification addresses the challenges of using JavaScript 14 Object Notation (JSON) with constrained devices by providing a 15 standard set of mapping rules to Concise Binary Object Representation 16 (CBOR) that preserve all semantic information, such that the original 17 JSON string can be identically re-created. JSON Constrained Notation 18 can also be used by devices as a native data format, which can then 19 be represented as JSON when necessary for diagnostics, compatibility, 20 and ease of integration with higher-level systems. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 19, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. CBOR Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Structured Types . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Primitive Types . . . . . . . . . . . . . . . . . . . . . 5 61 2.2.1. Boolean and Null . . . . . . . . . . . . . . . . . . 5 62 2.2.2. Numbers . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.3. Strings . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Reference Sets . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Canonical Form . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Formatting-only Whitespace . . . . . . . . . . . . . . . 7 67 4.2. String Escapes . . . . . . . . . . . . . . . . . . . . . 9 68 5. Constrained API . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1.2. Optimized JSCN Encoding . . . . . . . . . . . . . . . 11 73 6.1.3. Un-optimized JSCN Encoding . . . . . . . . . . . . . 13 74 6.2. JSON Web Token . . . . . . . . . . . . . . . . . . . . . 15 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7.1. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.2. JSCN Reference Sets Registry . . . . . . . . . . . . . . 17 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 9.2. Informative References . . . . . . . . . . . . . . . . . 18 82 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 Although JavaScript Object Notation (JSON) [RFC7159] has been widely 89 adopted in traditional networking and software environments, its use 90 in embedded and constrained environments has been more limited 91 because of the minimal storage and network capacities inherent in 92 low-cost and low-power devices (see [RFC7228]). 94 This specification addresses the challenges of using JSON with 95 constrained devices by defining a set of mapping rules to Concise 96 Binary Object Representation (CBOR) [RFC7049] that preserve all 97 semantic information, such that the original JSON string can be 98 identically re-created. JSON Constrained Notation (JSCN) can be used 99 directly by devices as a native data format, which can be represented 100 as JSON when necessary for diagnostics, compatibility, and ease of 101 integration with higher-level systems. 103 A primary goal of JSCN is to enable all JSON Object Signing and 104 Encryption (JOSE) standards ([RFC7515], [RFC7516], [RFC7517], 105 [RFC7518], [RFC7519]) to be used unmodified in constrained 106 environments. One result is that OpenID Connect [1] (which utilizes 107 JSON Web Tokens [RFC7519]) can more easily be adopted as an identity 108 management solution for the Internet of Things. 110 JSCN is designed to leverage, not replace, CBOR. Instead, JSCN 111 specifies rules for re-coding JSON structures by mapping them to 112 their CBOR parallels whenever possible, and then increasing the 113 efficiency through introspection and replacement of well-known 114 strings with compact references. 116 All transcoding software MUST operate on a UTF-8 JSON string whenever 117 complete round-trip compatibility to and from JSON is required, 118 including mapping any contained non-structural whitespace (such as 119 with JWTs for signature validation). If a transcoder is only 120 operating with an already parsed JSON value (the result of 121 "JSON.parse()" in JavaScript for instance), the round-trip can only 122 guarantee semantic compatibility of the values as represented in that 123 parsed context (only the JavaScript object will always match). 125 A significant reduction in space is also provided in JSCN when the 126 device and application contexts can make use of built-in or shared 127 UTF-8 string references. These references provide a mapping of 128 common JSON string values to an integer that used to replace the 129 string in the resulting CBOR during re-coding. JSON string values 130 are also introspected for data that has a more compact CBOR type 131 (such as base64url and hexadecimal encoding). 133 The use of this specification can ensure that a UTF-8 JSON string 134 before and after re-coding will be byte-for-byte identical across 135 implementations, whereas the CBOR encoding is not designed to have 136 this property and MAY vary based on implementation choices and 137 reference sets available. There are basic API rules defined for 138 constrained software such that directly accessing the CBOR data 139 values will always provide a uniform view to an application across 140 variations in the underlying CBOR representation. 142 1.1. Terminology 144 Many terms used in this document are defined in the specifications 145 for JSON [RFC7159] and CBOR [RFC7049]. This specification defines 146 the following additional terms: 148 o Constrained JSON Tag 150 * The CBOR tag registered in this specification to indicate an 151 array that contains JSON data encoded as CBOR according to this 152 specification. 154 o Reference 156 * A pointer within JSCN data that refers to a well-known UTF-8 157 string by using a CBOR byte string of length one, where the 158 byte value is the lookup identifier for the Reference. 160 o Reference Set 162 * A CBOR array of UTF-8 strings that are used to replace any 163 Reference within any JSCN data, where the Reference identifier 164 is the array offset to the replacement string and the first 165 position in the array identifies the Reference Set. 167 o Canonical Hints 169 * A CBOR array of integers that indicate positional offsets for 170 JSON string escape sequences or structural formatting 171 whitespace strings (, "\n", "\r", and "\t") such that when any 172 CBOR encoded data is stringified into JSON it can also 173 optionally be corrected to exactly match the original JSON 174 string. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 2. CBOR Encoding 182 JSCN encodes JSON data types to CBOR data types as described in the 183 following sections. 185 2.1. Structured Types 187 JSON defines two structured types: arrays and objects. These are 188 serialized to CBOR major type 4 (array) and type 5 (map), 189 respectively. Ordering of key/value pairs in JSON objects and CBOR 190 maps MUST be preserved. 192 2.2. Primitive Types 194 2.2.1. Boolean and Null 196 The JSON literal names "false", "true", and "null" are serialized to 197 the CBOR major type 7 simple values 20, 21, and 22 respectively. 199 2.2.2. Numbers 201 A JSCN encoder attempts to encode a JSON number as a CBOR unsigned 202 integer (type 0), negative integer (type 1), or float (type 7) and 203 then test for compatibility by round-tripping the CBOR data item back 204 to a JSON number. If the resulting JSON number is not equivalent to 205 the input number, the encoder MUST instead encode it as a CBOR 206 Bigfloat (tag 5). 208 The JSON exponent value (if any) is encoded as a CBOR exponent (tag 209 4). If the contained "e" symbol is upper case in JSON, the "Upper 210 Case Modifier" tag defined below MUST be included. 212 2.2.3. Strings 214 A JSON string is normally encoded as an un-escaped CBOR UTF-8 string 215 (type 3), i.e., as a series of UTF-8 [RFC3629] characters (e.g., the 216 word "one" is encoded as "6F6E65") without any backspace escaping for 217 control or unicode characters. 219 2.2.3.1. Base64 / Base16 Encoded 221 A JSCN encoder MUST round-trip test all JSON strings for possible 222 encodings (base64url, base64, and hexadecimal) by attempting to 223 decode and re-encode them. If identical byte strings result, the 224 decoded value is tagged in CBOR with the encoding format (tags 21, 225 22, and 23). For hexadecimal, the "Upper Case Modifier" tag defined 226 below MUST be included if the hexadecimal letters A-F are upper case 227 in the original JSON string. 229 A JSCN encoder MUST perform introspection on the resulting decoded 230 byte string to determine if it begins with a JSON structure byte of 231 '{' or '['. The encoder SHOULD then round-trip test the string as a 232 possible JSON object or array so that it can encode the string more 233 efficiently into a CBOR data item instead of a byte string (this 234 pattern is common in the JOSE specification). 236 3. Reference Sets 238 The Constrained JSON Tag is followed by an array whose second item 239 identifies the Reference Set used in the data. This is either a 240 Reference Set identifier or an array that defines an inline Reference 241 Set. 243 A Reference Set identifier is a unique integer that maps to a 244 Reference Set known to applications using the set. Public, well- 245 known reference sets can be registered as described in the IANA 246 Considerations section of this document. 248 The Reference Set definition is encoded as a JSCN array, where the 249 first value is the Reference Set identifier followed by all of the 250 UTF-8 string keys. A key's position in the array is the byte value 251 with which it is replaced. 253 Any Reference Set can include another Reference Set by encoding the 254 second set's identifer in the JSCN array that defines the first 255 Reference Set. Any byte strings in the definition array are then 256 replaced with the key from the references contained in the second 257 Reference Set. 259 JSON UTF-8 strings representing keys or values are first checked 260 against all active references (if any) for possible replacement. A 261 replacement is always a CBOR byte string (type 2) of length 1, where 262 the single byte represents the index value of the key in the 263 references array from 1-255. Value 0 and byte lengths greater than 1 264 are reserved for future use. 266 When a JSCN decoder generates JSON values from CBOR and it encounters 267 a CBOR byte string (type 2), single byte value MUST match the array 268 offset of the active references to be used as the replacement for 269 that byte string. 271 The following is the encoded form of a Reference Set as defined by 272 the JSON array of "[1,"map","value","array","one","two","three","bool 273 ","neg","simple","ints"]": 275 D4 # tag(20) 276 81 # array(1) 277 8B # array(11) 278 01 # unsigned(1) 279 63 # text(3) 280 6D6170 # "map" 281 65 # text(5) 282 76616C7565 # "value" 283 65 # text(5) 284 6172726179 # "array" 285 63 # text(3) 286 6F6E65 # "one" 287 63 # text(3) 288 74776F # "two" 289 65 # text(5) 290 7468726565 # "three" 291 64 # text(4) 292 626F6F6C # "bool" 293 63 # text(3) 294 6E6567 # "neg" 295 66 # text(6) 296 73696D706C65 # "simple" 297 64 # text(4) 298 696E7473 # "ints" 300 4. Canonical Form 302 This specification directly supports use-cases such as JSON Web 303 Tokens ([RFC7518]) where the canonical form of UTF-8 JSON strings 304 always needs to be available for validation. This is accomplished by 305 optionally including any additional information to reproduce the 306 exact UTF-8 string as an array of Canonical Hints included with the 307 Constrained JSON Tag. 309 These hints are not typically necessary as most machine-generated 310 JSON does not include any extra insignificant bytes by default, even 311 when included they do not need to be processed unless the original 312 canonical form is requested. When required, these additional hints 313 also take a highly constrained form and are independently additive to 314 the contained CBOR data values such that those values remain uniform 315 to any constrained application. 317 4.1. Formatting-only Whitespace 319 When a Constrained JSON tag is present and the first item in the 320 tagged array is a CBOR structure (map or array), a third optional 321 item in the tagged array is a set of canonical whitespace hints for 322 any non-structural whitespace characters contained in the original 323 UTF-8 representation of the JSON object or array. 325 o Whitespace hints are contained in an array of integers that 326 indicate offsets of the locations of whitespace characters in an 327 original JSON string, and lookup values identifying which 328 whitespace characters were there. 330 o Each offset integer is relative to the position of the previous 331 offset such that all integers are of small values. 333 o A negative integer offset indicates a single ASCII space character 334 (0x20) at the offset of the positive value of that integer. 336 o An unsigned integer offset is followed by another integer, where 337 unsigned values (0-23) indicate a whitespace string in the pre- 338 defined lookup table, and negative values specify the number of 339 space characters (0x20) to repeat. 341 o When re-inserting whitespace characters to a JSON string, the 342 array MUST be applied sequentially so that each new offset matches 343 the original JSON string position. 345 The following 24 whitespace character hexadecimal sequences are used 346 as the shared reference lookup table by row (0-23) when processing 347 whitespace hints. This table is constructed to minimize the number 348 of references commonly required while also allowing any possible 349 whitespace character sequences to be identified. 351 0a 352 0a2020 353 0a20202020 354 0a202020202020 355 0a2020202020202020 356 0a20202020202020202020 357 0a202020202020202020202020 358 0a2020202020202020202020202020 359 09 360 0a09 361 0a0909 362 0a090909 363 0a09090909 364 0a0909090909 365 0a090909090909 366 0a09090909090909 367 0a0909090909090909 368 0d 369 0d0a 370 0d0a2020 371 0d0a20202020 372 0d0a09 373 0d0a0909 374 0d0a090909 376 4.2. String Escapes 378 JSON string values MAY contain escaped characters (as defined in 379 Section 7 of [RFC7159]) that become un-escaped in the process of re- 380 coding them into a CBOR UTF-8 string. When the canonical form is 381 being preserved and any escaped characters are detected in the 382 process of converting them from JSON to CBOR, those string values 383 MUST be individually tagged as Constrained JSON where the first 384 element in the tagged array is the CBOR UTF-8 string value and the 385 second value is an array of positional integers similar to the 386 whitespace hints. 388 When the position is an unsigned integer it indicates the UTF-8 389 character at that position is to be escaped with the "\uXXXX" form 390 with lower-case hexadecimal characters. When it is a negative 391 integer it indicates that it is to be escaped with the "\X" form and 392 MUST be in the set of JSON escaped control characters. 394 When the original escaping in the "\uXXXX" form was with upper case 395 hexadecimal characters the entire array MUST be tagged with Upper 396 Case Modifier. In the unlikely case that the original escaping 397 contained mixed-case hexadecimal, then the positional integer will 398 instead itself be an array of length two with the position being the 399 first element and a 4-byte UTF-8 string of the mixed-case hexadecimal 400 value being the second element. 402 5. Constrained API 404 In order to ease the use of JSCN in constrained environments, an 405 implementation SHOULD make data values available both as native CBOR 406 types and as JSON strings; this enables a constrained application to 407 choose either format regardless of how the data is represented in 408 CBOR. 410 For example, when the original JSON string value is encoded as a CBOR 411 base64url tag plus byte string, a constrained application accessing 412 the value as a string MUST receive the base64url encoded value and 413 not the decoded byte value. If the constrained application instead 414 accesses the value as a byte array it MUST get the decoded value if 415 available. 417 The representation of the value in CBOR SHOULD NOT alter behavior of 418 the application, a string value encoded as tag plus byte array SHOULD 419 NOT be used as an indication that it is a binary value and only the 420 application can make this determination based on external context. 422 6. Examples 424 6.1. JSON 426 6.1.1. Input 428 Consider the following JSON as input to a JSCN encoder. 430 { 431 "map": "value", 432 "array": [ 433 "one", 434 "two", 435 "three", 436 42 437 ], 438 "bool": true, 439 "neg": -42, 440 "simple": [ 441 false, 442 null, 443 "" 444 ], 445 "ints": [ 446 0, 447 1, 448 23, 449 24, 450 255, 451 256, 452 65535, 453 65536, 454 4294967295, 455 4294967296, 456 281474976710656, 457 -281474976710656 458 ] 459 } 461 6.1.2. Optimized JSCN Encoding 463 An optimized encoding would remove whitespace and use a Reference 464 Set. Here the references would be: 466 "[1,"map","value","array","one","two","three","bool","neg","simple"," 467 ints"]" 469 The resulting JSCN encoding is 90 bytes compared to 318 bytes for the 470 JSON input. 472 D4 # tag(20) 473 82 # array(2) 474 A6 # map(6) 475 41 # bytes(1) 476 01 # "\x01" 477 41 # bytes(1) 478 02 # "\x02" 479 41 # bytes(1) 480 03 # "\x03" 481 84 # array(4) 482 41 # bytes(1) 483 04 # "\x04" 484 41 # bytes(1) 485 05 # "\x05" 486 41 # bytes(1) 487 06 # "\x06" 488 18 2A # unsigned(42) 489 41 # bytes(1) 490 07 # "\a" 491 F5 # primitive(21) 492 41 # bytes(1) 493 08 # "\b" 494 38 29 # negative(41) 495 41 # bytes(1) 496 09 # "\t" 497 83 # array(3) 498 F4 # primitive(20) 499 F6 # primitive(22) 500 60 # text(0) 501 # "" 502 41 # bytes(1) 503 0A # "\n" 504 8C # array(12) 505 00 # unsigned(0) 506 01 # unsigned(1) 507 17 # unsigned(23) 508 18 18 # unsigned(24) 509 19 00FF # unsigned(255) 510 19 0100 # unsigned(256) 511 19 FFFF # unsigned(65535) 512 1A 00010000 # unsigned(65536) 513 1B 00000000FFFFFFFF # unsigned(4294967295) 514 1B 0000000100000000 # unsigned(4294967296) 515 1B 0001000000000000 # unsigned(281474976710656) 516 3B 0000FFFFFFFFFFFF # negative(281474976710655) 517 01 # unsigned(1) 519 6.1.3. Un-optimized JSCN Encoding 521 An un-optimized encoding would not use a Reference Set and would 522 preserve whitespace. The un-optimized encoding would reduce the data 523 from the 318 bytes (JSON) to 187 bytes (JSCN). 525 D4 # tag(20) 526 83 # array(3) 527 A6 # map(6) 528 63 # text(3) 529 6D6170 # "map" 530 65 # text(5) 531 76616C7565 # "value" 532 65 # text(5) 533 6172726179 # "array" 534 84 # array(4) 535 63 # text(3) 536 6F6E65 # "one" 537 63 # text(3) 538 74776F # "two" 539 65 # text(5) 540 7468726565 # "three" 541 18 2A # unsigned(42) 542 64 # text(4) 543 626F6F6C # "bool" 544 F5 # primitive(21) 545 63 # text(3) 546 6E6567 # "neg" 547 38 29 # negative(41) 548 66 # text(6) 549 73696D706C65 # "simple" 550 83 # array(3) 551 F4 # primitive(20) 552 F6 # primitive(22) 553 60 # text(0) 554 # "" 555 64 # text(4) 556 696E7473 # "ints" 557 8C # array(12) 558 00 # unsigned(0) 559 01 # unsigned(1) 560 17 # unsigned(23) 561 18 18 # unsigned(24) 562 19 00FF # unsigned(255) 563 19 0100 # unsigned(256) 564 19 FFFF # unsigned(65535) 565 1A 00010000 # unsigned(65536) 566 1B 00000000FFFFFFFF # unsigned(4294967295) 567 1B 0000000100000000 # unsigned(4294967296) 568 1B 0001000000000000 # unsigned(281474976710656) 569 3B 0000FFFFFFFFFFFF # negative(281474976710655) 570 00 # unsigned(0) 571 98 40 # array(64) 572 01 # unsigned(1) 573 01 # unsigned(1) 574 26 # negative(6) 575 08 # unsigned(8) 576 01 # unsigned(1) 577 28 # negative(8) 578 01 # unsigned(1) 579 02 # unsigned(2) 580 06 # unsigned(6) 581 02 # unsigned(2) 582 06 # unsigned(6) 583 02 # unsigned(2) 584 08 # unsigned(8) 585 02 # unsigned(2) 586 02 # unsigned(2) 587 01 # unsigned(1) 588 02 # unsigned(2) 589 01 # unsigned(1) 590 27 # negative(7) 591 05 # unsigned(5) 592 01 # unsigned(1) 593 26 # negative(6) 594 04 # unsigned(4) 595 01 # unsigned(1) 596 29 # negative(9) 597 01 # unsigned(1) 598 02 # unsigned(2) 599 06 # unsigned(6) 600 02 # unsigned(2) 601 05 # unsigned(5) 602 02 # unsigned(2) 603 02 # unsigned(2) 604 01 # unsigned(1) 605 02 # unsigned(2) 606 01 # unsigned(1) 607 27 # negative(7) 608 01 # unsigned(1) 609 02 # unsigned(2) 610 02 # unsigned(2) 611 02 # unsigned(2) 612 02 # unsigned(2) 613 02 # unsigned(2) 614 03 # unsigned(3) 615 02 # unsigned(2) 616 03 # unsigned(3) 617 02 # unsigned(2) 618 04 # unsigned(4) 619 02 # unsigned(2) 620 04 # unsigned(4) 621 02 # unsigned(2) 622 06 # unsigned(6) 623 02 # unsigned(2) 624 06 # unsigned(6) 625 02 # unsigned(2) 626 0B # unsigned(11) 627 02 # unsigned(2) 628 0B # unsigned(11) 629 02 # unsigned(2) 630 10 # unsigned(16) 631 02 # unsigned(2) 632 10 # unsigned(16) 633 01 # unsigned(1) 634 01 # unsigned(1) 635 00 # unsigned(0) 637 6.2. JSON Web Token 639 Consider the following JSON Web Token [RFC7519], which natively is 640 149 bytes (line endings are not significant): 642 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiO 643 iIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWR 644 taW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZ 645 geFONFh7HgQ 647 In a JSON encoding, the JWT would be 191 bytes (line endings are not 648 significant): 650 {"protected": 651 "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9", 652 "payload":"eyJzdWIiOiIxMjM0NTY3ODkwIiwib 653 mFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9", 654 "signature": 655 "TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh 656 7HgQ"} 658 Using a Reference Set of "[1,"payload","signature","protected","alg", 659 "HS256","sub","name","admin"]", the JSCN encoding would be 80 bytes. 661 D4 # tag(20) 662 82 # array(2) 663 A3 # map(3) 664 41 # bytes(1) 665 03 # "\x03" 666 D5 # tag(21) 667 A2 # map(2) 668 41 # bytes(1) 669 04 # "\x04" 670 41 # bytes(1) 671 05 # "\x05" 672 41 # bytes(1) 673 06 # "\x06" 674 41 # bytes(1) 675 07 # "\a" 676 41 # bytes(1) 677 01 # "\x01" 678 D5 # tag(21) 679 A3 # map(3) 680 41 # bytes(1) 681 08 # "\b" 682 D7 # tag(23) 683 45 # bytes(5) 684 1234567890 # "\x124Vx\x90" 685 41 # bytes(1) 686 09 # "\t" 687 68 # text(8) 688 4A6F686E20446F65 # "John Doe" 689 41 # bytes(1) 690 0A # "\n" 691 F5 # primitive(21) 692 41 # bytes(1) 693 02 # "\x02" 694 D5 # tag(21) 695 58 20 # bytes(32) 696 4C9540F793AB33B13670169BDF444C1EB1C37047F18 697 E861981E14E34587B1E04 # "L\x95@\xF7\x93\xAB3 698 \xB16p\x16\x9B\xDFDL\x1E\xB1\xC3pG\xF1\x8E 699 \x86\x19\x81\xE1N4X{\x1E\x04" 700 01 # unsigned(1) 702 7. IANA Considerations 704 7.1. CBOR Tags 706 The IANA is requested to assign the following tags from the "CBOR 707 Tags" registry defined in RFC 7049 [RFC7049]: 709 o Assign the tag "Constrained JSON" in the 1 to 23 value range (one 710 byte in length when encoded). 712 o Assign the tag "Upper Case Modifier" in the 24 to 255 value range 713 (two bytes in length when encoded). 715 The tags to be assigned are described below. 717 Tag 20 (Constrained JSON) 718 Data Item array 719 Semantics The first value in the array is a constrained 720 JSON data item encoded using JSCN, optionally 721 followed by an integer or array identifying any 722 embedded references, and then an optional array 723 of canonical hints (if any). 724 Reference http://quartzjer.github.io/JSCN 725 Contact Jeremie Miller 727 Tag 31 (Upper Case Modifier) 728 Data Item multiple 729 Semantics Indicates that the data item following contains 730 values where the upper case is semantically 731 important when interpreted in a UTF-8 string 732 context. 733 Reference http://quartzjer.github.io/JSCN 734 Contact Jeremie Miller 736 7.2. JSCN Reference Sets Registry 738 A future version of this document will request creation of a registry 739 for JSCN Reference Sets and provide initial registrations for the 740 existing JOSE JWE, JWS, and JWA RFCs. 742 8. Security Considerations 744 TODO 746 9. References 748 9.1. Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, 752 DOI 10.17487/RFC2119, March 1997, 753 . 755 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 756 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 757 2003, . 759 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 760 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 761 October 2013, . 763 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 764 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 765 2014, . 767 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 768 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 769 2015, . 771 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 772 RFC 7516, DOI 10.17487/RFC7516, May 2015, 773 . 775 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 776 DOI 10.17487/RFC7517, May 2015, 777 . 779 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 780 DOI 10.17487/RFC7518, May 2015, 781 . 783 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 784 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 785 . 787 9.2. Informative References 789 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 790 Constrained-Node Networks", RFC 7228, 791 DOI 10.17487/RFC7228, May 2014, 792 . 794 9.3. URIs 796 [1] http://openid.net/connect/ 798 Appendix A. Acknowledgements 800 Thanks to Carsten Bormann and David Waite for their comments. 802 Authors' Addresses 804 Jeremie Miller 806 Email: jeremie@jabber.org 808 Peter Saint-Andre 809 Filament 811 Email: peter@filament.com