<!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"> TOC </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"> </td></tr>
<tr><td class="header">Expires: February 25, 2011</td><td class="header"> </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., “Key words for use in RFCs to Indicate Requirement Levels,” March 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 78 and BCP 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 “work in progress.”</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>
Introduction<br />
<a href="#anchor2">2.</a>
Terminology<br />
<a href="#anchor3">3.</a>
Example<br />
<a href="#anchor4">3.1.</a>
JSON Token using HmacSha256<br />
<a href="#anchor5">3.1.1.</a>
Encoding<br />
<a href="#anchor6">3.1.2.</a>
Decoding<br />
<a href="#anchor7">3.2.</a>
JSON Token using ECDSA P256 SHA256<br />
<a href="#anchor8">3.2.1.</a>
Encoding<br />
<a href="#anchor9">3.2.2.</a>
Decoding<br />
<a href="#anchor10">4.</a>
Claims that can be made in a JSON Token<br />
<a href="#anchor11">4.1.</a>
Generating unique names and values<br />
<a href="#base64urllogic">5.</a>
base64url encoding as used by JSON Tokens<br />
<a href="#anchor12">6.</a>
General rules for creating and validating a JSON Token<br />
<a href="#anchor13">7.</a>
Protecting a JSON Token with HMAC SHA-256<br />
<a href="#anchor14">8.</a>
Protecting a JSON Token with RSA digital signatures<br />
<a href="#DefiningECDSA">9.</a>
Protecting a JSON Token with ECDSA<br />
<a href="#IANA">10.</a>
IANA Considerations<br />
<a href="#Security">11.</a>
Security Considerations<br />
<a href="#anchor15">11.1.</a>
Unicode comparison security issues<br />
<a href="#Acknowledgements">12.</a>
Acknowledgements<br />
<a href="#anchor16">13.</a>
Appendix - Non-Normative - Relationship of JSON Tokens to SAML Assertions<br />
<a href="#rfc.references1">14.</a>
References<br />
<a href="#rfc.references1">14.1.</a>
Normative References<br />
<a href="#rfc.references2">14.2.</a>
Informative References<br />
<a href="#rfc.authors">§</a>
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"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
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., “The application/json Media Type for JavaScript Object Notation (JSON),” July 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"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
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"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
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"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
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"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1.
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> Figure 1: Sample decoded JSON Claim Segment </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"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.
Decoding</h3>
<p>Decoding the JSON Claim Segment first requires removing the base64url encoding with no padding. Per <a class='info' href='#base64urllogic'>Section 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 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"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
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"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1.
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> Figure 2: Sample decoded JSON Claim Segment </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> ECDSA Example key values </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> R and S values as big endian byte arrays </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"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2.
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 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"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
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> Table 1: A list of claim definitions </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, “Uniform Resource Identifier (URI): Generic Syntax,” January 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, “Date and Time on the Internet: Timestamps,” July 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> Table 2: A list of syntax types used in claim definitions </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"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
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, “A Universally Unique IDentifier (UUID) URN Namespace,” July 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"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
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., “The Base16, Base32, and Base64 Data Encodings,” October 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> Table 3: Guidance on how to handle base64url encoded values without padding. </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"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
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., “UTF-8, a transformation format of ISO 10646,” November 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Ürst, “Unicode Normalization Forms,” 09 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"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
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, “HMAC: Keyed-Hashing for Message Authentication,” February 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, “Secure Hash Standard (SHS),” October 2008.</span><span>)</span></a> [FIPS.180‑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"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
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"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
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, “Digital Signature Standard (DSS),” June 2009.</span><span>)</span></a> [FIPS.186‑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"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
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, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 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 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, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 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"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
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"> TOC </a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.
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"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.
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"> TOC </a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.
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, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.</span><span>)</span></a> [OASIS.saml‑core‑2.0‑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., “Extensible Markup Language (XML) 1.1,” October 2002.</span><span>)</span></a> [W3C.CR‑xml11‑20021015] and <a class='info' href='#RFC3275'>XML
DSIG<span> (</span><span class='info'>Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 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., “The application/json Media Type for JavaScript Object Notation (JSON),” July 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"> TOC </a></td></tr></table>
<a name="rfc.section.14"></a><h3>14.
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"> TOC </a></td></tr></table>
<h3>14.1. 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, “Secure Hash Standard (SHS),” FIPS PUB 180-3, October 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, “Digital Signature Standard (DSS),” FIPS PUB 186-3, June 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>, “<a href="http://tools.ietf.org/html/rfc2104">HMAC: Keyed-Hashing for Message Authentication</a>,” RFC 2104, February 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>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 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>, “<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,” RFC 3339, July 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., “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>,” STD 63, RFC 3629, November 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>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,” STD 66, RFC 3986, January 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., “<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,” RFC 4627, July 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., “<a href="http://tools.ietf.org/html/rfc4648">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 4648, October 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, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>,” BCP 26, RFC 5226, May 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Ürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 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"> TOC </a></td></tr></table>
<h3>14.2. 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>, “<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>,” OASIS Standard saml-core-2.0-os, March 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, “<a href="http://tools.ietf.org/html/rfc3275">(Extensible Markup Language) XML-Signature Syntax and Processing</a>,” RFC 3275, March 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>, “<a href="http://tools.ietf.org/html/rfc4122">A Universally Unique IDentifier (UUID) URN Namespace</a>,” RFC 4122, July 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., “<a href="http://www.w3.org/TR/2002/CR-xml11-20021015">Extensible Markup Language (XML) 1.1</a>,” W3C CR CR-xml11-20021015, October 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"> TOC </a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Author Name</td></tr>
</table>
</body></html>