diff options
Diffstat (limited to 'doc/specs/draft-jones-json-web-token.htm')
| -rw-r--r-- | doc/specs/draft-jones-json-web-token.htm | 1597 |
1 files changed, 1597 insertions, 0 deletions
diff --git a/doc/specs/draft-jones-json-web-token.htm b/doc/specs/draft-jones-json-web-token.htm new file mode 100644 index 0000000..ee9a73b --- /dev/null +++ b/doc/specs/draft-jones-json-web-token.htm @@ -0,0 +1,1597 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html lang="en"><head><title>JSON Web Token (JWT)</title> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<meta name="description" content="JSON Web Token (JWT)"> +<meta name="keywords" content="RFC, Request for Comments, I-D, Internet-Draft, Assertion, Claim, Simple Web Token, Security Token, SWT, JavaScript Object Notation, JSON, JSON Web Token, JWT, JSON Web Signature, JWS, JSON Web Encryption, JWE"> +<meta name="generator" content="xml2rfc v1.36 (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">M. Jones</td></tr> +<tr><td class="header">Internet-Draft</td><td class="header">Microsoft</td></tr> +<tr><td class="header">Intended status: Standards Track</td><td class="header">D. Balfanz</td></tr> +<tr><td class="header">Expires: June 15, 2012</td><td class="header">Google</td></tr> +<tr><td class="header"> </td><td class="header">J. Bradley</td></tr> +<tr><td class="header"> </td><td class="header">independent</td></tr> +<tr><td class="header"> </td><td class="header">Y. Goland</td></tr> +<tr><td class="header"> </td><td class="header">Microsoft</td></tr> +<tr><td class="header"> </td><td class="header">J. Panzer</td></tr> +<tr><td class="header"> </td><td class="header">Google</td></tr> +<tr><td class="header"> </td><td class="header">N. Sakimura</td></tr> +<tr><td class="header"> </td><td class="header">Nomura Research Institute</td></tr> +<tr><td class="header"> </td><td class="header">P. Tarjan</td></tr> +<tr><td class="header"> </td><td class="header">Facebook</td></tr> +<tr><td class="header"> </td><td class="header">December 13, 2011</td></tr> +</table></td></tr></table> +<h1><br />JSON Web Token (JWT)<br />draft-jones-json-web-token-07</h1> + +<h3>Abstract</h3> + +<p> + JSON Web Token (JWT) is a means of representing claims to be + transferred between two parties. The claims in a JWT are + encoded as a JSON object that is digitally signed using JSON + Web Signature (JWS) and/or encrypted using JSON Web Encryption + (JWE). + +</p> +<p> + The suggested pronunciation of JWT is the same as the English + word "jot". + +</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 June 15, 2012.</p> + +<h3>Copyright Notice</h3> +<p> +Copyright (c) 2011 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> +JSON Web Token (JWT) Overview<br /> + <a href="#ExampleJWT">3.1.</a> +Example JWT<br /> +<a href="#anchor4">4.</a> +JWT Claims<br /> + <a href="#ReservedClaimName">4.1.</a> +Reserved Claim Names<br /> + <a href="#PublicClaimName">4.2.</a> +Public Claim Names<br /> + <a href="#PrivateClaimName">4.3.</a> +Private Claim Names<br /> +<a href="#anchor5">5.</a> +JWT Header<br /> +<a href="#Plaintext">6.</a> +Plaintext JWTs<br /> + <a href="#ExamplePlaintextJWT">6.1.</a> +Example Plaintext JWT<br /> +<a href="#anchor6">7.</a> +Rules for Creating and Validating a JWT<br /> +<a href="#Algorithms">8.</a> +Cryptographic Algorithms<br /> +<a href="#IANA">9.</a> +IANA Considerations<br /> +<a href="#Security">10.</a> +Security Considerations<br /> + <a href="#anchor7">10.1.</a> +Unicode Comparison Security Issues<br /> +<a href="#TBD">11.</a> +Open Issues and Things To Be Done (TBD)<br /> +<a href="#rfc.references1">12.</a> +References<br /> + <a href="#rfc.references1">12.1.</a> +Normative References<br /> + <a href="#rfc.references2">12.2.</a> +Informative References<br /> +<a href="#anchor10">Appendix A.</a> +Relationship of JWTs to SAML Tokens<br /> +<a href="#anchor11">Appendix B.</a> +Relationship of JWTs to Simple Web Tokens (SWTs)<br /> +<a href="#Acknowledgements">Appendix C.</a> +Acknowledgements<br /> +<a href="#anchor12">Appendix D.</a> +Document History<br /> +<a href="#rfc.authors">§</a> +Authors' Addresses<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 Web Token (JWT) is a compact token format intended for + space constrained environments such as HTTP Authorization + headers and URI query parameters. JWTs encode claims 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]) that is base64url encoded + and digitally signed and/or encrypted. Signing is + accomplished using JSON Web Signature (JWS) <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a>. Encryption is accomplished using JSON Web Encryption + (JWE) <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a>. + +</p> +<p> + The suggested pronunciation of JWT is the same as the English + word "jot". + +</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 Web Token (JWT)</dt> +<dd> + A string consisting of three parts: the Encoded JWT Header, the + JWT Second Part, and the JWT Third Part, in that order, + with the parts being separated by period ('.') characters, + and each part containing base64url encoded content. + +</dd> +<dt>JWT Header</dt> +<dd> + A string representing a JSON object that + describes the cryptographic operations applied to the JWT. + When the JWT is signed, the JWT Header is the JWS Header. + When the JWT is encrypted, the JWT Header is the JWE Header. + +</dd> +<dt>Header Parameter Names</dt> +<dd> + The names of the members within the JWT Header. + +</dd> +<dt>Header Parameter Values</dt> +<dd> + The values of the members within the JWT Header. + +</dd> +<dt>JWT Second Part</dt> +<dd> + When the JWT is signed, the JWT Second Part is the Encoded JWS Payload. + When the JWT is encrypted, the JWT Second Part is the Encoded JWE Encrypted Key. + +</dd> +<dt>JWT Third Part</dt> +<dd> + When the JWT is signed, the JWT Third Part is the Encoded JWS Signature. + When the JWT is encrypted, the JWT Third Part is the Encoded JWE Ciphertext. + +</dd> +<dt>JWT Claims Set</dt> +<dd> + A string representing a JSON object that + contains the claims conveyed by the JWT. + When the JWT is signed, the bytes of the UTF-8 representation of the + JWT Claims Set are base64url encoded to create the Encoded JWS Payload. + When the JWT is encrypted, the bytes of the UTF-8 representation of the + JWT Claims Set are used as the JWE Plaintext. + +</dd> +<dt>Claim Names</dt> +<dd> + The names of the members of the JSON object represented by + the JWT Claims Set. + +</dd> +<dt>Claim Values</dt> +<dd> + The values of the members of the JSON object represented by + the JWT Claims Set. + +</dd> +<dt>Encoded JWT Header</dt> +<dd> + Base64url encoding of the bytes of the + UTF-8 <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] + representation of the JWT Header. + +</dd> +<dt>Base64url Encoding</dt> +<dd> + For the purposes of this specification, this term always + refers to the URL- and filename-safe Base64 encoding + described 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], + Section 5, with the (non URL-safe) '=' padding characters + omitted, as permitted by Section 3.2. (See Appendix C of + <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> for notes on implementing base64url + encoding without padding.) + +</dd> +</dl></blockquote><p> + +</p> +<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. +JSON Web Token (JWT) Overview</h3> + +<p> + JWTs represent a set of claims as a JSON object that is + base64url encoded and digitally signed and/or + encrypted. The JWT Claims Set represents this JSON object. + As per <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] + Section 2.2, the JSON object consists of zero or more + name/value pairs (or members), where the names are strings and + the values are arbitrary JSON values. These members are the + claims represented by the JWT. + +</p> +<p> + The member names within the JWT Claims Set are + referred to as Claim Names. The + corresponding values are referred to as Claim Values. + +</p> +<p> + The bytes of the UTF-8 representation of the JWT Claims Set + are signed in the manner described in JSON Web Signature (JWS) + <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> and/or encrypted in the manner described + in JSON Web Encryption (JWE) <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a>. + +</p> +<p> + The contents of the JWT Header describe the cryptographic + operations applied to the JWT Claims Set. + If the JWT Header is a JWS Header, the claims are signed. + If the JWT Header is a JWE Header, the claims are encrypted. + +</p> +<p> + A JWT is represented as the concatenation of the Encoded JWT Header, + the JWT Second Part, and the JWT Third Part, in that order, + with the parts being separated by period ('.') characters. + When signed, the three parts of the JWT are the three parts of + a JWS used to represent the JWT. When encrypted, the three + parts of the JWT are the three parts of a JWE used to + represent the JWT. + +</p> +<a name="ExampleJWT"></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. +Example JWT</h3> + +<p> + The following example JWT Header declares that the + encoded object is a JSON Web Token (JWT) and the JWT is + signed using the HMAC SHA-256 algorithm: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"typ":"JWT", + "alg":"HS256"}</pre></div> +<p> + Base64url encoding the bytes of the UTF-8 representation of + the JWT Header yields this Encoded JWS Header value, + which is used as the Encoded JWT Header: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9</pre></div> +<p> + The following is an example of a JWT Claims Set: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"iss":"joe", + "exp":1300819380, + "http://example.com/is_root":true}</pre></div> +<p> + Base64url encoding the bytes of the UTF-8 representation of + the JSON Claims Set yields this Encoded JWS Payload, + which is used as the JWT Second Part + (with line breaks for display purposes only): + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly +9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ</pre></div> +<p> + Signing the Encoded JWS Header and Encoded JWS Payload with + the HMAC SHA-256 algorithm and base64url encoding the + signature in the manner specified in <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a>, + yields this Encoded JWS Signature, which is used as the JWT + Third Part: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk</pre></div> +<p> + Concatenating these parts in the order + Header.Second.Third with period characters between the + parts yields this complete JWT (with line breaks for + display purposes only): + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 +. +eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt +cGxlLmNvbS9pc19yb290Ijp0cnVlfQ +. +dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk</pre></div> +<p> + This computation is illustrated in more detail in <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a>, Appendix A.1. + +</p> +<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.4"></a><h3>4. +JWT Claims</h3> + +<p> + The JWT Claims Set represents a JSON object whose members + are the claims conveyed by the JWT. + The Claim Names within this object MUST be unique. + Note however, that the set of claims that a + JWT must contain to be considered valid is context-dependent + and is outside the scope of this specification. When used in + a security-related context, implementations MUST understand + and support all of the claims present; otherwise, the JWT MUST + be rejected for processing. + +</p> +<p> + There are three classes of JWT Claim Names: Reserved Claim + Names, Public Claim Names, and Private Claim Names. + +</p> +<a name="ReservedClaimName"></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. +Reserved Claim Names</h3> + +<p> + The following claim names are reserved. None of the claims + defined in the table below are intended to be mandatory, but + rather, provide a starting point for a set of useful, + interoperable claims. All the names are short because a + core goal of JWTs is for the tokens to be compact. + +</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">exp</td> +<td align="left">number</td> +<td align="left">IntDate</td> +<td align="left"> + The <tt>exp</tt> (expiration time) + claim identifies the expiration time on or after which the + token MUST NOT be accepted for processing. The processing + of the <tt>exp</tt> claim requires that + the current date/time MUST be before the expiration + date/time listed in the <tt>exp</tt> + claim. Implementers MAY provide for some small leeway, + usually no more than a few minutes, to account for clock + skew. This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">nbf</td> +<td align="left">number</td> +<td align="left">IntDate</td> +<td align="left"> + The <tt>nbf</tt> (not before) claim + identifies the time before which the token MUST NOT be + accepted for processing. The processing of the <tt>nbf</tt> claim requires that the current + date/time MUST be after or equal to the not-before + date/time listed in the <tt>nbf</tt> + claim. Implementers MAY provide for some small leeway, + usually no more than a few minutes, to account for clock + skew. This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">iat</td> +<td align="left">number</td> +<td align="left">IntDate</td> +<td align="left"> + The <tt>iat</tt> (issued at) claim + identifies the time at which the JWT was issued. This + claim can be used to determine the age of the token. + This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">iss</td> +<td align="left">string</td> +<td align="left">StringOrURI</td> +<td align="left"> + The <tt>iss</tt> (issuer) claim + identifies the principal that issued the JWT. The + processing of this claim is generally application + specific. + The <tt>iss</tt> value is case sensitive. + This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">aud</td> +<td align="left">string</td> +<td align="left">StringOrURI</td> +<td align="left"> + The <tt>aud</tt> (audience) claim + identifies the audience that the JWT is intended for. The + principal intended to process the JWT MUST be identified + with the value of the audience claim. If the principal + processing the claim does not identify itself with the + identifier in the <tt>aud</tt> claim + value then the JWT MUST be rejected. The interpretation + of the audience value is generally + application specific. + The <tt>aud</tt> value is case sensitive. + This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">prn</td> +<td align="left">string</td> +<td align="left">StringOrURI</td> +<td align="left"> + The <tt>prn</tt> (principal) claim + identifies the subject of the JWT. The processing of this + claim is generally application specific. + The <tt>prn</tt> value is case sensitive. + This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">jti</td> +<td align="left">string</td> +<td align="left">String</td> +<td align="left"> + The <tt>jti</tt> (JWT ID) claim + provides a unique identifier for the JWT. The identifier + value MUST be assigned in a manner that ensures that there + is a negligible probability that the same value will be + accidentally assigned to a different data object. The + <tt>jti</tt> claim can be used to + prevent the JWT from being replayed. + The <tt>jti</tt> value is case sensitive. + This claim is OPTIONAL. + </td> +</tr> +<tr> +<td align="left">typ</td> +<td align="left">string</td> +<td align="left">String</td> +<td align="left"> + The <tt>typ</tt> (type) claim is used + to declare a type for the contents of this JWT Claims Set. + The <tt>typ</tt> value is case sensitive. + This claim is OPTIONAL. + </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: Reserved Claim Definitions </b></font><br /></td></tr></table><hr class="insert" /> + +<p> + Additional reserved claim names MAY be defined via the IANA + JSON Web Token Claims registry, as per <a class='info' href='#IANA'>Section 9<span> (</span><span class='info'>IANA Considerations</span><span>)</span></a>. The syntax values used above are defined as follows: + +</p><br /><hr class="insert" /> +<a name="SyntaxDefinitions"></a> +<table class="full" align="center" border="0" cellpadding="2" cellspacing="2"> +<col align="left"><col align="left"> +<tr><th align="left">Syntax Name</th><th align="left">Syntax Definition</th></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> +<tr> +<td align="left">String</td> +<td align="left"> + Any string value MAY be used. + </td> +</tr> +<tr> +<td align="left">StringOrURI</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> +</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: Claim Syntax Definitions </b></font><br /></td></tr></table><hr class="insert" /> + +<a name="PublicClaimName"></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.2"></a><h3>4.2. +Public Claim Names</h3> + +<p> + Claim names can be defined at will by those using + JWTs. However, in order to prevent collisions, any new claim + name SHOULD either be defined in the IANA JSON Web Token + Claims registry or 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 needs to take + reasonable precautions to make sure they are in control of + the part of the namespace they use to define the claim + name. +</p> +<a name="PrivateClaimName"></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.3"></a><h3>4.3. +Private Claim Names</h3> + +<p> + A producer and consumer of a JWT may agree to any claim + name that is not a Reserved Name <a class='info' href='#ReservedClaimName'>Section 4.1<span> (</span><span class='info'>Reserved Claim Names</span><span>)</span></a> or a Public Name <a class='info' href='#PublicClaimName'>Section 4.2<span> (</span><span class='info'>Public Claim Names</span><span>)</span></a>. Unlike Public Names, + these private names are subject to collision and should be + used with caution. + +</p> +<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.5"></a><h3>5. +JWT Header</h3> + +<p> + The members of the JSON object represented by the JWT Header + describe the cryptographic operations applied to the JWT and + optionally, additional properties of the JWT. + The member names within the JWT Header are + referred to as Header Parameter Names. These names MUST be + unique. The corresponding values are referred to as Header + Parameter Values. + +</p> +<p> + Implementations MUST understand the entire contents of the + header; otherwise, the JWT MUST be rejected for processing. + +</p> +<p> + There are two ways of distinguishing whether the JWT is a JWS + or JWE. The first is by examining the <tt>alg</tt> (algorithm) header value. If the + value represents a signature algorithm, the JWT is a JWS; if + it represents an encryption algorithm, the JWT is a JWE. A + second method is determining whether an <tt>enc</tt> (encryption method) member exists. + If the <tt>enc</tt> member exists, the JWT + is a JWE; otherwise, the JWT is a JWS. Both methods will + yield the same result. + +</p> +<p> + JWS Header Parameters are defined by <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a>. + JWE Header Parameters are defined by <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a>. + This specification further specifies the use of the following + header parameters in both the cases where the JWT is a JWS and + where it is a JWE. + +</p><br /><hr class="insert" /> +<a name="HeaderParameterTable"></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">Header Parameter Name</th><th align="left">JSON Value Type</th><th align="left">Header Parameter Syntax</th><th align="left">Header Parameter Semantics</th></tr> +<tr> +<td align="left">typ</td> +<td align="left">string</td> +<td align="left">String</td> +<td align="left"> + The <tt>typ</tt> (type) header parameter + is used to declare structural information about the JWT. + In the normal case where nested signing or encryption + operations are not employed, the use of this header + parameter is OPTIONAL, and if present, it is RECOMMENDED that + its value be either "JWT" or + "http://openid.net/specs/jwt/1.0". + In the case that nested signing or encryption steps are + employed, the use of this header parameter is REQUIRED; in + this case, the value MUST either be "JWS", to indicate that + a nested signed JWT is carried in this JWT or "JWE", to + indicate that a nested encrypted JWT is carried in this JWT. + </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: Reserved Header Parameter Usage </b></font><br /></td></tr></table><hr class="insert" /> + +<a name="Plaintext"></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. +Plaintext JWTs</h3> + +<p> + To support use cases where the JWT content is secured by a + means other than a signature and/or encryption contained + within the token (such as a signature on a data structure + containing the token), JWTs MAY also be created without a + signature or encryption. Plaintext JWTs MUST use the <tt>alg</tt> value <tt>none</tt>, and are formatted identically to a + signed JWT with an empty signature. This means that the + base64url encoding of the bytes representing the UTF-8 + encoding of the JWT Claims Set is the JWT Second Part, and + the empty string is the JWT Third Part. + +</p> +<a name="ExamplePlaintextJWT"></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.1"></a><h3>6.1. +Example Plaintext JWT</h3> + +<p> + The following example JWT Header declares that the + encoded object is a Plaintext JWT: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"alg":"none"}</pre></div> +<p> + Base64url encoding the bytes of the UTF-8 representation of + the JWT Header yields this Encoded JWT Header: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJhbGciOiJub25lIn0</pre></div> +<p> + The following is an example of a JWT Claims Set: + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"iss":"joe", + "exp":1300819380, + "http://example.com/is_root":true}</pre></div> +<p> + Base64url encoding the bytes of the UTF-8 representation of + the JSON Claims Set yields this Encoded JWS Payload, + which is used as the JWT Second Part + (with line breaks for display purposes only): + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt +cGxlLmNvbS9pc19yb290Ijp0cnVlfQ</pre></div> +<p> + The JWT Third Part is the empty string. + +</p> +<p> + Concatenating these parts in the order + Header.Second.Third with period characters between the + parts yields this complete JWT (with line breaks for + display purposes only): + +</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJhbGciOiJub25lIn0 +. +eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt +cGxlLmNvbS9pc19yb290Ijp0cnVlfQ +. +</pre></div> +<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.7"></a><h3>7. +Rules for Creating and Validating a JWT</h3> + +<p> + To create a JWT, one MUST perform these steps: + + </p> +<ol class="text"> +<li> + Create a JWT Claims Set containing the desired claims. + Note that white space is explicitly allowed in the + representation and no canonicalization is performed before + encoding. + +</li> +<li> + Let the Message be the bytes of the UTF-8 representation + of the JWT Claims Set. + +</li> +<li> + Create a JWT Header containing the desired set of header + parameters. If the JWT is to be signed or encrypted, they + MUST conform to either the <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> or <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a> specifications, respectively. Else, if + the JWT is to be plaintext, the <tt>alg</tt> value <tt>none</tt> MUST be used. Note that white + space is explicitly allowed in the representation and no + canonicalization is performed before encoding. + +</li> +<li> + Base64url encode the bytes of the UTF-8 representation of + the JWT Header. Let this be the Encoded JWT Header. + +</li> +<li> + Depending upon whether the JWT is to be signed, encrypted, + or plaintext, there are three cases: + +<ul class="text"> +<li> + If the JWT is to be signed, create a JWS using the JWT + Header as the JWS Header and the Message as the JWS + Payload; all steps specified in <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> + for creating a JWS MUST be followed. + Let the JWT Second Part be the Encoded JWS Payload and + let the JWT Third Part be the Encoded JWS Signature. + +</li> +<li> + If the JWT is to be encrypted, create a JWE using the + JWT Header as the JWE Header and the Message as the + JWE Plaintext; all steps specified in <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a> for creating a JWE MUST be followed. + Let the JWT Second Part be the Encoded JWE Encrypted + Key and let the JWT Third Part be the Encoded JWS + Ciphertext. + +</li> +<li> + Else, if the JWT is to be plaintext, let the JWT + Second Part be the base64url encoding of the Message + and let the JWT Third Part be the empty string. + +</li> +</ul> + +</li> +<li> + Concatenate the Encoded JWT Header, the JWT Second Part, + and the JWT Third Part in that order, separating each by + period ('.') characters. + +</li> +<li> + If a nested signing or encryption operation will be + performed, let the Message be this concatenation, and + return to Step 3, using a <tt>typ</tt> + value of either "JWS" or "JWE" respectively in the + new JWT Header created in that step. + +</li> +<li> + Otherwise, let the resulting JWT be this concatenation. + +</li> +</ol><p> + +</p> +<p> + When validating a JWT 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 JWT MUST contain exactly two period characters. + +</li> +<li> + The JWT MUST be split on the two period characters + resulting in three strings. The first string is the + Encoded JWT Header; the second is the JWT Second Part; the + third is the JWT Third Part. + +</li> +<li> + The Encoded JWT Header MUST be successfully base64url + decoded following the restriction given in this + specification that no padding characters have been used. + +</li> +<li> + The JWT Header MUST be completely valid JSON syntax + conforming to <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]. + +</li> +<li> + The JWT Header MUST be validated to only include + parameters and values whose syntax and semantics are both + understood and supported. + +</li> +<li> + Determine whether the JWT is signed, encrypted, or + plaintext by examining the <tt>alg</tt> + (algorithm) header value and optionally, the <tt>enc</tt> (encryption method) header value, + if present. + +</li> +<li> + Depending upon whether the JWT signed, encrypted, + or plaintext, there are three cases: + +<ul class="text"> +<li> + If the JWT is signed, all steps specified in <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> for validating a JWS MUST be followed. + Let the Message be the result of base64url decoding + the JWS Payload. + +</li> +<li> + If the JWT is encrypted, all steps specified in <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a> for validating a JWE MUST be followed. + Let the Message be the JWE Plaintext. + +</li> +<li> + Else, if the JWT is plaintext, let the Message be the + result of base64url decoding the JWE Second Part. The + Third Part MUST be verified to be the empty string. + +</li> +</ul> + +</li> +<li> + If the JWT Header contains a <tt>typ</tt> value of either "JWS" or "JWE", + then the Message contains a JWT that was the subject of + nested signing or encryption operations, respectively. In + this case, return to Step 1, using the Message as the JWT. + +</li> +<li> + Otherwise, let the JWT Claims Set be the Message. + +</li> +<li> + The JWT Claims Set MUST be completely valid + JSON syntax conforming to <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]. + +</li> +<li> + When used in a security-related context, the + JWT Claims Set MUST be validated to only include claims + whose syntax and semantics are both understood and + supported. + +</li> +</ol><p> + +</p> +<p> + Processing a JWT inevitably requires comparing known strings + to values in the token. For example, in checking what the + algorithm is, the Unicode string encoding <tt>alg</tt> will be + checked against the member names in the JWT Header + to see if there is a matching header parameter + name. A similar process occurs when determining if the value + of the <tt>alg</tt> header parameter represents a supported + algorithm. + +</p> +<p> + Comparisons between JSON strings and other Unicode strings + MUST be performed as specified below: + + </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 equality comparison. + +</li> +</ol><p> + +</p> +<a name="Algorithms"></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. +Cryptographic Algorithms</h3> + +<p> + JWTs use JSON Web Signature (JWS) <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> and + JSON Web Encryption (JWE) <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a> to sign and/or + encrypt the contents of the JWT. + +</p> +<p> + Of the JWS signing algorithms, only HMAC SHA-256 MUST be + implemented by conforming JWT implementations. It is + RECOMMENDED that implementations also support the RSA SHA-256 + and ECDSA P-256 SHA-256 algorithms. Support for other + algorithms and key sizes is OPTIONAL. + +</p> +<p> + If an implementation provides encryption capabilities, + of the JWE encryption algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, + AES-128-CBC, and AES-256-CBC MUST be implemented by conforming + implementations. It is RECOMMENDED that implementations also + support ECDH-ES with 256 bit keys, AES-128-GCM, and + AES-256-GCM. Support for other algorithms and key sizes is + OPTIONAL. + +</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.9"></a><h3>9. +IANA Considerations</h3> + +<p> + This specification calls for: + + </p> +<ul class="text"> +<li> + A new IANA registry entitled "JSON Web Token Claims" for + reserved claim names is defined in <a class='info' href='#ReservedClaimName'>Section 4.1<span> (</span><span class='info'>Reserved Claim Names</span><span>)</span></a>. 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 for reserved JWT claim names that are + intended to be interoperable between implementations. The + registry will just record the reserved 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'>Reserved Claim Definitions</span><span>)</span></a>. + +</li> +</ul><p> + +</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.10"></a><h3>10. +Security Considerations</h3> + +<p> + TBD: Lots of work to do here. We 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, we need to walk through the + JSON standard and see what kind of issues we have especially + around comparison of names. For instance, comparisons of + claim names and other parameters 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. + +</p> +<p> + TBD: 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 discern. + One example of malformed JSON that MUST be rejected is + an object in which the same member name occurs multiple times. + 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 attacker can + control. + +</p> +<p> + TBD: Write about the need to secure the token content if a + signature is not contained in the JWT itself. + +</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.10.1"></a><h3>10.1. +Unicode Comparison Security Issues</h3> + +<p> + Claim names in JWTs are Unicode strings. For security + reasons, the representations of these names must be compared + verbatim after performing any escape processing (as per + <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], Section 2.5). + +</p> +<p> + This means, for instance, that these JSON strings must + compare as being equal ("JWT", "\u004aWT"), whereas these + must all compare as being not equal to the first set or to + each other ("jwt", "Jwt", "JW\u0074"). + +</p> +<p> + JSON strings MAY contain characters outside the Unicode + Basic Multilingual Plane. For instance, the G clef + character (U+1D11E) may be represented in a JSON string as + "\uD834\uDD1E". Ideally, JWT implementations SHOULD ensure + that characters outside the Basic Multilingual Plane are + preserved and compared correctly; alternatively, if this is + not possible due to these characters exercising limitations + present in the underlying JSON implementation, then input + containing them MUST be rejected. + +</p> +<a name="TBD"></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. +Open Issues and Things To Be Done (TBD)</h3> + +<p> + The following items remain to be done in this draft: + + </p> +<ul class="text"> +<li> + Provide an example of an encrypted JWT. + +</li> +<li> + Clarify the optional ability to provide type information + for JWTs and/or their parts. Specifically, clarify + whether we need to specify the <tt>typ</tt> + Claim Name in addition to the Header Parameter, + whether it conveys syntax or semantics, and indeed, + whether this is the right approach. Also clarify the + relationship between these type values and <a class='info' href='#RFC2045'>MIME<span> (</span><span class='info'>Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.</span><span>)</span></a> [RFC2045] types (if any). + +</li> +<li> + Think about how to best describe the concept currently + described as "the bytes of the UTF-8 representation of". + Possible terms to use instead of "bytes of" include "byte + sequence", "octet series", and "octet sequence". Also + consider whether we want to add an overall clarifying + statement somewhere in each spec something like "every + place we say 'the UTF-8 representation of X', we mean 'the + bytes of the UTF-8 representation of X'". That would + potentially allow us to omit the "the bytes of" part + everywhere else. + +</li> +<li> + Consider whether a media type should be proposed, such as + "application/jwt". + +</li> +<li> + Finish the Security Considerations section. + +</li> +<li> + Possibly write a companion specification that contains the former + JWT JSON Serialization. + +</li> +</ul><p> + +</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.12"></a><h3>12. +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>12.1. Normative References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td> +<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:balfanz@google.com">Balfanz, D.</a>, <a href="mailto:ve7jtb@ve7jtb.com">Bradley, J.</a>, <a href="mailto:yarong@microsoft.com">Goland, Y.</a>, <a href="mailto:jpanzer@google.com">Panzer, J.</a>, <a href="mailto:n-sakimura@nri.co.jp">Sakimura, N.</a>, and <a href="mailto:pt@fb.com">P. Tarjan</a>, “<a href="http://tools.ietf.org/html/draft-jones-json-web-signature">JSON Web Signature (JWS)</a>,” December 2011.</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2045">[RFC2045]</a></td> +<td class="author-text"><a href="mailto:ned@innosoft.com">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>,” RFC 2045, November 1996 (<a href="http://www.rfc-editor.org/rfc/rfc2045.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>12.2. Informative References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="CanvasApp">[CanvasApp]</a></td> +<td class="author-text">Facebook, “<a href="http://developers.facebook.com/docs/authentication/canvas">Canvas Applications</a>,” 2010.</td></tr> +<tr><td class="author-text" valign="top"><a name="JSS">[JSS]</a></td> +<td class="author-text">Bradley, J. and N. Sakimura (editor), “<a href="http://jsonenc.info/jss/1.0/">JSON Simple Sign</a>,” September 2010.</td></tr> +<tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td> +<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:ekr@rtfm.com">Rescorla, E.</a>, and <a href="mailto:jhildebr@cisco.com">J. Hildebrand</a>, “<a href="http://tools.ietf.org/html/draft-jones-json-web-encryption">JSON Web Encryption (JWE)</a>,” December 2011.</td></tr> +<tr><td class="author-text" valign="top"><a name="MagicSignatures">[MagicSignatures]</a></td> +<td class="author-text">Panzer (editor), J., Laurie, B., and D. Balfanz, “<a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-experimental-00.html">Magic Signatures</a>,” August 2010.</td></tr> +<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="SWT">[SWT]</a></td> +<td class="author-text">Hardt, D. and Y. Goland, “<a href="http://oauth-wrap-wg.googlegroups.com/web/SWT-v0.9.5.1.pdf?gda=Sn4MsEMAAABFB7PFAFiVedPtjcqT8uuIImHXUksNUKMXLyrSumAs_dF2tzlQ33RhT1wW8BFYO1QytiJ-HdGYYcPi_09pl8N7FWLveOaWjzbYnpnkpmxcWg">Simple Web Token (SWT)</a>,” Version 0.9.5.1, November 2009.</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="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.A"></a><h3>Appendix A. +Relationship of JWTs to SAML Tokens</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 tokens with much greater expressivity + and more security options than supported by JWTs. However, the + cost of this flexibility and expressiveness is both size and + complexity. 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 tokens. + +</p> +<p> + JWTs are intended to provide a simple token format that is + small enough to fit into HTTP headers and query arguments in + URIs. It does this by supporting a much simpler token 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 tokens using + Hash-based Message Authentication Codes (HMACs) and digital + signatures using a smaller (and less flexible) format than XML + DSIG. + +</p> +<p> + Therefore, while JWTs can do some of the things SAML tokens + do, JWTs are not intended as a full replacement for SAML + tokens, but rather as a compromise token format to be used + when space is at a premium. + +</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.B"></a><h3>Appendix B. +Relationship of JWTs to Simple Web Tokens (SWTs)</h3> + +<p> + Both JWTs and Simple Web Tokens <a class='info' href='#SWT'>SWT<span> (</span><span class='info'>Hardt, D. and Y. Goland, “Simple Web Token (SWT),” November 2009.</span><span>)</span></a> [SWT], + at their core, enable sets of claims to be communicated + between applications. For SWTs, both the claim names and + claim values are strings. For JWTs, while claim names are + strings, claim values can be any JSON type. Both token types + offer cryptographic protection of their content: SWTs with + HMAC SHA-256 and JWTs with a choice of algorithms, including + HMAC SHA-256, RSA SHA-256, and ECDSA P-256 SHA-256. + +</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.C"></a><h3>Appendix C. +Acknowledgements</h3> + +<p> + The authors acknowledge that the design of JWTs was + intentionally influenced by the design and simplicity of <a class='info' href='#SWT'>Simple Web Tokens<span> (</span><span class='info'>Hardt, D. and Y. Goland, “Simple Web Token (SWT),” November 2009.</span><span>)</span></a> [SWT] and ideas for JSON + tokens that Dick Hardt discussed within the OpenID community. + +</p> +<p> + Solutions for signing JSON content were previously explored by + <a class='info' href='#MagicSignatures'>Magic Signatures<span> (</span><span class='info'>Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” August 2010.</span><span>)</span></a> [MagicSignatures], <a class='info' href='#JSS'>JSON Simple Sign<span> (</span><span class='info'>Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010.</span><span>)</span></a> [JSS], and <a class='info' href='#CanvasApp'>Canvas Applications<span> (</span><span class='info'>Facebook, “Canvas Applications,” 2010.</span><span>)</span></a> [CanvasApp], all of which + influenced this draft. + +</p> +<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.D"></a><h3>Appendix D. +Document History</h3> + +<p> + -07 + </p> +<ul class="text"> +<li> + Defined the <tt>prn</tt> (principal) + claim to identify the subject of the JWT. + +</li> +<li> + Defined the <tt>jti</tt> (JWT ID) + claim to enable replay protection. + +</li> +<li> + Use the term "JWT Claims Set" rather than "JWT Claims Object" + since this is actually a string representing a JSON object + and not the JSON object itself. + +</li> +<li> + Moved "MUST" requirements from the Overview to later in + the spec. + +</li> +<li> + Respect line length restrictions in examples. + +</li> +<li> + Applied other editorial improvements. + +</li> +</ul><p> + +</p> +<p> + -06 + </p> +<ul class="text"> +<li> + Reference and use content from <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signature (JWS),” December 2011.</span><span>)</span></a> and + <a class='info' href='#JWE'>[JWE]<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2011.</span><span>)</span></a>, rather than repeating it here. + +</li> +<li> + Simplified terminology to better match JWE, where the + terms "JWT Header" and "Encoded JWT Header" are now used, + for instance, rather than the previous terms "Decoded JWT + Header Segment" and "JWT Header Segment". Also changed to + "Plaintext JWT" from "Unsigned JWT". + +</li> +<li> + Describe how to perform nested encryption and signing + operations. + +</li> +<li> + Changed "integer" to "number", since that is the correct + JSON type. + +</li> +<li> + Changed StringAndURI to StringOrURI. + +</li> +</ul><p> + +</p> +<p> + -05 + </p> +<ul class="text"> +<li> + Added the <tt>nbf</tt> (not before) + claim and clarified the meaning of the <tt>iat</tt> (issued at) claim. + +</li> +</ul><p> + +</p> +<p> + -04 + </p> +<ul class="text"> +<li> + Correct typo found by John Bradley: "the JWT Claim Segment + is the empty string" -> "the JWT Crypto Segment is the + empty string". + +</li> +</ul><p> + +</p> +<p> + -03 + </p> +<ul class="text"> +<li> + Added "http://openid.net/specs/jwt/1.0" as a token type + identifier URI for JWTs. + +</li> +<li> + Added <tt>iat</tt> (issued at) claim. + +</li> +<li> + Changed RSA SHA-256 from MUST be supported to RECOMMENDED + that it be supported. Rationale: Several people have + objected to the requirement for implementing RSA SHA-256, + some because they will only be using HMACs and symmetric + keys, and others because they only want to use ECDSA when + using asymmetric keys, either for security or key length + reasons, or both. + +</li> +<li> + Defined <tt>alg</tt> value <tt>none</tt> to represent unsigned JWTs. + +</li> +</ul><p> + +</p> +<p> + -02 + </p> +<ul class="text"> +<li> + Split signature specification out into separate + draft-jones-json-web-signature-00. This split introduced + no semantic changes. + +</li> +<li> + The JWT Compact Serialization is now the only token + serialization format specified in this draft. The JWT + JSON Serialization can continue to be defined in a + companion specification. + +</li> +</ul><p> + +</p> +<p> + -01 + </p> +<ul class="text"> +<li> + Draft incorporating consensus decisions reached at IIW. + +</li> +</ul><p> + +</p> +<p> + -00 + </p> +<ul class="text"> +<li> + Public draft published before November 2010 IIW based upon + the JSON token convergence proposal incorporating input + from several implementers of related specifications. + +</li> +</ul><p> + +</p> +<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>Authors' Addresses</h3> +<table width="99%" border="0" cellpadding="0" cellspacing="0"> +<tr><td class="author-text"> </td> +<td class="author-text">Michael B. Jones</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Microsoft</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr> +<tr><td class="author" align="right">URI: </td> +<td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Dirk Balfanz</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Google</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:balfanz@google.com">balfanz@google.com</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">John Bradley</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">independent</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Yaron Y. Goland</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Microsoft</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:yarong@microsoft.com">yarong@microsoft.com</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">John Panzer</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Google</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:jpanzer@google.com">jpanzer@google.com</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Nat Sakimura</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Nomura Research Institute</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Paul Tarjan</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Facebook</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:pt@fb.com">pt@fb.com</a></td></tr> +</table> +</body></html> |