<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>JSON Tokens</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="JSON Tokens">
<meta name="keywords" content="RFC, Request for Comments, I-D, Internet-Draft, Assertion, Simple Web Tokens, SWT, JSON Tokens, JSON">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">A. Name</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">August 24, 2010</td></tr>
<tr><td class="header">Intended status: Experimental</td><td class="header">&nbsp;</td></tr>
<tr><td class="header">Expires: February 25, 2011</td><td class="header">&nbsp;</td></tr>
</table></td></tr></table>
<h1><br />JSON Tokens<br />draft-someone-json-tokens-format-00</h1>

<h3>Abstract</h3>

<p>JSON Tokens define an assertion format that can move claims between
      two parties. The claims in a JSON Token assertion are encoded as a JSON
      object which is then HMAC'd or digitally signed.
</p>
<h3>Requirements Language</h3>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a> [RFC2119].
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted  in full
conformance with the provisions of BCP&nbsp;78 and BCP&nbsp;79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF).  Note that other groups may also distribute
working documents as Internet-Drafts.  The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as &ldquo;work in progress.&rdquo;</p>
<p>
This Internet-Draft will expire on February 25, 2011.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Introduction<br />
<a href="#anchor2">2.</a>&nbsp;
Terminology<br />
<a href="#anchor3">3.</a>&nbsp;
Example<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor4">3.1.</a>&nbsp;
JSON Token using HmacSha256<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">3.1.1.</a>&nbsp;
Encoding<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">3.1.2.</a>&nbsp;
Decoding<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor7">3.2.</a>&nbsp;
JSON Token using ECDSA P256 SHA256<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor8">3.2.1.</a>&nbsp;
Encoding<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor9">3.2.2.</a>&nbsp;
Decoding<br />
<a href="#anchor10">4.</a>&nbsp;
Claims that can be made in a JSON Token<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor11">4.1.</a>&nbsp;
Generating unique names and values<br />
<a href="#base64urllogic">5.</a>&nbsp;
base64url encoding as used by JSON Tokens<br />
<a href="#anchor12">6.</a>&nbsp;
General rules for creating and validating a JSON Token<br />
<a href="#anchor13">7.</a>&nbsp;
Protecting a JSON Token with HMAC SHA-256<br />
<a href="#anchor14">8.</a>&nbsp;
Protecting a JSON Token with RSA digital signatures<br />
<a href="#DefiningECDSA">9.</a>&nbsp;
Protecting a JSON Token with ECDSA<br />
<a href="#IANA">10.</a>&nbsp;
IANA Considerations<br />
<a href="#Security">11.</a>&nbsp;
Security Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor15">11.1.</a>&nbsp;
Unicode comparison security issues<br />
<a href="#Acknowledgements">12.</a>&nbsp;
Acknowledgements<br />
<a href="#anchor16">13.</a>&nbsp;
Appendix - Non-Normative - Relationship of JSON Tokens to SAML Assertions<br />
<a href="#rfc.references1">14.</a>&nbsp;
References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references1">14.1.</a>&nbsp;
Normative References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references2">14.2.</a>&nbsp;
Informative References<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Author's Address<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Introduction</h3>

<p>JSON Tokens provide a simplified assertion format intended for space
      constrained environments such as HTTP Authorization headers and URI
      query parameters. JSON Tokens encode the assertion to be transmitted as
      a JSON object (as defined in <a class='info' href='#RFC4627'>RFC 4627<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627])
      which is then either HMAC'd or digitally signed.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p></p>
<blockquote class="text"><dl>
<dt>JSON Token Segment</dt>
<dd>One of the two parts that make up a
          JSON Token.
</dd>
<dt>JSON Crypto Segment</dt>
<dd>The first JSON Token Segment that
          contains cryptographic material such as a HMAC or signature that
          secures the token's contents.
</dd>
<dt>JSON Claim Segment</dt>
<dd>The second JSON Token Segment that
          contains a JSON object that encodes the claims being made by the
          JSON Token and has been base64url encoded.
</dd>
<dt>JSON Token</dt>
<dd>A string consisting of two JSON Token
          Segments, first the JSON Crypto Segment, then the JSON Claim
          Segment, separated by a period character.
</dd>
<dt>Decoded JSON Claim Segment</dt>
<dd>A JSON Claim Segment that
          has been base64url decoded back into a JSON object.
</dd>
<dt>Member</dt>
<dd>A JSON term referring to the contents of a JSON
          object.
</dd>
</dl></blockquote>

<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
Example</h3>

<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
JSON Token using HmacSha256</h3>

<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1.&nbsp;
Encoding</h3>

<p>The decoded JSON Claim Segment we will use in this example is:
</p><br /><hr class="insert" />
<a name="SampleDecoded"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"issuer":"joe",
 "algorithm":"HmacSha256",
 "not_after":"1282885245",
 "http://example.com/is_root":true}</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;1: Sample decoded JSON Claim Segment&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>Note that white space is explicitly allowed in JSON objects. The following is a byte array containing the UTF-8 characters that make up the decoded JSON Claims Segment: [123, 34, 105, 115, 115, 117, 101, 114, 34, 58, 34,
    106, 111, 101, 34, 44, 10, 32, 34, 97, 108, 103,
    111, 114, 105, 116, 104, 109, 34, 58, 34, 72, 109,
    97, 99, 83, 104, 97, 50, 53, 54, 34, 44, 10, 32,
    34, 110, 111, 116, 95, 97, 102, 116, 101, 114, 34, 58, 34, 49, 50, 56, 50, 56,
    56, 53, 50, 52, 53, 34, 44, 10, 32, 34, 104, 116,
    116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108,
    101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
    111, 116, 34, 58, 116, 114, 117, 101, 125]
</p>
<p>The previous is then base64url encoded and has its padding characters removed. This will then output the string: "eyJpc3N1ZXIiOiJqb2UiLAogImFsZ29yaXRobSI6IkhtYWNTaGEyNTYiLAogIm5vdF9hZnRlciI6IjEyODI4ODUyNDUiLAogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ". This string is the JSON Claim Segment.
</p>
<p>HMACs are generated using keys. In this case we will use the following key which is represented as a byte array: [233, 37, 57, 99, 72, 29, 196, 220, 90, 107, 230,
    190, 241, 145, 243, 12, 114, 154, 18, 94, 59, 56,
    134, 93, 208, 115, 232, 172, 88, 208, 24, 195, 174,
    197, 148, 96, 139, 206, 90, 247, 173, 198, 190, 162,
    10, 83, 84, 217, 206, 102, 154, 22, 189, 89, 39,
    157, 152, 195, 246, 249, 132, 162, 0, 233].
</p>
<p>Alternatively since it may be easier to process here is the same key as a base64url encoded value with padding removed: "6SU5Y0gdxNxaa-a-8ZHzDHKaEl47OIZd0HPorFjQGMOuxZRgi85a963GvqIKU1TZzmaaFr1ZJ52Yw_b5hKIA6Q".
</p>
<p>Now we can submit the JSON Claim Segment along with the key to a SHA 256 based HMAC which will output the following byte array: [126, 105, 182, 129, 27, 201, 165, 147, 91, 237, 24,
    229, 76, 57, 52, 238, 192, 34, 93, 229, 97, 159, 1,
    0, 48, 51, 185, 154, 163, 227, 134, 225].
</p>
<p>This byte array is then base64url encoded with padding removed producing the string: "fmm2gRvJpZNb7RjlTDk07sAiXeVhnwEAMDO5mqPjhuE". This string is the JSON Crypto Segment.
</p>
<p>Therefore the JSON Token would be: "fmm2gRvJpZNb7RjlTDk07sAiXeVhnwEAMDO5mqPjhuE.eyJpc3N1ZXIiOiJqb2UiLAogImFsZ29yaXRobSI6IkhtYWNTaGEyNTYiLAogIm5vdF9hZnRlciI6IjEyODI4ODUyNDUiLAogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ".
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.&nbsp;
Decoding</h3>

<p>Decoding the JSON Claim Segment first requires removing the base64url encoding with no padding. Per <a class='info' href='#base64urllogic'>Section&nbsp;5<span> (</span><span class='info'>base64url encoding as used by JSON Tokens</span><span>)</span></a> we need to calculate the length of the JSON Claim Segment string which is 142 characters and divided that number by 4 and get the remainder which is 2. Per <a class='info' href='#PaddingHandling'>Table&nbsp;3<span> (</span><span class='info'>Guidance on how to handle base64url encoded values without padding.</span><span>)</span></a> we now know we need to add two padding bytes. With that data we can base64url decode the JSON Claim Segment string and turn it into the previously provided UTF-8 byte array which we can then translate into the Decoded JSON Claim Segment string. At that point we can validate that the resulting string is completely legal JSON and validate the various claims and algorithm.
</p>
<p>Now we just repeat the previous process of using the expected key and the JSON Claim Segment as input to a SHA 256 HMAC function and then taking the output, base64url encoding it without padding and seeing if it is character for character equal to JSON Crypto Segment in the JSON Token.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
JSON Token using ECDSA P256 SHA256</h3>

<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1.&nbsp;
Encoding</h3>

<p>The decoded JSON Claim Segment we will use in this example is:
</p><br /><hr class="insert" />
<a name="SampleDecodedEcdsa"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"issuer":"joe",
 "algorithm":"EcdsaP256Sha256",
 "not_after":"1282885245",
 "http://example.com/is_root":true}</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Figure&nbsp;2: Sample decoded JSON Claim Segment&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>The only difference with the previous decoded JSON Claim Segment is the algorithm. However the rest of the process of generating the JSON Claim Segment is the same. The final base64url without padding output is "eyJpc3N1ZXIiOiJqb2UiLAogImFsZ29yaXRobSI6IkhtYWNTaGEyNTYiLAogIm5vdF9hZnRlciI6IjEyODI4ODUyNDUiLAogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ".
</p>
<p>The values of the ECDSA key used in this example, presented as base64url encoded values without padding of big endian byte arrays encoding unsigned integers are:
</p><br /><hr class="insert" />
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Parameter Name</th><th align="left">Value</th></tr>
<tr>
<td align="left">x</td>
<td align="left">2Ji-dBdV45ArzmsWIdsLK1M9O82-0TBq_9ZYFzak61c</td>
</tr>
<tr>
<td align="left">y</td>
<td align="left">oCr2bFccTTCLHRgH5O4l1lqJjglzgFnDnHoa9RzKH7M</td>
</tr>
<tr>
<td align="left">d</td>
<td align="left">gYIjx7pkcGJyOrrfymKe-ZaI7npTu4YgBUVoFSe8Wjo</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;ECDSA Example key values&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>The ECDSA key (the public part, x and y, plus the private part d) are then passed to a ECDSA signing function which also takes the curve type, P256, the hash type, SHA 256 and the JSON Claim Segment as inputs. It will output two unsigned integers R and S. In this example the R and S values, given as byte arrays in big endian order are:
</p><br /><hr class="insert" />
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Parameter Name</th><th align="left">Value</th></tr>
<tr>
<td align="left">R</td>
<td align="left">[43, 76, 226, 57, 205, 197, 126, 77, 42, 202, 246,
    55, 78, 209, 253, 165, 169, 117, 3, 186, 219, 125,
    63, 215, 93, 209, 127, 117, 238, 225, 26, 249]</td>
</tr>
<tr>
<td align="left">S</td>
<td align="left">[233, 32, 128, 9, 9, 192, 60, 181, 58, 244, 73, 46,
    105, 190, 200, 202, 208, 129, 155, 173, 249, 139,
    216, 109, 245, 81, 232, 119, 202, 57, 4, 138]</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;R and S values as big endian byte arrays&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>We then concatenate the S array to the end of the R array and base64url encode the result without padding producing the JSON Crypto Segment string "K0ziOc3Ffk0qyvY3TtH9pal1A7rbfT_XXdF_de7hGvnpIIAJCcA8tTr0SS5pvsjK0IGbrfmL2G31Ueh3yjkEig".
</p>
<p>The JSON Token would therefore be the string "K0ziOc3Ffk0qyvY3TtH9pal1A7rbfT_XXdF_de7hGvnpIIAJCcA8tTr0SS5pvsjK0IGbrfmL2G31Ueh3yjkEig.eyJpc3N1ZXIiOiJqb2UiLAogImFsZ29yaXRobSI6IkhtYWNTaGEyNTYiLAogIm5vdF9hZnRlciI6IjEyODI4ODUyNDUiLAogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ".
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2.&nbsp;
Decoding</h3>

<p>Decoding the JSON Token from this example requires processing the JSON Claim Segment exactly as handled in the previous example. Validating the JSON Crypto Segment is a little difference. We must base64url decode the JSON Crypto Segment as in the previous example but we then need to split the 64 member byte array that must result into two 32 byte arrays, the first R and the second S. We then have to pass x, y, R, S and the JSON Claim Segment to an ECDSA signature verifier that has been configured to use the P256 curve with the SHA 256 hash function. As explained in <a class='info' href='#DefiningECDSA'>Section&nbsp;9<span> (</span><span class='info'>Protecting a JSON Token with ECDSA</span><span>)</span></a> the use of the k value in ECDSA means that we cannot validate the correctness of the signature in the same way we validated the correctness of the HMAC> We have to depend on an ECDSA validator to validate the signature for us.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Claims that can be made in a JSON Token</h3>

<p>The members of the JSON object contain the claims made by the JSON
      Token. The following lists some pre-defined claims. Note however what
      claims a JSON Token must contain to be considered valid depends on the
      context in which the JSON Token is used and is outside the scope of this
      specification. None of the claims defined in the table below are
      intended to be mandatory but rather as a starting point for a catalog of
      useful claims.
</p><br /><hr class="insert" />
<a name="ClaimTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left"><col align="left"><col align="left">
<tr><th align="left">Claim Name</th><th align="left">JSON Value Type</th><th align="left">Claim Syntax</th><th align="left">Claim Semantics</th></tr>
<tr>
<td align="left">issuer</td>
<td align="left">string</td>
<td align="left">StringAndURI</td>
<td align="left">Identifies the principal who issued the JSON Token.</td>
</tr>
<tr>
<td align="left">algorithm</td>
<td align="left">string</td>
<td align="left">StringAndURI</td>
<td align="left">Identifies the cryptographic algorithm being used to secure the
        JSON Token.</td>
</tr>
<tr>
<td align="left">not_after</td>
<td align="left">integer</td>
<td align="left">IntDate</td>
<td align="left">Identifies the time on or after which the token MUST NOT be
        accepted for processing.</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 1: A list of claim definitions&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>The claim syntaxes referred to above are defined below:
</p><br /><hr class="insert" />
<a name="ClaimSyntaxDefinition"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Claim Syntax Name</th><th align="left">Claim Syntax Definition</th></tr>
<tr>
<td align="left">StringAndURI</td>
<td align="left">Any string value MAY be used but a value containing a ":" character
        MUST be a URI as defined in <a class='info' href='#RFC3986'>RFC
        3986<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a> [RFC3986].</td>
</tr>
<tr>
<td align="left">IntDate</td>
<td align="left">The number of seconds from 1970-01-01T0:0:0Z as measured in UTC
        until the desired date/time. See <a class='info' href='#RFC3339'>RFC
        3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, &ldquo;Date and Time on the Internet: Timestamps,&rdquo; July&nbsp;2002.</span><span>)</span></a> [RFC3339] for details regarding date/times in general and UTC in
        particular.</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 2: A list of syntax types used in claim definitions&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p></p>
<ol class="text">
<li>The processing of the issuer claim is generally application
          specific.
</li>
<li>The processing of the algorithm claim requires that, if present,
          the value of the algorithm claim MUST be one that is both supported
          and for which there exists a key associated with the issuer of the
          JSON Token. Note however that if the issuer claim is not included
          then the manner in which the issuer is determined is application
          specific.
</li>
<li>The processing of the not_after claim requires that the current
          date/time MUST be before the date/time listed in the not_after claim
          if present. Implementers MAY provide for some small leeway, usually
          no more than a few minutes, to account for clock skew.
</li>
</ol><p>EDITOR'S NOTE: Edit the previous text in so it's more
      natural.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.&nbsp;
Generating unique names and values</h3>

<p>Both claim names as well as algorithm values can be defined at will
        by those using JSON Tokens. However, in order to prevent collisions,
        any new claim name or algorithm value MUST either be defined in an RFC
        published via the IETF or MUST be defined as a URI that contains a
        collision resistant namespace. Examples of collision resistant
        namespaces include: </p>
<ul class="text">
<li>Domain Names,
</li>
<li>Object Identifiers (OIDs) as defined in the ITU-T X 660 and X
            670 Recommendation series or
</li>
<li>Universally Unique IDentifier (UUID) as defined in <a class='info' href='#RFC4122'>RFC 4122<span> (</span><span class='info'>Leach, P., Mealling, M., and R. Salz, &ldquo;A Universally Unique IDentifier (UUID) URN Namespace,&rdquo; July&nbsp;2005.</span><span>)</span></a> [RFC4122].
</li>
</ul><p> In each case the definer of the name or value MUST take
        reasonable precautions to make sure they are in control of the part of
        the namespace they use to define the name or value.
</p>
<a name="base64urllogic"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
base64url encoding as used by JSON Tokens</h3>

<p>JSON Tokens make use of the base64url encoding as defined in <a class='info' href='#RFC4648'>RFC 4648<span> (</span><span class='info'>Josefsson, S., &ldquo;The Base16, Base32, and Base64 Data Encodings,&rdquo; October&nbsp;2006.</span><span>)</span></a> [RFC4648]. However as allowed by section 3.2 of
      RFC 4648 this specification mandates that base64url encoding when used
      with JSON Tokens MUST NOT use padding. The reason for this restriction
      is that the padding character is not URL safe.
</p>
<p>To process a base64url value in a JSON Token one must first calculate
      the size of the base64url value and then divide that size by four using
      modular arithmetic. Look up the remainder of the modular division in the
      table below.
</p><br /><hr class="insert" />
<a name="PaddingHandling"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Remainder</th><th align="left">Action to take</th></tr>
<tr>
<td align="left">0</td>
<td align="left">No padding is needed.</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">The base64url encoded value is malformed and MUST be rejected for
        processing.</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">Two padding characters are needed.</td>
</tr>
<tr>
<td align="left">3</td>
<td align="left">One padding character is needed.</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 3: Guidance on how to handle base64url encoded values without padding.&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
General rules for creating and validating a JSON Token</h3>

<p>To create a JSON Token one MUST follow these steps: </p>
<ol class="text">
<li>Create a JSON object containing the desired claims.
</li>
<li>Translate the JSON object's Unicode code points into UTF-8 as
          defined in <a class='info' href='#RFC3629'>RFC 3629<span> (</span><span class='info'>Yergeau, F., &ldquo;UTF-8, a transformation format of ISO 10646,&rdquo; November&nbsp;2003.</span><span>)</span></a> [RFC3629].
</li>
<li>base64url encode the JSON object as defined in this
          specification. This creates the JSON Claim Segment.
</li>
<li>Create the JSON Crypto segment as defined for the particular
          algorithm being used.
</li>
<li>Combine the JSON Crypto segment and then the JSON Token segment,
          separated by a period character to create a JSON Token.
</li>
</ol>

<p>When validating a JSON Token the following steps MUST be taken. If
      any of the listed steps fails then the token MUST be rejected for
      processing.
</p>
<p></p>
<ol class="text">
<li>The JSON Token MUST contain exactly one period character.
</li>
<li>The JSON Token MUST be split on the period character resulting in
          two non-empty segments.
</li>
<li>The JSON Claim Segment (the second of the two) MUST be
          successfully base64url decoded following the restriction given in
          this spec that no padding characters may have been used.
</li>
<li>The Decoded JSON Claim Segment MUST be completely valid JSON
          syntax.
</li>
<li>The JSON Claim Segment MUST be validated to only include claims
          whose syntax and semantics are both understood and supported.
</li>
<li>The JSON Crypto Segment MUST be successfully validated against
          the JSON Claim Segment in the manner defined for the type of
          algorithm being used.
</li>
</ol>

<p>Processing a JSON Token inevitably requires comparing known strings
      to values in the token. For example, in checking what the algorithm is
      (assuming the algorithm claim is used) the Unicode string encoding
      'algorithm' will be checked against the member names in the Decoded JSON
      Claim Segment to see if there is a matching claim name. A similar
      process occurs when determining if the value of the algorithm claim
      represents a supported algorithm. Comparing Unicode strings however has
      signfigant security implications which are further explored in the
      security considerations section.
</p>
<p>Comparisons between JSON strings and other Unicode strings MUST be
      performed as specified below:
</p>
<p></p>
<ol class="text">
<li>Remove any JSON applied escaping to produce an array of Unicode
          code points
</li>
<li><a class='info' href='#USA15'>Unicode Normalization<span> (</span><span class='info'>Davis, M., Whistler, K., and M. D&Uuml;rst, &ldquo;Unicode Normalization Forms,&rdquo; 09&nbsp;2009.</span><span>)</span></a> [USA15] MUST NOT be
          applied at any point to either the JSON string or to the string it
          is to be compared against.
</li>
<li>Comparisons between the two strings MUST be performed as a
          Unicode code point to code point comparison.
</li>
</ol>

<p>
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Protecting a JSON Token with HMAC SHA-256</h3>

<p>Hash based Message Authentication Codes (HMACs) enable one to use a
      secret plus a cryptographic hash function to generate a Message
      Authentication Code (MAC) that can be used to demonstrate not only that
      the MAC matches the hashed content, in this case the JSON Claim Segment,
      but can only demonstrate that whom ever generated the MAC was in
      possession of the secret. Unlike digital signatures, HMACs can only
      provide validation but not repudiation since both the sender and
      receiver of the HMAC must be in possession of the secret and so either
      could have generated the HMAC.
</p>
<p>The algorithm for implementing and validating HMACs is provided in
      <a class='info' href='#RFC2104'>RFC 2104<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, &ldquo;HMAC: Keyed-Hashing for Message Authentication,&rdquo; February&nbsp;1997.</span><span>)</span></a> [RFC2104]. Although any HMAC can be used
      with JSON Tokens this section defines the use of the SHA-256
      cryptographic hash function as defined in <a class='info' href='#FIPS.180-3'>FIPS
      180-3<span> (</span><span class='info'>National Institute of Standards and             Technology, &ldquo;Secure Hash Standard (SHS),&rdquo; October&nbsp;2008.</span><span>)</span></a> [FIPS.180&#8209;3]. The reserved algorithm claim value HmacSha256 is used in
      the JSON Claim Segment to indicate that the JSON Crypto Segment contains
      a HMAC SHA-256 HMAC.
</p>
<p>The HMAC SHA-256 MAC is generated as follows: </p>
<ol class="text">
<li>Take the JSON Claim Segment and execute the HMAC SHA-256
          algorithm on it using the desired key to produce a HMAC.
</li>
<li>base64url encode the HMAC as defined in this document.
</li>
</ol><p> The output of the previous then becomes the JSON Crypto
      Segment for that JSON Token.
</p>
<p>The HMAC SHA-256 MAC on a JSON token is validated for a particular
      key as defined below. </p>
<ol class="text">
<li>Take the JSON Claim Segment and calculate a HMAC SHA-256 MAC on
          it using the key to be tested.
</li>
<li>base64url encode the previously generated HMAC as defined in this
          document.
</li>
<li>If the JSON Crypto Segment and the previously calculated value
          exactly match in a character by character, case sensitive
          comparison, then one has confirmation that the key being tested was
          used to generate the HMAC on the JSON Token and that the contents of
          the JSON Claim Segment have not be tampered with.
</li>
</ol>

<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Protecting a JSON Token with RSA digital signatures</h3>

<p>TBD. I have some homework to do before I will feel comfortable that I
      can properly specify this behavior.
</p>
<a name="DefiningECDSA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
Protecting a JSON Token with ECDSA</h3>

<p>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined by
      <a class='info' href='#FIPS.186-3'>FIPS 186-3<span> (</span><span class='info'>National Institute of Standards and             Technology, &ldquo;Digital Signature Standard (DSS),&rdquo; June&nbsp;2009.</span><span>)</span></a> [FIPS.186&#8209;3]. ECDSA provides for the use
      of Elliptic Curve cryptography which is able to provide equivalent
      security to RSA cryptography but using shorter key lengths and with
      greater processing speed. This means that ECDSA signatures will be
      substantially smaller in terms of length than equivalently strong RSA
      Digital Signatures.
</p>
<p>This specification defines the use of ECDSA with the P-256 curve and
      the SHA-256 cryptographic hash function. The P-256 curve is also defined
      in FIPS 186-3. The algorithm claim value EcdsaP256Sha256 is reversed to
      identify a JSON Token signed with ECDSA P-256 SHA-256.
</p>
<p>A JSON Token is signed with an ECDSA P-256 SHA-256 signature as
      follows: </p>
<ol class="text">
<li>Take the JSON Claim Segment and generate a digital signature for
          it using ECDSA P-256 SHA-256 with the desired private key. The
          output will be two unsigned integers called, by convention R and
          S.
</li>
<li>Turn R and S into byte arrays in big endian order. Each array
          will be 32 bytes long
</li>
<li>Concatenate the two byte arrays in the order R and then S.
</li>
<li>base64url the 64 byte array as defined in this specification.
</li>
</ol><p> The output is then the JSON Crypto Segment for the JSON
      Token.
</p>
<p>A JSON Token is tested to see if it was signed with ECDSA P-256
      SHA-256 using a given public key as follows: </p>
<ol class="text">
<li>Take the JSON Crypto Segment and base64url decode it. If decoding
          fails then the test MUST fail.
</li>
<li>The output of the base64url decoding MUST be a 64 byte array.
</li>
<li>Split the 64 byte array into two 32 byte arrays. The first array
          will be R and the second S. Please remember that the byte arrays are
          in big endian byte order, please check with the ECDSA validator in
          use to see what byte order it required.
</li>
<li>Submit the JSON Claim Segment, R, S and the public key that is
          being tested to the ECDSA P-256 SHA-256 validator.
</li>
</ol><p> The ECDSA validator will then specify if the digital signature
      is valid given the inputs. Please note that ECDSA digital signature
      contain a value referred to as K which is a random number generated for
      each digital signature instance. This means that two ECDSA digital
      signatures using exactly the same input parameters will still output
      different signatures because their K values will be different. The
      consequence of K is that one validates a ECDSA signature by submitting
      the previously specified inputs to a ECDSA validator. One cannot, as
      with HMACs, check the signature directly oneself.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.&nbsp;
IANA Considerations</h3>

<p>This specification calls for: </p>
<ul class="text">
<li>A new IANA registry entitled "JSON Token Claims" for claim names
          used in a decoded JSON Claim Segment. Inclusion in the registry is
          RFC Required in the <a class='info' href='#RFC5226'>RFC 5226<span> (</span><span class='info'>Narten, T. and H. Alvestrand, &ldquo;Guidelines for Writing an IANA Considerations Section in RFCs,&rdquo; May&nbsp;2008.</span><span>)</span></a> [RFC5226] sense.
          The registry will just record the claim name and a pointer to the
          RFC that defines it. This specification defines inclusion of the
          claim names defined in <a class='info' href='#ClaimTable'>Table&nbsp;1<span> (</span><span class='info'>A list of claim definitions</span><span>)</span></a>.
</li>
<li>A new IANA registry entitled "JSON Token Algorithm Values" for
          values used with the algorithm claim used in a decoded JSON Claim
          Segment. Inclusion in the registry is RFC Required in the <a class='info' href='#RFC5226'>RFC 5226<span> (</span><span class='info'>Narten, T. and H. Alvestrand, &ldquo;Guidelines for Writing an IANA Considerations Section in RFCs,&rdquo; May&nbsp;2008.</span><span>)</span></a> [RFC5226] sense. The registry will just
          record the algorithm value and a pointer to the RFC that defines it.
          This specification defines inclusion of the algorithm values
          HmaxSha256 and EcdsaP256Sha256.
</li>
</ul>

<p>EDITOR'S NOTE: Need to include an identifier for RSA. Also I
      explicitly didn't allow for ad-hoc registrations because I figure that
      IANA has enough to do but it would be useful to have a central registry
      of values, even ad-hoc ones. We should check with IANA to see what they
      think.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.&nbsp;
Security Considerations</h3>

<p>EDITOR'S NOTE: Lots of work to do here. I need to remember to look
      into any issues relating to security and JSON parsing. One wonders just
      how secure most JSON parsing libraries are. Were they ever hardened for
      security scenarios? If not, what kind of holes does that open up? Also
      need to walk through the JSON standard and see what kind of issues we
      have especially around comparison of names, already found an issue with
      escaping strings (needed to define that comparisons of strings must
      occur after they are unescaped). Need to also put in text about:
      Importance of keeping secrets secret. Rotating keys. Strengths and
      weaknesses of the different algorithms. Case sensitivity and more
      generally Unicode comparison issues that can cause security holes,
      especially in claim names and explain why Unicode Normalization is such
      a problem for assertions.
</p>
<p>Need to put in text about why strict JSON validation is necessary.
      Basically that if malformed JSON is received then the intent of the
      sender is impossible to reliably discerne. While in non-security
      contexts it's o.k. to be generous in what one accepts in security
      contexts this can lead to serious security holes. For example, malformed
      JSON might indicate that someone has managed to find a security hole in
      the issuer's code and is leveraging it to get the issuer to issue 'bad'
      tokens whose content the attack can control.
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.&nbsp;
Unicode comparison security issues</h3>

<p>
</p>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.&nbsp;
Acknowledgements</h3>

<p>
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.&nbsp;
Appendix - Non-Normative - Relationship of JSON Tokens to SAML Assertions</h3>

<p><a class='info' href='#OASIS.saml-core-2.0-os'>SAML 2.0<span> (</span><span class='info'>Cantor, S., Kemp, J., Philpott, R., and E. Maler, &ldquo;Assertions and Protocol for the OASIS Security Assertion Markup Language             (SAML) V2.0,&rdquo; March&nbsp;2005.</span><span>)</span></a> [OASIS.saml&#8209;core&#8209;2.0&#8209;os] provides a
      standard for creating assertions with much greater expressivity and
      security options than supported by JSON Tokens. However the cost of this
      flexibility and expressiveness is size. In addition SAML's use of <a class='info' href='#W3C.CR-xml11-20021015'>XML<span> (</span><span class='info'>Cowan, J., &ldquo;Extensible Markup Language (XML) 1.1,&rdquo; October&nbsp;2002.</span><span>)</span></a> [W3C.CR&#8209;xml11&#8209;20021015] and <a class='info' href='#RFC3275'>XML
      DSIG<span> (</span><span class='info'>Eastlake, D., Reagle, J., and D. Solo, &ldquo;(Extensible Markup Language) XML-Signature Syntax and Processing,&rdquo; March&nbsp;2002.</span><span>)</span></a> [RFC3275] only contributes to the size of SAML assertions.
</p>
<p>JSON Tokens are intended to provide a simplified assertion format
      that is small enough to fit into HTTP headers and query arguments in
      URIs. It does this by supporting a much simpler assertion model than
      SAML and using the <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627] object encoding
      syntax. It also supports securing assertions using Hash-based Message
      Authentication Codes (HMACs) and digital signatures using a smaller (and
      less flexible) format than XML DSIG.
</p>
<p>Therefore while JSON Tokens can do some of the things SAML assertions
      do, JSON Tokens are not intended as a full replacement for SAML. But
      rather a compromise assertion format to be used when space is at a
      premium.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.14"></a><h3>14.&nbsp;
References</h3>

<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>14.1.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FIPS.180-3">[FIPS.180-3]</a></td>
<td class="author-text">National Institute of Standards and
            Technology, &ldquo;Secure Hash Standard (SHS),&rdquo; FIPS&nbsp;PUB 180-3, October&nbsp;2008.</td></tr>
<tr><td class="author-text" valign="top"><a name="FIPS.186-3">[FIPS.186-3]</a></td>
<td class="author-text">National Institute of Standards and
            Technology, &ldquo;Digital Signature Standard (DSS),&rdquo; FIPS&nbsp;PUB 186-3, June&nbsp;2009.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2104">[RFC2104]</a></td>
<td class="author-text"><a href="mailto:hugo@watson.ibm.com">Krawczyk, H.</a>, <a href="mailto:mihir@cs.ucsd.edu">Bellare, M.</a>, and <a href="mailto:canetti@watson.ibm.com">R. Canetti</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2104">HMAC: Keyed-Hashing for Message Authentication</a>,&rdquo; RFC&nbsp;2104, February&nbsp;1997 (<a href="http://www.rfc-editor.org/rfc/rfc2104.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a href="mailto:chris.newman@sun.com">C. Newman</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,&rdquo; RFC&nbsp;3339, July&nbsp;2002 (<a href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
<td class="author-text">Yergeau, F., &ldquo;<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>,&rdquo; STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003 (<a href="http://www.rfc-editor.org/rfc/rfc3629.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,&rdquo; STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005 (<a href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
<td class="author-text">Crockford, D., &ldquo;<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,&rdquo; RFC&nbsp;4627, July&nbsp;2006 (<a href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4648">[RFC4648]</a></td>
<td class="author-text">Josefsson, S., &ldquo;<a href="http://tools.ietf.org/html/rfc4648">The Base16, Base32, and Base64 Data Encodings</a>,&rdquo; RFC&nbsp;4648, October&nbsp;2006 (<a href="http://www.rfc-editor.org/rfc/rfc4648.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5226">[RFC5226]</a></td>
<td class="author-text">Narten, T. and H. Alvestrand, &ldquo;<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>,&rdquo; BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008 (<a href="http://www.rfc-editor.org/rfc/rfc5226.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="USA15">[USA15]</a></td>
<td class="author-text"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler, K.</a>, and M. D&Uuml;rst, &ldquo;Unicode Normalization Forms,&rdquo; Unicode Standard Annex&nbsp;15, 09&nbsp;2009.</td></tr>
</table>

<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>14.2.&nbsp;Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OASIS.saml-core-2.0-os">[OASIS.saml-core-2.0-os]</a></td>
<td class="author-text"><a href="mailto:cantor.2@osu.edu">Cantor, S.</a>, <a href="mailto:John.Kemp@nokia.com">Kemp, J.</a>, <a href="mailto:rphilpott@rsasecurity.com">Philpott, R.</a>, and <a href="mailto:eve.maler@sun.com">E. Maler</a>, &ldquo;<a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">Assertions and Protocol for the OASIS Security Assertion Markup Language
            (SAML) V2.0</a>,&rdquo; OASIS Standard&nbsp;saml-core-2.0-os, March&nbsp;2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3275">[RFC3275]</a></td>
<td class="author-text">Eastlake, D., Reagle, J., and D. Solo, &ldquo;<a href="http://tools.ietf.org/html/rfc3275">(Extensible Markup Language) XML-Signature Syntax and Processing</a>,&rdquo; RFC&nbsp;3275, March&nbsp;2002 (<a href="http://www.rfc-editor.org/rfc/rfc3275.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4122">[RFC4122]</a></td>
<td class="author-text"><a href="mailto:paulle@microsoft.com">Leach, P.</a>, <a href="mailto:michael@refactored-networks.com">Mealling, M.</a>, and <a href="mailto:rsalz@datapower.com">R. Salz</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc4122">A Universally Unique IDentifier (UUID) URN Namespace</a>,&rdquo; RFC&nbsp;4122, July&nbsp;2005 (<a href="http://www.rfc-editor.org/rfc/rfc4122.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc4122.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc4122.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.CR-xml11-20021015">[W3C.CR-xml11-20021015]</a></td>
<td class="author-text">Cowan, J., &ldquo;<a href="http://www.w3.org/TR/2002/CR-xml11-20021015">Extensible Markup Language (XML) 1.1</a>,&rdquo; W3C CR&nbsp;CR-xml11-20021015, October&nbsp;2002.</td></tr>
</table>

<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Author Name</td></tr>
</table>
</body></html>