<!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 Key (JWK)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="JSON Web Key (JWK)">
<meta name="keywords" content="RFC, Request for Comments, I-D, Internet-Draft, JavaScript Object Notation, JSON, JSON Web Token, JWT, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK, JSON Web Algorithms, JWA">
<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">JOSE 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">October 14, 2012</td></tr>
<tr><td class="header">Expires: April 17, 2013</td><td class="header"> </td></tr>
</table></td></tr></table>
<h1><br />JSON Web Key (JWK)<br />draft-ietf-jose-json-web-key-06</h1>
<h3>Abstract</h3>
<p>
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON)
data structure that represents a public key.
This specification also defines a JSON Web Key Set (JWK Set)
JSON data structure for representing a set of JWKs.
Cryptographic algorithms and identifiers for use with this
specification are described in the separate
JSON Web Algorithms (JWA) specification.
</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 April 17, 2013.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 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">1.1.</a>
Notational Conventions<br />
<a href="#anchor3">2.</a>
Terminology<br />
<a href="#ExampleJWKSet">3.</a>
Example JSON Web Key Set<br />
<a href="#JWKFormat">4.</a>
JSON Web Key (JWK) Format<br />
<a href="#algDef">4.1.</a>
"alg" (Algorithm Family) Parameter<br />
<a href="#useDef">4.2.</a>
"use" (Key Use) Parameter<br />
<a href="#kidDef">4.3.</a>
"kid" (Key ID) Parameter<br />
<a href="#JWKSet">5.</a>
JSON Web Key Set (JWK Set) Format<br />
<a href="#keysDef">5.1.</a>
"keys" (JSON Web Key Set) Parameter<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#JWKParamReg">6.1.</a>
JSON Web Key Parameters Registry<br />
<a href="#anchor4">6.1.1.</a>
Registration Template<br />
<a href="#anchor5">6.1.2.</a>
Initial Registry Contents<br />
<a href="#JWKSetParamReg">6.2.</a>
JSON Web Key Set Parameters Registry<br />
<a href="#anchor6">6.2.1.</a>
Registration Template<br />
<a href="#anchor7">6.2.2.</a>
Initial Registry Contents<br />
<a href="#Security">7.</a>
Security Considerations<br />
<a href="#rfc.references1">8.</a>
References<br />
<a href="#rfc.references1">8.1.</a>
Normative References<br />
<a href="#rfc.references2">8.2.</a>
Informative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#TBD">Appendix B.</a>
Open Issues<br />
<a href="#anchor10">Appendix C.</a>
Document History<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>
A JSON Web Key (JWK) is a
JavaScript Object Notation (JSON) <a class='info' href='#RFC4627'>[RFC4627]<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a>
data structure that represents a public key.
This specification also defines a JSON Web Key Set (JWK Set)
JSON data structure for representing a set of JWKs.
Cryptographic algorithms and identifiers for use with this
specification are described in the separate
JSON Web Algorithms (JWA) <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a> specification.
</p>
<p>
Goals for this specification do not include representing
private keys, representing symmetric keys, representing
certificate chains, representing certified keys, and replacing
X.509 certificates.
</p>
<p>
JWKs and JWK Sets are used in the
JSON Web Signature (JWS) <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” October 2012.</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),” October 2012.</span><span>)</span></a>
specifications.
</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.1.1"></a><h3>1.1.
Notational Conventions</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
Key words for use in RFCs to Indicate Requirement Levels <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>.
</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.2"></a><h3>2.
Terminology</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>JSON Web Key (JWK)</dt>
<dd>
A JSON data structure that represents a public key.
</dd>
<dt>JSON Web Key Set (JWK Set)</dt>
<dd>
A JSON object that contains an array of JWKs as a member.
</dd>
<dt>Base64url Encoding</dt>
<dd>
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., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” October 2012.</span><span>)</span></a> for notes on implementing base64url
encoding without padding.)
</dd>
<dt>Collision Resistant Namespace</dt>
<dd>
A namespace that allows names to be allocated in a manner
such that they are highly unlikely to collide with other names.
For instance, collision resistance can be achieved through
administrative delegation of portions of the namespace or
through use of collision-resistant name allocation functions.
Examples of Collision Resistant Namespaces include:
Domain Names,
Object Identifiers (OIDs) as defined in the ITU-T X.660
and X.670 Recommendation series, and
Universally Unique IDentifiers (UUIDs)
<a class='info' href='#RFC4122'>[RFC4122]<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>.
When using an administratively delegated namespace,
the definer of a name needs to take
reasonable precautions to ensure they are in control of
the portion of the namespace they use to define the name.
</dd>
</dl></blockquote><p>
</p>
<a name="ExampleJWKSet"></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 JSON Web Key Set</h3>
<p>
The following example JWK Set contains two public keys
represented as JWKs: one
using an Elliptic Curve algorithm and a second one using an
RSA algorithm. The first specifies that the key is to be
used for encryption. Both provide a Key ID for key matching
purposes. In both cases, integers are represented using the
base64url encoding of their big endian representations.
(Long lines are broken are for display purposes only.)
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{"keys":
[
{"alg":"EC",
"crv":"P-256",
"x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
"y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
"use":"enc",
"kid":"1"},
{"alg":"RSA",
"mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"xpo":"AQAB",
"kid":"2011-04-29"}
]
}
</pre></div>
<a name="JWKFormat"></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.
JSON Web Key (JWK) Format</h3>
<p>
A JSON Web Key (JWK) is a JSON object containing specific
members, as specified below. Those members that are common
to all key types are defined below.
</p>
<p>
In addition to the common parameters, each JWK will have
members that are specific to the key being represented.
These members represent the parameters of the key.
Section 5 of the JSON Web Algorithms (JWA) <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a> specification
defines multiple kinds of public keys and their associated members.
</p>
<p>
The member names within a JWK MUST be unique;
objects with duplicate member names MUST be rejected.
</p>
<p>
Additional members MAY be present in the JWK.
If present, they MUST be understood by implementations using them.
Member names used for representing key parameters
for different kinds of keys need not be distinct.
Member names
SHOULD either be registered in the IANA JSON Web Key Parameters registry
<a class='info' href='#JWKParamReg'>Section 6.1<span> (</span><span class='info'>JSON Web Key Parameters Registry</span><span>)</span></a> or be
URIs that contain a Collision Resistant Namespace.
</p>
<a name="algDef"></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.
"alg" (Algorithm Family) Parameter</h3>
<p>
The <tt>alg</tt> (algorithm family) member
identifies the cryptographic algorithm family used with the key.
<tt>alg</tt> values SHOULD either be
registered in the IANA JSON Web Key Algorithm Families registry
<a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a> or be
a URI that contains a Collision Resistant Namespace.
The <tt>alg</tt> value is a case sensitive string.
This member is REQUIRED.
</p>
<p>
A list of defined <tt>alg</tt> values can be found
in the IANA JSON Web Key Algorithm Families registry <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a>;
the initial contents of this registry is the values defined in
Section 5.1 of the
JSON Web Algorithms (JWA) <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a> specification.
</p>
<p>
Additional members used with these <tt>alg</tt> values can be found
in the IANA JSON Web Key Parameters registry <a class='info' href='#JWKParamReg'>Section 6.1<span> (</span><span class='info'>JSON Web Key Parameters Registry</span><span>)</span></a>;
the initial contents of this registry is the values defined in
Sections 5.2 and 5.3 of the
JSON Web Algorithms (JWA) <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” October 2012.</span><span>)</span></a> specification.
</p>
<a name="useDef"></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.
"use" (Key Use) Parameter</h3>
<p>
The <tt>use</tt> (key use) member identifies the
intended use of the key. Values defined by this specification are:
</p>
<ul class="text">
<li><tt>sig</tt> (signature)
</li>
<li><tt>enc</tt> (encryption)
</li>
</ul><p>
Other values MAY be used.
The <tt>use</tt> value is a case sensitive string.
This member is OPTIONAL.
</p>
<a name="kidDef"></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.
"kid" (Key ID) Parameter</h3>
<p>
The <tt>kid</tt> (key ID) member can
be used to match a specific key. This can be used, for
instance, to choose among a set of keys within a JWK Set
during key rollover.
The interpretation of the <tt>kid</tt> value is unspecified.
Key ID values within a JWK Set need not be unique.
The <tt>kid</tt> value is a case sensitive string.
This member is OPTIONAL.
</p>
<p>
When used with JWS or JWE, the <tt>kid</tt>
value MAY be used to match a JWS or JWE <tt>kid</tt>
header parameter value.
</p>
<p>
In some contexts, different keys using the same Key ID value might be present,
with the keys being disambiguated using other information, such as the
<tt>alg</tt> or <tt>use</tt> values.
For example, imagine <tt>kid</tt> values like
"Current", "Upcoming", and "Deprecated", used for key rollover guidance.
One could apply a label to all keys where the classification fits.
If there are multiple "Current" keys, then in this example, they might be
differentiated either by having different "alg" or "use" values,
or some combination of both.
As one example, there might only be one current RSA signing key and
one current Elliptic Curve signing key, but both would be "Current".
</p>
<a name="JWKSet"></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.
JSON Web Key Set (JWK Set) Format</h3>
<p>
A JSON Web Key Set (JWK Set) is a JSON object that contains
an array of JSON Web Key values as the value of its
<tt>keys</tt> member.
</p>
<p>
The member names within a JWK Set MUST be unique;
objects with duplicate member names MUST be rejected.
</p>
<p>
Additional members MAY be present in the JWK Set.
If present, they MUST be understood by implementations using them.
Parameters for representing additional properties of JWK Sets
SHOULD either be registered in the IANA JSON Web Key Set Parameters registry
<a class='info' href='#JWKSetParamReg'>Section 6.2<span> (</span><span class='info'>JSON Web Key Set Parameters Registry</span><span>)</span></a> or be
a URI that contains a Collision Resistant Namespace.
</p>
<a name="keysDef"></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.1"></a><h3>5.1.
"keys" (JSON Web Key Set) Parameter</h3>
<p>
The value of the <tt>keys</tt> (JSON Web Key Set)
member is an array of JSON Web Key (JWK) values.
This member is REQUIRED.
</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.6"></a><h3>6.
IANA Considerations</h3>
<p>
The following registration procedure is used for all the
registries established by this specification.
</p>
<p>
Values are registered with a Specification Required
<a class='info' href='#RFC5226'>[RFC5226]<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> after a two week review period on the [TBD]@ietf.org mailing
list, on the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) may approve
registration once they are satisfied that such a specification will be published.
</p>
<p>
Registration requests must be sent to the [TBD]@ietf.org mailing list for review and
comment, with an appropriate subject (e.g., "Request for access token type: example").
[[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation
with the IESG and IANA. Suggested name: jose-reg-review. ]]
</p>
<p>
Within the review period, the Designated Expert(s) will either approve or
deny the registration request, communicating this decision to the review list and IANA.
Denials should include an explanation and, if applicable, suggestions as to how to make
the request successful.
</p>
<p>
IANA must only accept registry updates from the Designated Expert(s), and should direct
all requests for registration to the review mailing list.
</p>
<a name="JWKParamReg"></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.
JSON Web Key Parameters Registry</h3>
<p>
This specification establishes the
IANA JSON Web Key Parameters registry
for reserved JWK parameter names.
The registry records the reserved parameter name
and a reference to the specification that defines it.
This specification registers the parameter names defined in
<a class='info' href='#JWKFormat'>Section 4<span> (</span><span class='info'>JSON Web Key (JWK) Format</span><span>)</span></a>.
</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.6.1.1"></a><h3>6.1.1.
Registration Template</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Parameter Name:</dt>
<dd>
The name requested (e.g., "example").
This name is case sensitive. Names that match other registered names
in a case insensitive manner SHOULD NOT be accepted.
</dd>
<dt>Change Controller:</dt>
<dd>
For standards-track RFCs, state "IETF". For others, give the name of the
responsible party. Other details (e.g., postal address, e-mail address, home page
URI) may also be included.
</dd>
<dt>Specification Document(s):</dt>
<dd>
Reference to the document that specifies the parameter, preferably including a URI that
can be used to retrieve a copy of the document. An indication of the relevant
sections may also be included, but is not required.
</dd>
</dl></blockquote><p>
</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.6.1.2"></a><h3>6.1.2.
Initial Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Parameter Name: <tt>alg</tt>
</li>
<li>
Change Controller: IETF
</li>
<li>
Specification Document(s): <a class='info' href='#algDef'>Section 4.1<span> (</span><span class='info'>"alg" (Algorithm Family) Parameter</span><span>)</span></a> of [[ this document ]]
</li>
</ul><p>
</p>
<ul class="text">
<li>
Parameter Name: <tt>use</tt>
</li>
<li>
Change Controller: IETF
</li>
<li>
Specification Document(s): <a class='info' href='#useDef'>Section 4.2<span> (</span><span class='info'>"use" (Key Use) Parameter</span><span>)</span></a> of [[ this document ]]
</li>
</ul><p>
</p>
<ul class="text">
<li>
Parameter Name: <tt>kid</tt>
</li>
<li>
Change Controller: IETF
</li>
<li>
Specification Document(s): <a class='info' href='#kidDef'>Section 4.3<span> (</span><span class='info'>"kid" (Key ID) Parameter</span><span>)</span></a> of [[ this document ]]
</li>
</ul><p>
</p>
<a name="JWKSetParamReg"></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.2"></a><h3>6.2.
JSON Web Key Set Parameters Registry</h3>
<p>
This specification establishes the
IANA JSON Web Key Set Parameters registry
for reserved JWK Set parameter names.
The registry records the reserved parameter name
and a reference to the specification that defines it.
This specification registers the parameter names defined in
<a class='info' href='#JWKSet'>Section 5<span> (</span><span class='info'>JSON Web Key Set (JWK Set) Format</span><span>)</span></a>.
</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.6.2.1"></a><h3>6.2.1.
Registration Template</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Parameter Name:</dt>
<dd>
The name requested (e.g., "example").
This name is case sensitive. Names that match other registered names
in a case insensitive manner SHOULD NOT be accepted.
</dd>
<dt>Change Controller:</dt>
<dd>
For standards-track RFCs, state "IETF". For others, give the name of the
responsible party. Other details (e.g., postal address, e-mail address, home page
URI) may also be included.
</dd>
<dt>Specification Document(s):</dt>
<dd>
Reference to the document that specifies the parameter, preferably including a URI that
can be used to retrieve a copy of the document. An indication of the relevant
sections may also be included, but is not required.
</dd>
</dl></blockquote><p>
</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.6.2.2"></a><h3>6.2.2.
Initial Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
Parameter Name: <tt>keys</tt>
</li>
<li>
Change Controller: IETF
</li>
<li>
Specification Document(s): <a class='info' href='#keysDef'>Section 5.1<span> (</span><span class='info'>"keys" (JSON Web Key Set) Parameter</span><span>)</span></a> of [[ this document ]]
</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.7"></a><h3>7.
Security Considerations</h3>
<p>
All of the security issues faced by any cryptographic application
must be faced by a JWS/JWE/JWK agent. Among these issues are protecting
the user's private key, preventing various attacks, and helping the
user avoid mistakes such as inadvertently encrypting a message for
the wrong recipient. The entire list of security considerations is
beyond the scope of this document, but some significant concerns are
listed here.
</p>
<p>
A key is no more trustworthy than the method by which it was received.
</p>
<p>
Per <a class='info' href='#kidDef'>Section 4.3<span> (</span><span class='info'>"kid" (Key ID) Parameter</span><span>)</span></a>, applications should not assume
that <tt>kid</tt> values are unique within
a JWK Set.
</p>
<p>
The security considerations in
<a class='info' href='#W3C.CR-xmldsig-core2-20120124'>XML DSIG 2.0<span> (</span><span class='info'>Roessler, T., Yiu, K., Solo, D., Reagle, J., Datta, P., Eastlake, D., Hirsch, F., and S. Cantor, “XML Signature Syntax and Processing Version 2.0,” January 2012.</span><span>)</span></a> [W3C.CR‑xmldsig‑core2‑20120124],
about public key representations also apply to this specification,
other than those that are XML specific.
</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.8"></a><h3>8.
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>8.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="JWA">[JWA]</a></td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">JSON Web Algorithms (JWA)</a>,” October 2012.</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="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="W3C.CR-xmldsig-core2-20120124">[W3C.CR-xmldsig-core2-20120124]</a></td>
<td class="author-text">Roessler, T., Yiu, K., Solo, D., Reagle, J., Datta, P., Eastlake, D., Hirsch, F., and S. Cantor, “<a href="http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124">XML Signature Syntax and Processing Version 2.0</a>,” World Wide Web Consortium CR CR-xmldsig-core2-20120124, January 2012 (<a href="http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124">HTML</a>).</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>8.2. Informative References</h3>
<table width="99%" border="0">
<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-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>,” October 2012.</td></tr>
<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:ve7jtb@ve7jtb.com">Bradley, J.</a>, and <a href="mailto:n-sakimura@nri.co.jp">N. Sakimura</a>, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature (JWS)</a>,” October 2012.</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-01.html">Magic Signatures</a>,” January 2011.</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>
</table>
<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.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>
A JSON representation for RSA public keys was previously
introduced by John Panzer, Ben Laurie, and Dirk Balfanz
in <a class='info' href='#MagicSignatures'>Magic Signatures<span> (</span><span class='info'>Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011.</span><span>)</span></a> [MagicSignatures].
</p>
<p>
Jim Schaad and Karen O'Donoghue chaired the JOSE working group and
Sean Turner and Stephen Farrell served as Security area directors
during the creation of this specification.
</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.B"></a><h3>Appendix B.
Open Issues</h3>
<p>
[[ to be removed by the RFC editor before publication as an RFC ]]
</p>
<p>
The following items remain to be considered or done in this draft:
</p>
<ul class="text">
<li>
No known open issues.
</li>
</ul><p>
</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.C"></a><h3>Appendix C.
Document History</h3>
<p>
[[ to be removed by the RFC editor before publication as an RFC ]]
</p>
<p>
-06
</p>
<ul class="text">
<li>
Changed the name of the JWK RSA exponent parameter from
<tt>exp</tt> to <tt>xpo</tt>
so as to allow the potential use of the name <tt>exp</tt>
for a future extension that might define an expiration parameter for keys.
(The <tt>exp</tt> name is already used for this
purpose in the JWT specification.)
</li>
<li>
Clarify that the <tt>alg</tt> (algorithm family)
member is REQUIRED.
</li>
<li>
Correct an instance of "JWK" that should have been "JWK Set".
</li>
</ul><p>
</p>
<p>
-05
</p>
<ul class="text">
<li>
Indented artwork elements to better distinguish them from the body text.
</li>
</ul><p>
</p>
<p>
-04
</p>
<ul class="text">
<li>
Refer to the registries as the primary sources of defined
values and then secondarily reference the sections
defining the initial contents of the registries.
</li>
<li>
Normatively reference
<a class='info' href='#W3C.CR-xmldsig-core2-20120124'>XML DSIG 2.0<span> (</span><span class='info'>Roessler, T., Yiu, K., Solo, D., Reagle, J., Datta, P., Eastlake, D., Hirsch, F., and S. Cantor, “XML Signature Syntax and Processing Version 2.0,” January 2012.</span><span>)</span></a> [W3C.CR‑xmldsig‑core2‑20120124]
for its security considerations.
</li>
<li>
Added this language to Registration Templates:
"This name is case sensitive. Names that match other registered names
in a case insensitive manner SHOULD NOT be accepted."
</li>
<li>
Described additional open issues.
</li>
<li>
Applied editorial suggestions.
</li>
</ul><p>
</p>
<p>
-03
</p>
<ul class="text">
<li>
Clarified that <tt>kid</tt> values need not be unique
within a JWK Set.
</li>
<li>
Moved JSON Web Key Parameters registry to the JWK specification.
</li>
<li>
Added "Collision Resistant Namespace" to the terminology section.
</li>
<li>
Changed registration requirements from RFC Required to
Specification Required with Expert Review.
</li>
<li>
Added Registration Template sections for defined registries.
</li>
<li>
Added Registry Contents sections to populate registry values.
</li>
<li>
Numerous editorial improvements.
</li>
</ul><p>
</p>
<p>
-02
</p>
<ul class="text">
<li>
Simplified JWK terminology to get replace the "JWK Key Object" and
"JWK Container Object" terms with simply "JSON Web Key (JWK)"
and "JSON Web Key Set (JWK Set)" and to eliminate potential
confusion between single keys and sets of keys.
As part of this change, the top-level member name for a
set of keys was changed from <tt>jwk</tt>
to <tt>keys</tt>.
</li>
<li>
Clarified that values with duplicate member names MUST be rejected.
</li>
<li>
Established JSON Web Key Set Parameters registry.
</li>
<li>
Explicitly listed non-goals in the introduction.
</li>
<li>
Moved algorithm-specific definitions from JWK to JWA.
</li>
<li>
Reformatted to give each member definition its own section heading.
</li>
</ul><p>
</p>
<p>
-01
</p>
<ul class="text">
<li>
Corrected the Magic Signatures reference.
</li>
</ul><p>
</p>
<p>
-00
</p>
<ul class="text">
<li>
Created the initial IETF draft based upon
draft-jones-json-web-key-03 with no normative changes.
</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>Author's Address</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>
</table>
</body></html>