File: rfc8785.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2860 lines) | stat: -rw-r--r-- 116,977 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8785: JSON Canonicalization Scheme (JCS)</title>
<meta content="Anders Rundgren" name="author">
<meta content="Bret Jordan" name="author">
<meta content="Samuel Erdtman" name="author">
<meta content='
       
        Cryptographic operations like hashing and signing need the data to be
        expressed in an invariant format so that the operations are reliably
        repeatable.

        One way to address this is to create a canonical representation of
        the data.  Canonicalization also permits data to be exchanged in its
        original form on the "wire" while cryptographic operations
        performed on the canonicalized counterpart of the data in the
        producer and consumer endpoints generate consistent results.
       
       
        This document describes the JSON Canonicalization Scheme (JCS).
        This specification defines how to create a canonical representation
        of JSON data by building on the strict serialization methods for
        JSON primitives defined by ECMAScript, constraining JSON data to
        the Internet JSON (I-JSON) subset, and by using deterministic property
 sorting.
       
    ' name="description">
<meta content="xml2rfc 2.46.0" name="generator">
<meta content="JSON" name="keyword">
<meta content="ECMAScript" name="keyword">
<meta content="Signatures" name="keyword">
<meta content="Cryptography" name="keyword">
<meta content="Canonicalization" name="keyword">
<meta content="8785" name="rfc.number">
<link href="rfc8785.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code {
  background-color: #f9f9f9;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8785" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-rundgren-json-canonicalization-scheme-17" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8785</td>
<td class="center">JSON Canonicalization Scheme</td>
<td class="right">June 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Rundgren, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8785" class="eref">8785</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-06" class="published">June 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">A. Rundgren</div>
<div class="org">Independent</div>
</div>
<div class="author">
      <div class="author-name">B. Jordan</div>
<div class="org">Broadcom</div>
</div>
<div class="author">
      <div class="author-name">S. Erdtman</div>
<div class="org">Spotify AB</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8785</h1>
<h1 id="title">JSON Canonicalization Scheme (JCS)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        Cryptographic operations like hashing and signing need the data to be
        expressed in an invariant format so that the operations are reliably
        repeatable.

        One way to address this is to create a canonical representation of
        the data.  Canonicalization also permits data to be exchanged in its
        original form on the "wire" while cryptographic operations
        performed on the canonicalized counterpart of the data in the
        producer and consumer endpoints generate consistent results.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
        This document describes the JSON Canonicalization Scheme (JCS).
        This specification defines how to create a canonical representation
        of JSON data by building on the strict serialization methods for
        JSON primitives defined by ECMAScript, constraining JSON data to
        the Internet JSON (I-JSON) subset, and by using deterministic property
 sorting.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8785">https://www.rfc-editor.org/info/rfc8785</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-detailed-operation" class="xref">Detailed Operation</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-creation-of-input-data" class="xref">Creation of Input Data</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-generation-of-canonical-jso" class="xref">Generation of Canonical JSON Data</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-whitespace" class="xref">Whitespace</a><a href="#section-toc.1-1.3.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="xref">3.2.2</a>.  <a href="#name-serialization-of-primitive-" class="xref">Serialization of Primitive Data Types</a><a href="#section-toc.1-1.3.2.2.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.2.2.1">
                        <p id="section-toc.1-1.3.2.2.2.2.2.1.1"><a href="#section-3.2.2.1" class="xref">3.2.2.1</a>.  <a href="#name-serialization-of-literals" class="xref">Serialization of Literals</a><a href="#section-toc.1-1.3.2.2.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                      <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.2.2.2">
                        <p id="section-toc.1-1.3.2.2.2.2.2.2.1"><a href="#section-3.2.2.2" class="xref">3.2.2.2</a>.  <a href="#name-serialization-of-strings" class="xref">Serialization of Strings</a><a href="#section-toc.1-1.3.2.2.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                      <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.2.2.3">
                        <p id="section-toc.1-1.3.2.2.2.2.2.3.1"><a href="#section-3.2.2.3" class="xref">3.2.2.3</a>.  <a href="#name-serialization-of-numbers" class="xref">Serialization of Numbers</a><a href="#section-toc.1-1.3.2.2.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                    </ul>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="xref">3.2.3</a>.  <a href="#name-sorting-of-object-propertie" class="xref">Sorting of Object Properties</a><a href="#section-toc.1-1.3.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.3.2.2.2.4">
                    <p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="xref">3.2.4</a>.  <a href="#name-utf-8-generation" class="xref">UTF-8 Generation</a><a href="#section-toc.1-1.3.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-ecmascript-sample-canonical" class="xref">ECMAScript Sample Canonicalizer</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-number-serialization-sample" class="xref">Number Serialization Samples</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-canonicalized-json-as-wire-" class="xref">Canonicalized JSON as "Wire Format"</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.d" class="xref">Appendix D</a>.  <a href="#name-dealing-with-big-numbers" class="xref">Dealing with Big Numbers</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.e" class="xref">Appendix E</a>.  <a href="#name-string-subtype-handling" class="xref">String Subtype Handling</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-e.1" class="xref">E.1</a>.  <a href="#name-subtypes-in-arrays" class="xref">Subtypes in Arrays</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.f" class="xref">Appendix F</a>.  <a href="#name-implementation-guidelines" class="xref">Implementation Guidelines</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.g" class="xref">Appendix G</a>.  <a href="#name-open-source-implementations" class="xref">Open-Source Implementations</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-appendix.h" class="xref">Appendix H</a>.  <a href="#name-other-json-canonicalization" class="xref">Other JSON Canonicalization Efforts</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-appendix.i" class="xref">Appendix I</a>.  <a href="#name-development-portal" class="xref">Development Portal</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.j" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#section-appendix.k" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="Introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
        This document describes the JSON Canonicalization Scheme (JCS).
        This specification defines how to create a canonical representation
        of JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> data by building
        on the strict serialization methods for
        JSON primitives defined by ECMAScript <span>[<a href="#ECMA-262" class="xref">ECMA-262</a>]</span>,
        constraining JSON data to the I-JSON <span>[<a href="#RFC7493" class="xref">RFC7493</a>]</span>
        subset, and by using deterministic property sorting. The output from
 JCS is a
        "hashable" representation of JSON data that can be used by
 cryptographic methods.
        The subsequent paragraphs outline the primary design considerations.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        Cryptographic operations like hashing and signing need the data to be
        expressed in an invariant format so that the operations are reliably
        repeatable.
        One way to accomplish this is to convert the data into
        a format that has a simple and fixed representation,
        like base64url <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span>.
        This is how JSON Web Signature (JWS) <span>[<a href="#RFC7515" class="xref">RFC7515</a>]</span> addressed this issue.
        Another solution is to create a canonical version of the data,
        similar to what was done for the XML signature <span>[<a href="#XMLDSIG" class="xref">XMLDSIG</a>]</span> standard.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">  
        The primary advantage with a canonicalizing scheme is that data
        can be kept in its original form. This is the core rationale behind
 JCS.
        Put another way, using canonicalization enables a JSON object to
 remain a JSON object
        even after being signed. This can simplify system design,
 documentation, and logging.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
        To avoid "reinventing the wheel", JCS relies on the serialization of
 JSON primitives
        (strings, numbers, and literals), as defined by ECMAScript (aka
 JavaScript)
        <span>[<a href="#ECMA-262" class="xref">ECMA-262</a>]</span> beginning with version 6.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
        Seasoned XML developers may recall difficulties getting XML signatures
        to validate.  This was usually due to different interpretations of the
 quite intricate
        XML canonicalization rules as well as of the equally complex
        Web Services security standards.
        The reasons why JCS should not suffer from similar issues are:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-6.1">
          JSON does not have a namespace concept and default values.<a href="#section-1-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.2">
          Data is constrained to the I‑JSON <span>[<a href="#RFC7493" class="xref">RFC7493</a>]</span> subset.
          This eliminates the need for specific parsers for dealing with
   canonicalization.<a href="#section-1-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.3">
          JCS-compatible serialization of JSON primitives is currently
   supported
          by most web browsers as well as by Node.js <span>[<a href="#NODEJS" class="xref">NODEJS</a>]</span>.<a href="#section-1-6.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.4">
          The full JCS specification is currently supported by multiple
          open-source implementations (see <a href="#open.source" class="xref">Appendix G</a>).
          See also <a href="#impl.guidelines" class="xref">Appendix F</a> for
   implementation 
          guidelines.<a href="#section-1-6.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-7">
        JCS is compatible with some existing systems relying on JSON
        canonicalization such as JSON Web Key (JWK) Thumbprint <span>[<a href="#RFC7638" class="xref">RFC7638</a>]</span> and Keybase <span>[<a href="#KEYBASE" class="xref">KEYBASE</a>]</span>.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">
        For potential uses outside of cryptography, see <span>[<a href="#I-D.rundgren-comparable-json" class="xref">JSONCOMP</a>]</span>.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
        The intended audiences of this document are JSON tool vendors as
        well as designers of JSON-based cryptographic solutions.
        The reader is assumed to be knowledgeable in ECMAScript, including the
 "JSON" object.<a href="#section-1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
        Note that this document is not on the IETF standards track. However, a
 conformant
        implementation is supposed to adhere to the specified behavior for
        security and interoperability reasons.  This text uses BCP 14 to
        describe that necessary behavior.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Operation">
<section id="section-3">
      <h2 id="name-detailed-operation">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-detailed-operation" class="section-name selfRef">Detailed Operation</a>
      </h2>
<p id="section-3-1">
        This section describes the details related to creating 
        a canonical JSON representation and how they are addressed by JCS.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        <a href="#impl.guidelines" class="xref">Appendix F</a> describes
        the <span class="bcp14">RECOMMENDED</span> way of adding JCS support to existing
 JSON tools.<a href="#section-3-2" class="pilcrow">¶</a></p>
<div id="json.datacreation">
<section id="section-3.1">
        <h3 id="name-creation-of-input-data">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-creation-of-input-data" class="section-name selfRef">Creation of Input Data</a>
        </h3>
<p id="section-3.1-1">
          Data to be canonically serialized is usually created by:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">
              Parsing previously generated JSON data.<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.2">
              Programmatically creating data.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.1-3">
          Irrespective of the method used, the data to be serialized
   <span class="bcp14">MUST</span> be adapted
          for I‑JSON <span>[<a href="#RFC7493" class="xref">RFC7493</a>]</span>
   formatting, which implies the following:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-4.1">
              JSON objects <span class="bcp14">MUST NOT</span> exhibit duplicate property
       names.<a href="#section-3.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-4.2">
              JSON string data <span class="bcp14">MUST</span> be expressible
              as Unicode <span>[<a href="#UNICODE" class="xref">UNICODE</a>]</span>.<a href="#section-3.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-4.3">
              JSON number data <span class="bcp14">MUST</span> be expressible
              as IEEE 754 <span>[<a href="#IEEE754" class="xref">IEEE754</a>]</span>
       double-precision values.
            For applications needing higher precision or longer integers than
            offered by IEEE 754 double precision, it is
     <span class="bcp14">RECOMMENDED</span> to represent such
            numbers as JSON strings; see <a href="#json.bignumbers" class="xref">Appendix D</a> for 
              details on how this can be performed in an interoperable and
       extensible way.<a href="#section-3.1-4.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.1-5">
          An additional constraint is that parsed JSON string data <span class="bcp14">MUST NOT</span> be altered during subsequent serializations.  For more
          information, see <a href="#string.subtypes" class="xref">Appendix E</a>.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">
          Note: Although the Unicode standard offers the possibility of
          rearranging certain character sequences, referred to as "Unicode
          Normalization" <span>[<a href="#UCNORM" class="xref">UCNORM</a>]</span>,
          JCS-compliant string processing does not take this into
          consideration. That is, all components involved in a scheme
          depending on JCS <span class="bcp14">MUST</span> preserve Unicode string data
          "as is".<a href="#section-3.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.canonicalization">
<section id="section-3.2">
        <h3 id="name-generation-of-canonical-jso">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-generation-of-canonical-jso" class="section-name selfRef">Generation of Canonical JSON Data</a>
        </h3>
<p id="section-3.2-1">
          The following subsections describe the steps required to create a
   canonical
          JSON representation of the data elaborated on in the previous
   section.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">
          <a href="#canonicalize.js" class="xref">Appendix A</a> shows sample code
          for an ECMAScript-based canonicalizer, matching the JCS
   specification.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<div id="json.whitespace">
<section id="section-3.2.1">
          <h4 id="name-whitespace">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-whitespace" class="section-name selfRef">Whitespace</a>
          </h4>
<p id="section-3.2.1-1">
            Whitespace between JSON tokens <span class="bcp14">MUST NOT</span> be emitted.<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.serialization.data">
<section id="section-3.2.2">
          <h4 id="name-serialization-of-primitive-">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-serialization-of-primitive-" class="section-name selfRef">Serialization of Primitive Data Types</a>
          </h4>
<p id="section-3.2.2-1">
            Assume the following JSON object is parsed:<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<div id="section-3.2.2-2">
<pre class="sourcecode lang-json">
  {
    "numbers": [333333333.33333329, 1E30, 4.50,
                2e-3, 0.000000000000000000000000001],
    "string": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/",
    "literals": [null, true, false]
  }
</pre><a href="#section-3.2.2-2" class="pilcrow">¶</a>
</div>
<p id="section-3.2.2-3">
            If the parsed data is subsequently serialized using a serializer
            compliant with ECMAScript's "JSON.stringify()", the result would
            (with a line wrap added for display purposes only) be rather
            divergent with respect to the original data:<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
<div id="section-3.2.2-4">
<pre class="sourcecode lang-json">
  {"numbers":[333333333.3333333,1e+30,4.5,0.002,1e-27],"string":
  "€$\u000f\nA'B\"\\\\\"/","literals":[null,true,false]}
</pre><a href="#section-3.2.2-4" class="pilcrow">¶</a>
</div>
<p id="section-3.2.2-5">
            The reason for the difference between the parsed data and its
            serialized counterpart is due to a wide tolerance on input data
     (as defined
            by JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>), while output
     data (as defined by ECMAScript)
            has a fixed representation.  As can be seen in the example,
            numbers are subject to rounding as well.<a href="#section-3.2.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2.2-6">
            The following subsections describe the serialization of primitive
     JSON data types
            according to JCS.  This part is identical to that of ECMAScript.
            In the (unlikely) event that a future version of ECMAScript would
            invalidate any of the following serialization methods, it will be
            up to the developer community to
            either stick to this specification or create a new specification.<a href="#section-3.2.2-6" class="pilcrow">¶</a></p>
<div id="json.ser.literals">
<section id="section-3.2.2.1">
            <h5 id="name-serialization-of-literals">
<a href="#section-3.2.2.1" class="section-number selfRef">3.2.2.1. </a><a href="#name-serialization-of-literals" class="section-name selfRef">Serialization of Literals</a>
            </h5>
<p id="section-3.2.2.1-1">
              In accordance with JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>, 
              the literals "null", "true", and
              "false" <span class="bcp14">MUST</span> be serialized as null, true, and
       false, respectively.<a href="#section-3.2.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.ser.string">
<section id="section-3.2.2.2">
            <h5 id="name-serialization-of-strings">
<a href="#section-3.2.2.2" class="section-number selfRef">3.2.2.2. </a><a href="#name-serialization-of-strings" class="section-name selfRef">Serialization of Strings</a>
            </h5>
<p id="section-3.2.2.2-1">
              For JSON string data (which includes JSON object property names
              as well), each Unicode code point <span class="bcp14">MUST</span> be
              serialized as described below (see Section 24.3.2.2 of <span>[<a href="#ECMA-262" class="xref">ECMA-262</a>]</span>):<a href="#section-3.2.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.2.2-2.1">
                If the Unicode value falls within the traditional ASCII
                control character range (U+0000 through U+001F), it
                <span class="bcp14">MUST</span> be serialized using lowercase hexadecimal
                Unicode notation (\uhhhh) unless it is in the set of
                predefined JSON control characters U+0008, U+0009, U+000A,
                U+000C, or U+000D, which <span class="bcp14">MUST</span> be serialized as
                \b, \t, \n, \f, and \r, respectively.<a href="#section-3.2.2.2-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2.2.2-2.2">
                If the Unicode value is outside of the ASCII control character
                range, it <span class="bcp14">MUST</span> be serialized "as is"
                unless it is equivalent to U+005C (\) or U+0022 ("),
                which <span class="bcp14">MUST</span> be serialized as \\ and \",
                respectively.<a href="#section-3.2.2.2-2.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-3.2.2.2-3">
              Finally, the resulting sequence of Unicode code points
       <span class="bcp14">MUST</span> be enclosed in double quotes (").<a href="#section-3.2.2.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2.2.2-4">
              Note: Since invalid Unicode data like "lone surrogates" (e.g.,
       U+DEAD)
              may lead to interoperability issues including broken signatures,
              occurrences of such data <span class="bcp14">MUST</span> cause a compliant
       JCS implementation to terminate
              with an appropriate error.<a href="#section-3.2.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.ser.number">
<section id="section-3.2.2.3">
            <h5 id="name-serialization-of-numbers">
<a href="#section-3.2.2.3" class="section-number selfRef">3.2.2.3. </a><a href="#name-serialization-of-numbers" class="section-name selfRef">Serialization of Numbers</a>
            </h5>
<p id="section-3.2.2.3-1">
              ECMAScript builds on the IEEE 754 <span>[<a href="#IEEE754" class="xref">IEEE754</a>]</span> double-precision standard for representing
              JSON number data.  Such data <span class="bcp14">MUST</span> be serialized
              according to Section 7.1.12.1 of <span>[<a href="#ECMA-262" class="xref">ECMA-262</a>]</span>, including the "Note 2" enhancement.<a href="#section-3.2.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.2.3-2">
              Due to the relative complexity of this part, the algorithm 
              itself is not included in this document.
              For implementers of JCS-compliant number serialization,
              Google's implementation in V8 <span>[<a href="#V8" class="xref">V8</a>]</span> may serve as a reference.
              Another compatible number serialization reference implementation
              is Ryu <span>[<a href="#RYU" class="xref">RYU</a>]</span>,
              which is used by the JCS open-source Java implementation 
              mentioned in <a href="#open.source" class="xref">Appendix G</a>.
              <a href="#json.ieee754.test" class="xref">Appendix B</a> holds a set
             of IEEE 754 sample values and their
              corresponding JSON serialization.<a href="#section-3.2.2.3-2" class="pilcrow">¶</a></p>
<p id="section-3.2.2.3-3">
              Note: Since Not a Number (NaN) and Infinity
              are not permitted in JSON, occurrences of NaN or
              Infinity <span class="bcp14">MUST</span> cause a compliant JCS
              implementation to terminate with an appropriate error.<a href="#section-3.2.2.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="json.sorting.properties">
<section id="section-3.2.3">
          <h4 id="name-sorting-of-object-propertie">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-sorting-of-object-propertie" class="section-name selfRef">Sorting of Object Properties</a>
          </h4>
<p id="section-3.2.3-1">
            Although the previous step normalized the representation of
            primitive JSON data types, the result would not yet qualify as
            "canonical" since JSON object properties are not in lexicographic
            (alphabetical) order.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-2">
            Applied to the sample in <a href="#json.serialization.data" class="xref">Section 3.2.2</a>,
            a properly canonicalized version should (with a
            line wrap added for display purposes only) read as:<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
<div id="section-3.2.3-3">
<pre class="sourcecode lang-json">
  {"literals":[null,true,false],"numbers":[333333333.3333333,
  1e+30,4.5,0.002,1e-27],"string":"€$\u000f\nA'B\"\\\\\"/"}
</pre><a href="#section-3.2.3-3" class="pilcrow">¶</a>
</div>
<p id="section-3.2.3-4">
            The rules for lexicographic sorting of JSON object
            properties according to JCS are as follows:<a href="#section-3.2.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.3-5.1">
                JSON object properties <span class="bcp14">MUST</span> be sorted
 recursively,
                which means that JSON child Objects
                <span class="bcp14">MUST</span> have their properties sorted as well.<a href="#section-3.2.3-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.3-5.2">
              JSON array data <span class="bcp14">MUST</span> also be scanned for the
              presence of JSON objects (if an object is found, then its
       properties <span class="bcp14">MUST</span> be sorted),
              but array element order <span class="bcp14">MUST NOT</span> be changed.<a href="#section-3.2.3-5.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.2.3-6">
            When a JSON object is about to have its properties
            sorted, the following measures <span class="bcp14">MUST</span> be adhered to:<a href="#section-3.2.3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.3-7.1">
              The sorting process is applied to property name strings in their
       "raw" (unescaped) form.
              That is, a newline character is treated as U+000A.<a href="#section-3.2.3-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.3-7.2">
              Property name strings to be sorted are formatted
              as arrays of UTF-16 <span>[<a href="#UNICODE" class="xref">UNICODE</a>]</span>
       code units.
              The sorting is based on pure value comparisons, where code units
       are treated as
              unsigned integers, independent of locale settings.<a href="#section-3.2.3-7.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.3-7.3">
              <p id="section-3.2.3-7.3.1">
                Property name strings either have different values at some
 index that is
                a valid index for both strings, or their lengths are
 different, or both.
                If they have different values at one or more index
                positions, let k be the smallest such index; then, the string
 whose
                value at position k has the smaller value, as determined by
 using
                the "&lt;" operator, lexicographically precedes the other
 string.
                If there is no index position at which they differ,
                then the shorter string lexicographically precedes the longer
 string.<a href="#section-3.2.3-7.3.1" class="pilcrow">¶</a></p>
<p id="section-3.2.3-7.3.2">
                In plain English, this means that property names are sorted in
 ascending order like the following:<a href="#section-3.2.3-7.3.2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-ascii-art" id="section-3.2.3-7.3.3">
<pre>
        ""
        "a"
        "aa"
        "ab"
</pre><a href="#section-3.2.3-7.3.3" class="pilcrow">¶</a>
</div>
</li>
          </ul>
<p id="section-3.2.3-8">
            The rationale for basing the sorting algorithm on UTF-16 code
     units is that
            it maps directly to the string type in ECMAScript (featured in web
     browsers
            and Node.js), Java, and .NET.  In addition, JSON only supports
     escape sequences
            expressed as UTF-16 code units, making knowledge and handling of
     such data
            a necessity anyway.
            Systems using another internal representation of string data will
     need to convert
            JSON property name strings into arrays of UTF-16 code units before
     sorting.
            The conversion from UTF-8 or UTF-32 to UTF-16 is defined by the
            Unicode <span>[<a href="#UNICODE" class="xref">UNICODE</a>]</span> standard.<a href="#section-3.2.3-8" class="pilcrow">¶</a></p>
<p id="section-3.2.3-9">
   The following JSON test data can be used for verifying the correctness of
   the sorting scheme in a JCS implementation:<a href="#section-3.2.3-9" class="pilcrow">¶</a></p>
<div id="section-3.2.3-10">
<pre class="sourcecode lang-json">
  {
    "\u20ac": "Euro Sign",
    "\r": "Carriage Return",
    "\ufb33": "Hebrew Letter Dalet With Dagesh",
    "1": "One",
    "\ud83d\ude00": "Emoji: Grinning Face",
    "\u0080": "Control",
    "\u00f6": "Latin Small Letter O With Diaeresis"
  }
</pre><a href="#section-3.2.3-10" class="pilcrow">¶</a>
</div>
<p id="section-3.2.3-11">
            Expected argument order after sorting property strings:<a href="#section-3.2.3-11" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-ascii-art" id="section-3.2.3-12">
<pre>  "Carriage Return"
  "One"
  "Control"
  "Latin Small Letter O With Diaeresis"
  "Euro Sign"
  "Emoji: Grinning Face"
  "Hebrew Letter Dalet With Dagesh"</pre><a href="#section-3.2.3-12" class="pilcrow">¶</a>
</div>
<p id="section-3.2.3-13">
            Note: For the purpose of obtaining a deterministic property order,
            sorting of data encoded in UTF-8 or UTF-32 would also work, but
            the outcome for JSON data like above would differ and thus be
            incompatible with this specification.

            However, in practice, property names are rarely defined outside of
            7-bit ASCII, making it possible to sort string data in UTF-8 or
            UTF-32 format without conversion to UTF-16 and still be compatible
            with JCS.  Whether or not this is a viable option depends on the
            environment JCS is used in.<a href="#section-3.2.3-13" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.utf8">
<section id="section-3.2.4">
          <h4 id="name-utf-8-generation">
<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-utf-8-generation" class="section-name selfRef">UTF-8 Generation</a>
          </h4>
<p id="section-3.2.4-1">
            Finally, in order to create a platform-independent representation,
            the result of the preceding step <span class="bcp14">MUST</span> be encoded in
     UTF-8.<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
<p id="section-3.2.4-2">
            Applied to the sample in <a href="#json.sorting.properties" class="xref">Section 3.2.3</a>, this
            should yield the following bytes, here shown in hexadecimal
     notation:<a href="#section-3.2.4-2" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-ascii-art" id="section-3.2.4-3">
<pre>  7b 22 6c 69 74 65 72 61 6c 73 22 3a 5b 6e 75 6c 6c 2c 74 72
  75 65 2c 66 61 6c 73 65 5d 2c 22 6e 75 6d 62 65 72 73 22 3a
  5b 33 33 33 33 33 33 33 33 33 2e 33 33 33 33 33 33 33 2c 31
  65 2b 33 30 2c 34 2e 35 2c 30 2e 30 30 32 2c 31 65 2d 32 37
  5d 2c 22 73 74 72 69 6e 67 22 3a 22 e2 82 ac 24 5c 75 30 30
  30 66 5c 6e 41 27 42 5c 22 5c 5c 5c 5c 5c 22 2f 22 7d</pre><a href="#section-3.2.4-3" class="pilcrow">¶</a>
</div>
<p id="section-3.2.4-4">
            This data is intended to be usable as input to cryptographic
     methods.<a href="#section-3.2.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="IANA">
<section id="section-4">
      <h2 id="name-iana-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-4-1">
        This document has no IANA actions.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-5">
      <h2 id="name-security-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-5-1">
        It is crucial to perform sanity checks on input data to avoid
        overflowing buffers and similar things that could affect the
        integrity of the system.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        When JCS is applied to signature schemes like the one described
        in <a href="#impl.guidelines" class="xref">Appendix F</a>,
        applications <span class="bcp14">MUST</span> perform the following operations
 before acting
        upon received data:<a href="#section-5-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-3">
        <li id="section-5-3.1">
          Parse the JSON data and verify that it adheres to I-JSON.<a href="#section-5-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-3.2">
          Verify the data for correctness according to the conventions defined
   by the
          ecosystem where it is to be used.   This also includes locating the
          property holding the signature data.<a href="#section-5-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-5-3.3">
          Verify the signature.<a href="#section-5-3.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-5-4">
        If any of these steps fail, the operation in progress
 <span class="bcp14">MUST</span> be aborted.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-6">
      <h2 id="name-references">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-6.1">
        <h3 id="name-normative-references">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="ECMA-262">[ECMA-262]</dt>
        <dd>
<span class="refAuthor">ECMA International</span>, <span class="refTitle">"ECMAScript 2019 Language Specification"</span>, <span class="refContent">Standard ECMA-262 10th Edition</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.ecma-international.org/ecma-262/10.0/index.html">https://www.ecma-international.org/ecma-262/10.0/index.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE754">[IEEE754]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Floating-Point Arithmetic"</span>, <span class="refContent">IEEE 754-2019</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2019.8766229</span>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/8766229">https://ieeexplore.ieee.org/document/8766229</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7493">[RFC7493]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The I-JSON Message Format"</span>, <span class="seriesInfo">RFC 7493</span>, <span class="seriesInfo">DOI 10.17487/RFC7493</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7493">https://www.rfc-editor.org/info/rfc7493</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="UCNORM">[UCNORM]</dt>
        <dd>
<span class="refAuthor">The Unicode Consortium</span>, <span class="refTitle">"Unicode Normalization Forms"</span>, <span>&lt;<a href="https://www.unicode.org/reports/tr15/">https://www.unicode.org/reports/tr15/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="UNICODE">[UNICODE]</dt>
      <dd>
<span class="refAuthor">The Unicode Consortium</span>, <span class="refTitle">"The Unicode Standard"</span>, <span>&lt;<a href="https://www.unicode.org/versions/latest/">https://www.unicode.org/versions/latest/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-6.2">
        <h3 id="name-informative-references">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.rundgren-comparable-json">[JSONCOMP]</dt>
        <dd>
<span class="refAuthor">Rundgren, A.</span>, <span class="refTitle">""Comparable" JSON (JSONCOMP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-rundgren-comparable-json-04</span>, <time datetime="2019-02-13" class="refDate">13 February 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-rundgren-comparable-json-04">https://tools.ietf.org/html/draft-rundgren-comparable-json-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="KEYBASE">[KEYBASE]</dt>
        <dd>
<span class="refAuthor">Keybase</span>, <span class="refTitle">"Canonical Packings for JSON and Msgpack"</span>, <span>&lt;<a href="https://keybase.io/docs/api/1.0/canonical_packings">https://keybase.io/docs/api/1.0/canonical_packings</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NODEJS">[NODEJS]</dt>
        <dd>
<span class="refAuthor">OpenJS Foundation</span>, <span class="refTitle">"Node.js"</span>, <span>&lt;<a href="https://nodejs.org">https://nodejs.org</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="OPENAPI">[OPENAPI]</dt>
        <dd>
<span class="refAuthor">OpenAPI Initiative</span>, <span class="refTitle">"The OpenAPI Specification: a broadly adopted industry standard for describing modern APIs"</span>, <span>&lt;<a href="https://www.openapis.org/">https://www.openapis.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7515">[RFC7515]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor">, Bradley, J.</span><span class="refAuthor">, and N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7638">[RFC7638]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span><span class="refAuthor"> and N. Sakimura</span>, <span class="refTitle">"JSON Web Key (JWK) Thumbprint"</span>, <span class="seriesInfo">RFC 7638</span>, <span class="seriesInfo">DOI 10.17487/RFC7638</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7638">https://www.rfc-editor.org/info/rfc7638</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RYU">[RYU]</dt>
        <dd>
<span class="refTitle">"Ryu floating point number serializing algorithm"</span>, <span class="refContent">commit 27d3c55</span>, <time datetime="2020-05" class="refDate">May 2020</time>, <span>&lt;<a href="https://github.com/ulfjack/ryu">https://github.com/ulfjack/ryu</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="V8">[V8]</dt>
        <dd>
<span class="refAuthor">Google LLC</span>, <span class="refTitle">"What is V8?"</span>, <span>&lt;<a href="https://v8.dev/">https://v8.dev/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="XMLDSIG">[XMLDSIG]</dt>
      <dd>
<span class="refAuthor">W3C</span>, <span class="refTitle">"XML Signature Syntax and Processing Version 1.1"</span>, <span class="refContent">W3C Recommendation</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.w3.org/TR/xmldsig-core1/">https://www.w3.org/TR/xmldsig-core1/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="canonicalize.js">
<section id="section-appendix.a">
      <h2 id="name-ecmascript-sample-canonical">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-ecmascript-sample-canonical" class="section-name selfRef">ECMAScript Sample Canonicalizer</a>
      </h2>
<p id="section-appendix.a-1">
        Below is an example of a JCS canonicalizer for usage with
 ECMAScript-based systems:<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<div id="section-appendix.a-2">
<pre class="sourcecode lang-javascript">
  ////////////////////////////////////////////////////////////
  // Since the primary purpose of this code is highlighting //
  // the core of the JCS algorithm, error handling and      //
  // UTF-8 generation were not implemented.                 //
  ////////////////////////////////////////////////////////////
  var canonicalize = function(object) {

      var buffer = '';
      serialize(object);
      return buffer;

      function serialize(object) {
          if (object === null || typeof object !== 'object' ||
              object.toJSON != null) {
              /////////////////////////////////////////////////
              // Primitive type or toJSON, use "JSON"        //
              /////////////////////////////////////////////////
              buffer += JSON.stringify(object);

          } else if (Array.isArray(object)) {
              /////////////////////////////////////////////////
              // Array - Maintain element order              //
              /////////////////////////////////////////////////
              buffer += '[';
              let next = false;
              object.forEach((element) =&gt; {
                  if (next) {
                      buffer += ',';
                  }
                  next = true;
                  /////////////////////////////////////////
                  // Array element - Recursive expansion //
                  /////////////////////////////////////////
                  serialize(element);
              });
              buffer += ']';

          } else {
              /////////////////////////////////////////////////
              // Object - Sort properties before serializing //
              /////////////////////////////////////////////////
              buffer += '{';
              let next = false;
              Object.keys(object).sort().forEach((property) =&gt; {
                  if (next) {
                      buffer += ',';
                  }
                  next = true;
                  /////////////////////////////////////////////
                  // Property names are strings, use "JSON"  //
                  /////////////////////////////////////////////
                  buffer += JSON.stringify(property);
                  buffer += ':';
                  //////////////////////////////////////////
                  // Property value - Recursive expansion //
                  //////////////////////////////////////////
                  serialize(object[property]);
              });
              buffer += '}';
          }
      }
  };
</pre><a href="#section-appendix.a-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="json.ieee754.test">
<section id="section-appendix.b">
      <h2 id="name-number-serialization-sample">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-number-serialization-sample" class="section-name selfRef">Number Serialization Samples</a>
      </h2>
<p id="section-appendix.b-1">
        The following table holds a set of ECMAScript-compatible number
 serialization samples,
        including some edge cases.  The column
        "IEEE 754" refers to the internal
        ECMAScript representation of the "Number" data type, which is based on
 the
        IEEE 754 <span>[<a href="#IEEE754" class="xref">IEEE754</a>]</span> standard using
 64-bit (double-precision) values,
        here expressed in hexadecimal.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<span id="name-ecmascript-compatible-json-"></span><div id="ECMAScript-TABLE">
<table class="center" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-ecmascript-compatible-json-" class="selfRef">ECMAScript-Compatible JSON Number Serialization Samples</a>
        </caption>
<thead>
          <tr>
            <th class="text-center" rowspan="1" colspan="1">IEEE 754</th>
            <th class="text-center" rowspan="1" colspan="1">JSON Representation</th>
            <th class="text-center" rowspan="1" colspan="1">Comment</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>0000000000000000</code>
            </td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>0</code>
            </td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Zero</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>8000000000000000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>0</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Minus zero</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>0000000000000001</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>5e-324</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Min pos number</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>8000000000000001</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>-5e-324</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Min neg number</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>7fefffffffffffff</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>1.7976931348623157e+308</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Max pos number</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>ffefffffffffffff</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>-1.7976931348623157e+308</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Max neg number</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>4340000000000000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>9007199254740992</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Max pos
int    (1)</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>c340000000000000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>-9007199254740992</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Max neg
int    (1)</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>4430000000000000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>295147905179352830000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>~2**68         (2)
</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>7fffffffffffffff</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>NaN            (3)</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>7ff0000000000000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Infinity       (3)</code>
</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>44b52d02c7e14af5</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>9.999999999999997e+22</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>44b52d02c7e14af6</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>1e+23</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>44b52d02c7e14af7</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>1.0000000000000001e+23</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>444b1ae4d6e2ef4e</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>999999999999999700000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>444b1ae4d6e2ef4f</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>999999999999999900000</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>444b1ae4d6e2ef50</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>1e+21</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>3eb0c6f7a0b5ed8c</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>9.999999999999997e-7</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>3eb0c6f7a0b5ed8d</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>0.000001</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
      </td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>41b3de4355555553</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>333333333.3333332</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>41b3de4355555554</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>333333333.33333325</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>41b3de4355555555</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>333333333.3333333</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>41b3de4355555556</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>333333333.3333334</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>41b3de4355555557</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>333333333.33333343</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>becbf647612f3696</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>-0.0000033333333333333333</code>
</td>
            <td class="text-left" rowspan="1" colspan="1"></td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">
              <code>43143ff3c1cb0959</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>1424953923781206.2</code>
</td>
            <td class="text-left" rowspan="1" colspan="1">
              <code>Round to even  (4)</code>
</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-appendix.b-3">
        Notes:<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-appendix.b-4">
        <dt>(1)</dt>
<dd id="section-appendix.b-4.1">
          For maximum compliance with the ECMAScript "JSON" object,
          values that are to be interpreted as true integers
          <span class="bcp14">SHOULD</span> be in the range -9007199254740991 to
   9007199254740991.
          However, how numbers are used in applications does not affect the
   JCS algorithm.<a href="#section-appendix.b-4.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-appendix.b-4.2">
          Although a set of specific integers like 2**68 could be regarded as
   having
          extended precision, the JCS/ECMAScript number serialization
          algorithm does not take this into consideration.<a href="#section-appendix.b-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-appendix.b-4.3">
            Values out of range are not permitted in JSON.
            See <a href="#json.ser.number" class="xref">Section 3.2.2.3</a>.<a href="#section-appendix.b-4.3" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(4)</dt>
<dd id="section-appendix.b-4.4">
          This number is exactly 1424953923781206.25 but will, after the "Note
   2" rule
          mentioned in <a href="#json.ser.number" class="xref">Section 3.2.2.3</a>, be
   truncated and
          rounded to the closest even value.<a href="#section-appendix.b-4.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-appendix.b-5">
        For a more exhaustive validation of a JCS number serializer, you may
        test against a file (currently) available in the development portal
        (see <a href="#json.development" class="xref">Appendix I</a>) containing a
        large set of sample values. Another option is running V8 <span>[<a href="#V8" class="xref">V8</a>]</span> as a live reference together with a
        program generating a substantial amount of random IEEE 754 values.<a href="#section-appendix.b-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.wireformat">
<section id="section-appendix.c">
      <h2 id="name-canonicalized-json-as-wire-">
<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-canonicalized-json-as-wire-" class="section-name selfRef">Canonicalized JSON as "Wire Format"</a>
      </h2>
<p id="section-appendix.c-1">
        Since the result from the canonicalization process (see <a href="#json.utf8" class="xref">Section 3.2.4</a>) is fully valid JSON, it can
        also be used as "Wire Format".  However, this is just an option since
        cryptographic schemes based on JCS, in most cases, would not depend on
        that externally supplied JSON data already being canonicalized.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<p id="section-appendix.c-2">
        In fact, the ECMAScript standard way of serializing objects using
        "JSON.stringify()" produces a
        more "logical" format, where properties are
        kept in the order they were created or received.  The
        example below shows an address record that could benefit from
        ECMAScript standard serialization:<a href="#section-appendix.c-2" class="pilcrow">¶</a></p>
<div id="section-appendix.c-3">
<pre class="sourcecode lang-json">
  {
    "name": "John Doe",
    "address": "2000 Sunset Boulevard",
    "city": "Los Angeles",
    "zip": "90001",
    "state": "CA"
  }
</pre><a href="#section-appendix.c-3" class="pilcrow">¶</a>
</div>
<p id="section-appendix.c-4">
        Using canonicalization, the properties above would be output in the
 order
        "address", "city", "name", "state", and "zip", which adds fuzziness
        to the data from a human (developer or technical support) perspective.
        Canonicalization also converts JSON data into a single line of text,
 which may
        be less than ideal for debugging and logging.<a href="#section-appendix.c-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.bignumbers">
<section id="section-appendix.d">
      <h2 id="name-dealing-with-big-numbers">
<a href="#section-appendix.d" class="section-number selfRef">Appendix D. </a><a href="#name-dealing-with-big-numbers" class="section-name selfRef">Dealing with Big Numbers</a>
      </h2>
<p id="section-appendix.d-1">
        There are several issues associated with the
        JSON number type, here illustrated by the following
        sample object:<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
<div id="section-appendix.d-2">
<pre class="sourcecode lang-json">
  {
    "giantNumber": 1.4e+9999,
    "payMeThis": 26000.33,
    "int64Max": 9223372036854775807
  }
</pre><a href="#section-appendix.d-2" class="pilcrow">¶</a>
</div>
<p id="section-appendix.d-3">
        Although the sample above conforms to JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>,
        applications would normally use different native data types for
 storing
        "giantNumber" and "int64Max".  In addition, monetary data like
 "payMeThis" would
        presumably not rely on floating-point data types due to rounding
 issues with respect
        to decimal arithmetic.<a href="#section-appendix.d-3" class="pilcrow">¶</a></p>
<p id="section-appendix.d-4">
        The established way of handling this kind of "overloading" of the
        JSON number type (at least in an extensible manner) is through
        mapping mechanisms, instructing parsers what to do with different
 properties
        based on their name.  However, this greatly limits the value of using
 the
        JSON number type outside of its original, somewhat constrained
 JavaScript context.
        The ECMAScript "JSON" object does not support mappings to the JSON
 number type either.<a href="#section-appendix.d-4" class="pilcrow">¶</a></p>
<p id="section-appendix.d-5">
        Due to the above, numbers that do not have a natural place in the
 current
        JSON ecosystem <span class="bcp14">MUST</span> be wrapped using the JSON string
 type.  This is close to
        a de facto standard for open systems.  This is also applicable for
        other data types that do not have direct support in JSON, like
 "DateTime"
        objects as described in <a href="#string.subtypes" class="xref">Appendix E</a>.<a href="#section-appendix.d-5" class="pilcrow">¶</a></p>
<p id="section-appendix.d-6">
        Aided by a system using the JSON string type, be it programmatic like<a href="#section-appendix.d-6" class="pilcrow">¶</a></p>
<div id="section-appendix.d-7">
<pre class="sourcecode">
  var obj = JSON.parse('{"giantNumber": "1.4e+9999"}');
  var biggie = new BigNumber(obj.giantNumber);
</pre><a href="#section-appendix.d-7" class="pilcrow">¶</a>
</div>
<p id="section-appendix.d-8">
        or declarative schemes like OpenAPI <span>[<a href="#OPENAPI" class="xref">OPENAPI</a>]</span>,
        JCS imposes no limits on applications, including when using
 ECMAScript.<a href="#section-appendix.d-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="string.subtypes">
<section id="section-appendix.e">
      <h2 id="name-string-subtype-handling">
<a href="#section-appendix.e" class="section-number selfRef">Appendix E. </a><a href="#name-string-subtype-handling" class="section-name selfRef">String Subtype Handling</a>
      </h2>
<p id="section-appendix.e-1">
        Due to the limited set of data types featured in JSON, the JSON string
        type is commonly used for holding subtypes.  This can, depending on
        JSON parsing method, lead to interoperability problems, which
        <span class="bcp14">MUST</span> be dealt with by JCS-compliant applications
        targeting a wider audience.<a href="#section-appendix.e-1" class="pilcrow">¶</a></p>
<p id="section-appendix.e-2">
        Assume you want to parse a JSON object where the schema
        designer assigned the property "big" for holding a "BigInt" subtype
 and
        "time" for holding a "DateTime" subtype, while "val" is supposed to be
 a JSON number
        compliant with JCS. The following example shows such an object:<a href="#section-appendix.e-2" class="pilcrow">¶</a></p>
<div id="section-appendix.e-3">
<pre class="sourcecode lang-json">
  {
    "time": "2019-01-28T07:45:10Z",
    "big": "055",
    "val": 3.5
  }
</pre><a href="#section-appendix.e-3" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-4">Parsing of this object can be accomplished by the following
      ECMAScript statement:<a href="#section-appendix.e-4" class="pilcrow">¶</a></p>
<div id="section-appendix.e-5">
<pre class="sourcecode">
  var object = JSON.parse(JSON_object_featured_as_a_string);
</pre><a href="#section-appendix.e-5" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-6">After parsing, the actual data can be extracted, which for subtypes,
      also involves a conversion step using the result of the parsing process
      (an ECMAScript object) as input:<a href="#section-appendix.e-6" class="pilcrow">¶</a></p>
<div id="section-appendix.e-7">
<pre class="sourcecode">
  ... = new Date(object.time); // Date object
  ... = BigInt(object.big);    // Big integer
  ... = object.val;            // JSON/JS number
</pre><a href="#section-appendix.e-7" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-8">
        Note that the "BigInt" data type is currently only natively supported
 by V8 <span>[<a href="#V8" class="xref">V8</a>]</span>.<a href="#section-appendix.e-8" class="pilcrow">¶</a></p>
<p id="section-appendix.e-9">
        Canonicalization of "object" using the sample code in <a href="#canonicalize.js" class="xref">Appendix A</a> would return the
        following string:<a href="#section-appendix.e-9" class="pilcrow">¶</a></p>
<div id="section-appendix.e-10">
<pre class="sourcecode lang-json">
  {"big":"055","time":"2019-01-28T07:45:10Z","val":3.5}
</pre><a href="#section-appendix.e-10" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-11">
        Although this is (with respect to JCS) technically correct, there is
        another way of parsing JSON data, which also can be used with
        ECMAScript as shown below:<a href="#section-appendix.e-11" class="pilcrow">¶</a></p>
<div id="section-appendix.e-12">
<pre class="sourcecode">
  // "BigInt" requires the following code to become JSON serializable
  BigInt.prototype.toJSON = function() {
      return this.toString();
  };

  // JSON parsing using a "stream"-based method
  var object = JSON.parse(JSON_object_featured_as_a_string,
      (k,v) =&gt; k == 'time' ? new Date(v) : k == 'big' ? BigInt(v) : v
  );
</pre><a href="#section-appendix.e-12" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-13">
        If you now apply the canonicalizer in <a href="#canonicalize.js" class="xref">Appendix A</a> to "object", the following string would be
        generated:<a href="#section-appendix.e-13" class="pilcrow">¶</a></p>
<div id="section-appendix.e-14">
<pre class="sourcecode lang-json">
  {"big":"55","time":"2019-01-28T07:45:10.000Z","val":3.5}
</pre><a href="#section-appendix.e-14" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-15">
        In this case, the string arguments for "big" and "time" have changed
 with respect to the original,
        presumably making an application depending on JCS fail.<a href="#section-appendix.e-15" class="pilcrow">¶</a></p>
<p id="section-appendix.e-16">
        The reason for the deviation is that in stream- and schema-based JSON
 parsers,
        the original string argument is typically replaced on the fly
        by the native subtype that, when serialized, may exhibit a different
        and platform-dependent pattern.<a href="#section-appendix.e-16" class="pilcrow">¶</a></p>
<p id="section-appendix.e-17">
        That is, stream- and schema-based parsing <span class="bcp14">MUST</span> treat
        subtypes as "pure" (immutable) JSON string types and perform the
        actual conversion to the designated native type in a subsequent step.
        In modern programming platforms like Go, Java, and C#, this can be
        achieved with moderate efforts by combining annotations, getters, and
        setters.  Below is an example in C#/Json.NET showing a part of a class
        that is serializable as a JSON object:<a href="#section-appendix.e-17" class="pilcrow">¶</a></p>
<div id="section-appendix.e-18">
<pre class="sourcecode">
  // The "pure" string solution uses a local
  // string variable for JSON serialization while
  // exposing another type to the application
  [JsonProperty("amount")]
  private string _amount;

  [JsonIgnore]
  public decimal Amount {
      get { return decimal.Parse(_amount); }
      set { _amount = value.ToString(); }
  }
</pre><a href="#section-appendix.e-18" class="pilcrow">¶</a>
</div>
<p id="section-appendix.e-19">
        In an application, "Amount" can be accessed as any other property
        while it is actually represented by a quoted string in JSON contexts.<a href="#section-appendix.e-19" class="pilcrow">¶</a></p>
<p id="section-appendix.e-20">
        Note: The example above also addresses the constraints on numeric data
        implied by I-JSON (the C# "decimal" data type has quite different
        characteristics compared to IEEE 754 double precision).<a href="#section-appendix.e-20" class="pilcrow">¶</a></p>
<div id="string.subtypes.arrays">
<section id="section-e.1">
        <h2 id="name-subtypes-in-arrays">
<a href="#section-e.1" class="section-number selfRef">E.1. </a><a href="#name-subtypes-in-arrays" class="section-name selfRef">Subtypes in Arrays</a>
        </h2>
<p id="section-e.1-1">
          Since the JSON array construct permits mixing arbitrary JSON data
   types,
          custom parsing and serialization code may be required
          to cope with subtypes anyway.<a href="#section-e.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="impl.guidelines">
<section id="section-appendix.f">
      <h2 id="name-implementation-guidelines">
<a href="#section-appendix.f" class="section-number selfRef">Appendix F. </a><a href="#name-implementation-guidelines" class="section-name selfRef">Implementation Guidelines</a>
      </h2>
<p id="section-appendix.f-1">
        The optimal solution is integrating support for JCS directly
        in JSON serializers (parsers need no changes).
        That is, canonicalization would just be an additional "mode"
        for a JSON serializer. However, this is currently not the case.
        Fortunately, JCS support can be introduced through externally supplied
        canonicalizer software acting as a post processor to existing
        JSON serializers. This arrangement also relieves the JCS implementer
 from
        having to deal with how underlying data is to be represented in JSON.<a href="#section-appendix.f-1" class="pilcrow">¶</a></p>
<p id="section-appendix.f-2">
        The post processor concept enables signature creation schemes like the
 following:<a href="#section-appendix.f-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-appendix.f-3">
        <li id="section-appendix.f-3.1">
            Create the data to be signed.<a href="#section-appendix.f-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-3.2">
            Serialize the data using existing JSON tools.<a href="#section-appendix.f-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-3.3">
            Let the external canonicalizer process the serialized data and
     return canonicalized result data.<a href="#section-appendix.f-3.3" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-3.4">
            Sign the canonicalized data.<a href="#section-appendix.f-3.4" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-3.5">
            Add the resulting signature value to the original JSON data
     through a designated signature property.<a href="#section-appendix.f-3.5" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-3.6">
            Serialize the completed (now signed) JSON object using existing
     JSON tools.<a href="#section-appendix.f-3.6" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-appendix.f-4">
        A compatible signature verification scheme would then be as follows:<a href="#section-appendix.f-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-appendix.f-5">
        <li id="section-appendix.f-5.1">
            Parse the signed JSON data using existing JSON tools.<a href="#section-appendix.f-5.1" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-5.2">
            Read and save the signature value from the designated signature
     property.<a href="#section-appendix.f-5.2" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-5.3">
            Remove the signature property from the parsed JSON object.<a href="#section-appendix.f-5.3" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-5.4">
            Serialize the remaining JSON data using existing JSON tools.<a href="#section-appendix.f-5.4" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-5.5">
            Let the external canonicalizer process the serialized data and
     return canonicalized result data.<a href="#section-appendix.f-5.5" class="pilcrow">¶</a>
</li>
        <li id="section-appendix.f-5.6">
            Verify that the canonicalized data matches the saved signature
     value
            using the algorithm and key used for creating the signature.<a href="#section-appendix.f-5.6" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-appendix.f-6">
        A canonicalizer like above is effectively only a "filter", potentially
 usable with
        a multitude of quite different cryptographic schemes.<a href="#section-appendix.f-6" class="pilcrow">¶</a></p>
<p id="section-appendix.f-7">
        Using a JSON serializer with integrated JCS support, the serialization
 performed
        before the canonicalization step could be eliminated for both
 processes.<a href="#section-appendix.f-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="open.source">
<section id="section-appendix.g">
      <h2 id="name-open-source-implementations">
<a href="#section-appendix.g" class="section-number selfRef">Appendix G. </a><a href="#name-open-source-implementations" class="section-name selfRef">Open-Source Implementations</a>
      </h2>
<p id="section-appendix.g-1">
        The following open-source implementations have been verified to be
        compatible with JCS:<a href="#section-appendix.g-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.g-2.1">
          JavaScript: <span>&lt;<a href="https://www.npmjs.com/package/canonicalize">https://www.npmjs.com/package/canonicalize</a>&gt;</span><a href="#section-appendix.g-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.g-2.2">
          Java: <span>&lt;<a href="https://github.com/erdtman/java-json-canonicalization">https://github.com/erdtman/java-json-canonicalization</a>&gt;</span><a href="#section-appendix.g-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.g-2.3">
          Go: <span>&lt;<a href="https://github.com/cyberphone/json-canonicalization/tree/master/go">https://github.com/cyberphone/json-canonicalization/tree/master/go</a>&gt;</span><a href="#section-appendix.g-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.g-2.4">
          .NET/C#: <span>&lt;<a href="https://github.com/cyberphone/json-canonicalization/tree/master/dotnet">https://github.com/cyberphone/json-canonicalization/tree/master/dotnet</a>&gt;</span><a href="#section-appendix.g-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.g-2.5">
          Python: <span>&lt;<a href="https://github.com/cyberphone/json-canonicalization/tree/master/python3">https://github.com/cyberphone/json-canonicalization/tree/master/python3</a>&gt;</span><a href="#section-appendix.g-2.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="json.otherefforts">
<section id="section-appendix.h">
      <h2 id="name-other-json-canonicalization">
<a href="#section-appendix.h" class="section-number selfRef">Appendix H. </a><a href="#name-other-json-canonicalization" class="section-name selfRef">Other JSON Canonicalization Efforts</a>
      </h2>
<p id="section-appendix.h-1">
        There are (and have been) other efforts creating "Canonical JSON". 
        Below is a list of URLs to some of them:<a href="#section-appendix.h-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.h-2.1">
          <span>&lt;<a href="https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00">https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00</a>&gt;</span><a href="#section-appendix.h-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.h-2.2">
          <span>&lt;<a href="https://gibson042.github.io/canonicaljson-spec/">https://gibson042.github.io/canonicaljson-spec/</a>&gt;</span><a href="#section-appendix.h-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-appendix.h-2.3">
          <span>&lt;<a href="http://wiki.laptop.org/go/Canonical_JSON">http://wiki.laptop.org/go/Canonical_JSON</a>&gt;</span><a href="#section-appendix.h-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.h-3">
        The listed efforts all build on text-level JSON-to-JSON
        transformations. The primary feature of text-level canonicalization is
        that it can be made neutral to the flavor of JSON used.  However, such
        schemes also imply major changes to the JSON parsing process, which is
        a likely hurdle for adoption. Albeit at the expense of certain JSON
        and application constraints, JCS was designed to be compatible with
        existing JSON tools.<a href="#section-appendix.h-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="json.development">
<section id="section-appendix.i">
      <h2 id="name-development-portal">
<a href="#section-appendix.i" class="section-number selfRef">Appendix I. </a><a href="#name-development-portal" class="section-name selfRef">Development Portal</a>
      </h2>
<p id="section-appendix.i-1">
        The JCS specification is currently developed at:
        <span>&lt;<a href="https://github.com/cyberphone/ietf-json-canon">https://github.com/cyberphone/ietf-json-canon</a>&gt;</span>.<a href="#section-appendix.i-1" class="pilcrow">¶</a></p>
<p id="section-appendix.i-2">
        JCS source code and extensive test data is available at:
        <span>&lt;<a href="https://github.com/cyberphone/json-canonicalization">https://github.com/cyberphone/json-canonicalization</a>&gt;</span>.<a href="#section-appendix.i-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Acknowledgements">
<section id="section-appendix.j">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.j-1">
        Building on ECMAScript number serialization was
        originally proposed by <span class="contact-name">James Manger</span>. This
 ultimately led to the
        adoption of the entire ECMAScript serialization scheme for JSON
 primitives.<a href="#section-appendix.j-1" class="pilcrow">¶</a></p>
<p id="section-appendix.j-2">
        Other people who have contributed with valuable input to this
 specification include
        <span class="contact-name">Scott Ananian</span>,
        <span class="contact-name">Tim Bray</span>,
        <span class="contact-name">Ben Campbell</span>,
        <span class="contact-name">Adrian Farell</span>,
        <span class="contact-name">Richard Gibson</span>,
        <span class="contact-name">Bron Gondwana</span>,
        <span class="contact-name">John-Mark Gurney</span>,
        <span class="contact-name">Mike Jones,</span>
        <span class="contact-name">John Levine</span>,
        <span class="contact-name">Mark Miller</span>,
        <span class="contact-name">Matthew Miller</span>,
        <span class="contact-name">Mark Nottingham</span>,
        <span class="contact-name">Mike Samuel</span>,
        <span class="contact-name">Jim Schaad</span>,
        <span class="contact-name">Robert Tupelo-Schneck</span>,
        and <span class="contact-name">Michal Wadas</span>.<a href="#section-appendix.j-2" class="pilcrow">¶</a></p>
<p id="section-appendix.j-3">
        For carrying out real-world concept verification, the software and
        support for number serialization provided by
        <span class="contact-name">Ulf Adams</span>,
        <span class="contact-name">Tanner Gooding</span>,
        and <span class="contact-name">Remy Oudompheng</span>
        was very helpful.<a href="#section-appendix.j-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.k">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Anders Rundgren</span></div>
<div dir="auto" class="left"><span class="org">Independent</span></div>
<div dir="auto" class="left"><span class="locality">Montpellier</span></div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:anders.rundgren.net@gmail.com" class="email">anders.rundgren.net@gmail.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.linkedin.com/in/andersrundgren/" class="url">https://www.linkedin.com/in/andersrundgren/</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Bret Jordan</span></div>
<div dir="auto" class="left"><span class="org">Broadcom</span></div>
<div dir="auto" class="left"><span class="street-address">1320 Ridder Park Drive</span></div>
<div dir="auto" class="left">
<span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95131</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:bret.jordan@broadcom.com" class="email">bret.jordan@broadcom.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Samuel Erdtman</span></div>
<div dir="auto" class="left"><span class="org">Spotify AB</span></div>
<div dir="auto" class="left"><span class="street-address">Birger Jarlsgatan 61, 4tr</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">113 56</span> <span class="locality">Stockholm</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:erdtman@spotify.com" class="email">erdtman@spotify.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>