<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect Artifact Binding 1.0 - draft 01</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Artifact Binding 1.0 - draft 01">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">N. Sakimura, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradeley</td></tr>
<tr><td class="header"> </td><td class="header">Protiviti Government Services</td></tr>
<tr><td class="header"> </td><td class="header">B. de Madeiros</td></tr>
<tr><td class="header"> </td><td class="header">Google</td></tr>
<tr><td class="header"> </td><td class="header">R. Ito</td></tr>
<tr><td class="header"> </td><td class="header">Yahoo! Japan</td></tr>
<tr><td class="header"> </td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">January 14, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Artifact Binding 1.0 - draft 01</h1>
<h3>Abstract</h3>
<p>OpenID Connect Artifact Binding 1.0 is a HTTP protocol binding of OpenID Connect Core 1.0. It provides the facility to send a large request that includes various OpenID 2.0 extensions requests securely and compactly so that it will function even on the capability limited browsers such as found on mobile phones.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#rnc">1.</a>
Requirements Notation and Conventions<br />
<a href="#terminology">2.</a>
Terminology<br />
<a href="#protocol_flows">3.</a>
Protocol Flows<br />
<a href="#rf_prep">3.1.</a>
Client prepares a Request File<br />
<a href="#rurl_create">3.2.</a>
Client Obtains the URL of the Request File<br />
<a href="#art_req">3.3.</a>
Client sends a request to Authorization Server via HTTPS redirect<br />
<a href="#anchor1">3.4.</a>
Authorization Server fetches the Request File<br />
<a href="#anchor2">3.5.</a>
Authorization Server Authenticates the End-User<br />
<a href="#anchor3">3.6.</a>
Authorization Server Obtains the End-User Consent/Authorization<br />
<a href="#art_res">3.7.</a>
Authorization Server Sends the End-User back to the Client <br />
<a href="#anchor4">3.8.</a>
Client requests Assertion using the Artifact ("code")<br />
<a href="#anchor5">3.9.</a>
Client receives Assertion in the response body<br />
<a href="#id_req">3.10.</a>
Accessing Userinfo Endpoint<br />
<a href="#id_res">3.11.</a>
RP receives UserInfo Response<br />
<a href="#security_considerations">4.</a>
Security Considerations<br />
<a href="#assertion_manufacture">4.1.</a>
Assertion manufacture/modification<br />
<a href="#assertion_disclosure">4.2.</a>
Assertion disclosure<br />
<a href="#assertion_repudiation">4.3.</a>
Assertion repudiation<br />
<a href="#assertion_redirect">4.4.</a>
Assertion redirect<br />
<a href="#assertion_reuse">4.5.</a>
Assertion reuse<br />
<a href="#artifact_manufacture">4.6.</a>
Secondary authenticator manufacture<br />
<a href="#artifact_capture">4.7.</a>
Secondary authenticator capture<br />
<a href="#assertion_substitution">4.8.</a>
Assertion substitution<br />
<a href="#auth_req_disclosure">4.9.</a>
Authentication Request Disclosure<br />
<a href="#anchor10">4.10.</a>
Timing Attack<br />
<a href="#authn_proc_threats">4.11.</a>
Authentication Process Threats<br />
<a href="#iana">5.</a>
IANA Considerations<br />
<a href="#oauth_params">5.1.</a>
OAuth Parameters Registry<br />
<a href="#anchor11">Appendix A.</a>
Acknowledgements<br />
<a href="#rfc.references1">6.</a>
Normative References<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="rnc"></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.
Requirements Notation and 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 <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>
<p>Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
</p>
<a name="terminology"></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>Followings are the terminology defined in the <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc]. </p>
<blockquote class="text"><dl>
<dt>Protected Resource</dt>
<dd>An access-restricted resource which can be obtained using an OAuth-authenticated request.
</dd>
<dt>Resource Server</dt>
<dd>A server capable of accepting and responding to protected resource requests.
</dd>
<dt>Client</dt>
<dd>An application obtaining authorization and making protected resource requests.
</dd>
<dt>Resource Owner</dt>
<dd>An entity capable of granting access to a protected resource.
</dd>
<dt>End-user</dt>
<dd>A human resource owner.
</dd>
<dt>Authentication</dt>
<dd>An act of verifying End-User's identity through the verification of the credential.
</dd>
<dt>Token</dt>
<dd>A string representing an access authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization servers. The token may denote an identifier used to retrieve the authorization information, or self-contain the authorization information in a verifiable manner (i.e. a token string consisting of some data and a signature). Tokens may be pure capabilities. Specific additional authentication credentials may be required in order for a client to use a token.
</dd>
<dt>Access Token</dt>
<dd>A token used by the client to make authenticated requests on behalf of the resource owner.
</dd>
<dt>Refresh Token</dt>
<dd>A token used by the client to obtain a new access token without having to involve the resource owner. authorization code.
</dd>
<dt>Authorization Code</dt>
<dd>A short-lived token representing the authorization provided by the end-user. The authorization code is used to obtain an access token and a refresh token.
</dd>
<dt>Access Grant</dt>
<dd>A general term used to describe the intermediate credentials (such as an end-user password or authorization code) representing the resource owner authorization. Access grants are used by the client to obtain an access token. By exchanging access grants of different types for an access token, the resource server is only required to support a single authentication scheme.
</dd>
<dt>Authorization Server</dt>
<dd>A server capable of authenticating the resource owner and issuing tokens after obtaining authorization from the authenticated Resource Owner. The authorization server may be the same server as Resource Server or a separate entity. A single authorization server may issue tokens for multiple resource servers.
</dd>
<dt>OpenID Provider (OP)</dt>
<dd>Authorization Servers that are able to support OpenID Connect Messages.
</dd>
<dt>Relying Party (RP)</dt>
<dd>Client and Resource Servers.
</dd>
<dt>End-User Authorization Endpoint</dt>
<dd>The Authorization Server's endpoint capable of authenticating the End-User and obtaining authorization.
</dd>
<dt>Client Identifier</dt>
<dd>An unique identifier that the client to identify itself to the OP.
</dd>
<dt>Client Secret</dt>
<dd>A shared secret established between the OP and client.
</dd>
<dt>Token Endpoint</dt>
<dd>The Authorization Server's HTTP endpoint capable of issuing tokens.
</dd>
<dt>OP Endpoints</dt>
<dd>End-User Authentication, Authorization, and Token Endpoint.
</dd>
<dt>RP Endpoints</dt>
<dd>The endpoint to which the OP responses are returned through redirect.
</dd>
<dt>UserInfo Endpoint</dt>
<dd>A protected resource that when presented with a token by the client returns authorized information about the current user.
</dd>
<dt>Claims</dt>
<dd>A statement that something is true or factual.
</dd>
<dt>Assertion</dt>
<dd>A set of Claims about the End-User which is attested by the OP and Resource Servers.
</dd>
<dt>Compact Serialization</dt>
<dd>Compact Serialization defined in <a class='info' href='#jwt'>JSON Simple Sign<span> (</span><span class='info'>Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.</span><span>)</span></a> [jwt].
</dd>
<dt>Base64url</dt>
<dd>Base 64 Encoding <a class='info' href='#RFC3548'>[RFC3548]<span> (</span><span class='info'>Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.</span><span>)</span></a> with URL and Filename Safe Alphabet without padding.
</dd>
</dl></blockquote><p>Followings are the additional terminology defined in this specification.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Artifact</dt>
<dd>A small string that acts as a reference to the larger body of data.
</dd>
<dt>Request File</dt>
<dd>A JSON structure that captures the <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc] Authorization Request parameters that can be pointed by a URL that is reacheable by the Authorization Server.
</dd>
<dt>Request URI</dt>
<dd>A URL that points to the Request File. It MUST be accessible by the Authorization Server.
</dd>
<dt>Request Registration Endpoint</dt>
<dd>An HTTPS Endpoint URL provided by the Authorization Server so that the Client MAY register the Request File to obtain the Request URI.
</dd>
</dl></blockquote>
<a name="protocol_flows"></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.
Protocol Flows</h3>
<p>The protocol flow goes through the following steps.
</p>
<p></p>
<ol class="text">
<li>Client prepares a JSON Request File that contains all the request parameters.
</li>
<li>Client obtains the URL of the Request File.
</li>
<li>Client sends a request to Authorization Server via HTTPS redirect
</li>
<li>Authorization Server fetches the Request File
</li>
<li>Authorization Server Authenticates the End-User
</li>
<li>Authorization Server Obtains the End-User Consent/Authorization
</li>
<li>Authorization Server Sends the End-User back to the Client
</li>
<li>Client requests Assertion using the Artifact ("code")
</li>
<li>Client receives Assertion in the response body
</li>
<li>(OPTIONAL) Accessing Userinfo Endpoint
</li>
<li>(OPTIONAL) RP receives UserInfo Response
</li>
</ol><p>Note that in each step, the party that receives message MUST verify it according to the verification rule set in <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc].
</p>
<p>
</p>
<a name="rf_prep"></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.
Client prepares a Request File</h3>
<p>The Client prepares an Authorization Request described in <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc] with a globally reachable URL with the following parameters constraint.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>Set to <tt>"code"</tt>.
</dd>
</dl></blockquote><p>Optionally, it may contain other extension parameters. It MAY be signed as in <a class='info' href='#jwt'>[jwt]<span> (</span><span class='info'>Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.</span><span>)</span></a>.
</p>
<p>Following is a non-normative example of a Requst File. Note that the line wraps within the values are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type": "http://openid.net/specs/cc/1.0#env,
"redirect_uri": "https://example.com/rp/endpoint_url",
"response_type":"code",
"client_id": "http://example.com/rp/",
"scope": "openid",
"openid": {
"type": "http://openid.net/specs/cc/1.0#req",
"server_id": "http://example.com/op/",
"realm":"http://rp.example.com/",
"immediate": "true",
"claimed_id":"http://specs.openid.net/auth/2.0/identifier_select",
"identity": "http://specs.openid.net/auth/2.0/identifier_select",
"ns.pape": "http://openid.net/srv/ax/1.0",
"pape.max_auth_age":0,
"pape.preferred_auth_policies": "
http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privat
epersonalidentifier
http://www.idmanagement.gov/schema/2009/05/icam/openidtrust-level1.pdf"
}
}</pre></div>
<a name="rurl_create"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Client Obtains the URL of the Request File</h3>
<p>Client then records the Request File either locally or remotely and obtains the Request URI, <tt>"request_uri"</tt>.
</p>
<p>Optionally, the Authorization Server may provide the Request File registration service at the Request Registration Endpoint, which allows the Client to register the Request File and obtain the URL for it in exchange. This is especially useful for the cases such as the RP is behind the firewall or lives on a client device that cannot be accessed from the Authorization Server.
</p>
<a name="art_req"></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.3"></a><h3>3.3.
Client sends a request to Authorization Server via HTTPS redirect</h3>
<p>When the user wishes to access a Protected Resource, and the End-User Authorization has not yet been obtained, the Client sends the user to the HTTPS End-User Authorization Endpoint through the HTTP 302 redirect with the following parameters. The entire URL MUST NOT exceed 512 bytes.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>REQUIRED. <tt>"token".</tt>
</dd>
<dt>request_uri</dt>
<dd>REQUIRED. The Request URI.
</dd>
<dt>immediate</dt>
<dd>OPTIONAL. <tt>true</tt> or <tt>false</tt>. Used to override what was written in the Request File.
</dd>
<dt>claimed_id</dt>
<dd>OPTIONAL. claimed_id MAY be sent as flow parameter to override what is written in the Request File.
</dd>
<dt>state</dt>
<dd>OPTIONAL. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.
</dd>
</dl></blockquote><p>Following is a non-normative example. Note: Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://rp.example.com/rp.php?response_type=token
&request_uri=https://rp.example.com/rf.js%23Qfsoe2F
&state=A02FB8C</pre></div>
<p>
</p>
<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.3.4"></a><h3>3.4.
Authorization Server fetches the Request File</h3>
<p>Upon receipt of the Request, the Authorization Server MUST send a GET request to the <tt>request_uri</tt> to retrieve the content unless it is already cached and parse it to recreate the request parameters.
</p>
<p>Following is a non-normative example of this fetch process. Note: Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /rf.js HTTP/1.1
Host:rp.example.com</pre></div>
<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.3.5"></a><h3>3.5.
Authorization Server Authenticates the End-User</h3>
<p>If the Request File had the End-User identifier, the Authorization Server MUST authenticate the End-User as the user that matches the identifier. If the Request File did not have an End-User identifier or the identifier was <tt>http://specs.openid.net/auth/2.0/identifier_select</tt>, then the Authorization Server SHOULD provide the user with the way to select or input the user's identifier and credential so that the Authorization Server can authenticate the user.
</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.6"></a><h3>3.6.
Authorization Server Obtains the End-User Consent/Authorization</h3>
<p>Once the user is authenticated, the Authorization Server MUST present the user with the dialogue that allows the user to recognize what he is consenting to and obtain his consent.
</p>
<p>Note that this server does not have to be the same server as the authenticating server. Also note that different jurisdictions have different requirement to this dialgue to be legally compliant.
</p>
<a name="art_res"></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.7"></a><h3>3.7.
Authorization Server Sends the End-User back to the Client </h3>
<p>Once it is determined, the Authorization Server creates either positive or negative assertion and associated Artifact called <tt>"code"</tt> and returns the response to the RP Endpoint specified in <tt>redirect_uri</tt> URL specified in the Authorization Request with following parameters:
</p>
<a name="art_res_ok"></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.7.1"></a><h3>3.7.1.
End-user Grants Authorization</h3>
<p></p>
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The artifact Value.
</dd>
<dt>state</dt>
<dd>REQUIRED if it was in the request. Set to the exact value received from the RP.
</dd>
<dt>server_id</dt>
<dd>The Server Identifier.
</dd>
</dl></blockquote>
<p>No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes.
</p>
<p>Following is a non-normative example. Line wraps after the second line is for the display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://rp.example.com/rp.php?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk</pre></div>
<p>
</p>
<a name="authz_error"></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.7.2"></a><h3>3.7.2.
End-User Denies Authorization or Invalid Request FIle</h3>
<p>If the user denies the authorization or the user authentication fails, the server MUST return the negative authorization response as defined in <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc]. No other parameter SHOULD be returned. The entire URL MUST NOT exceed 512 bytes.
</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.3.8"></a><h3>3.8.
Client requests Assertion using the Artifact ("code")</h3>
<p>Upon receipt of the <tt>"code"</tt>, the Client requests Assertion that includes <tt>"access_token"</tt> and other variables. To obtain the assertion, send the following parameters via HTTPS POST to the token endpoint using the <tt>application/x-www-form-urlencoded</tt> format in the HTTP request entity-body:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>grant_type</dt>
<dd>REQUIRED. A string "authorization_code".
</dd>
<dt>code</dt>
<dd>REQUIRED. The artifact received.
</dd>
<dt>client_id</dt>
<dd>REQUIRED. The client_id of the RP.
</dd>
<dt>client_secret</dt>
<dd>OPTIONAL. Client Secret. If the secret_type is <tt>"shared"</tt>, send the pre-shared secret. If the secret_type is <tt>"jwt"</tt>, send the compact serealization of the <a class='info' href='#jwt'>JWT<span> (</span><span class='info'>Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.</span><span>)</span></a> [jwt] Signature over the 'code'.
</dd>
<dt>secret_type</dt>
<dd>OPTIONAL. Type of the <tt>client_secret</tt>. <tt>"shared"</tt> or <tt>"jwt"</tt>. Defaults to <tt>"shared"</tt>.
</dd>
</dl></blockquote>
<p>
</p>
<p>The following is a non-normative example. Line wraps after line 4 are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=_artifact_received_
&client_id=https%3A%2F%2Frp.example.com%2Frpf.json
&client_secret=1234qwer&secret_type=shared</pre></div>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.9"></a><h3>3.9.
Client receives Assertion in the response body</h3>
<p>Upon receipt of the Token Request, the Server MUST return either Positive or Negative Assertion that corresponds to the received Artifact <tt>"code"</tt>.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.9.1"></a><h3>3.9.1.
Positive Assertion</h3>
<p>Positive Assertion is the Authorization Response of the <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc]. It MUST include the fields that corresonds to what the user authorized while it MUST NOT include what was not authorized. The Assertion is returned in the entity body of the HTTP response using the application/json media type as defined by <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>. The Assertion format depends on what was requested initially in <tt>atype</tt> request parameter, e.g., <tt>openid2json, openid2json+sig, openid2json+sig+enc, saml2, wss, uprov</tt>, etc.
</p>
<p>The authorization server MUST include the HTTP <tt>Cache-Control</tt> response header field with a value of <tt>no-store</tt> in any response containing tokens, secrets, or other sensitive information.
</p>
<p>Following is a non-normative example for <tt>openid2json</tt> version of the Assertion:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": "SlAV32hkKG",
"refresh_token": "8xLOxBtZp8",
"user_id": "http://op.example.com/alice#1234",
"domain": "op.example.com",
"expires_in": 3600,
"openid": {
"type": "http://openid.net/specs/cc/1.0#id_res",
"op_endpoint": "https://op.example.com/op_endpoint",
"client_id": "http://rp.example.com/",
"server_id": "http://op.example.com/",
"claimed_id": "https://example.com/alice#1234",
"identity": "alice",
"issued_at": 1274889460,
"access_tokens": [
{
"endpoint": "https://ds1.example.com/attrs",
"access_token": "af0skdjf",
"user_id": "8fjslek02IfjwIKSlfao9fjwldkfj",
"expires_in": 3600
},
{
"endpoint": "https://ds2.example.com/cal",
"access_token": "Z9fl3i",
"user_id": "P8fhs",
"expires_in": 3600
}
]
}
}</pre></div>
<p>
</p>
<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.3.9.2"></a><h3>3.9.2.
Error Response</h3>
<p>If the Token Request is invalid or unauthorized, the Authorization Server constructs the response by returning the Token Error Response defined in <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc] in the entity body of the HTTP response using the <tt>application/json</tt> media type with HTTP response code 400.
</p>
<p>Following is a non-normative example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_request"
}</pre></div>
<a name="id_req"></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.10"></a><h3>3.10.
Accessing Userinfo Endpoint</h3>
<p>To obtain the additional attributes and tokens/assertions, the client makes a GET or POST request to the Userinfo Endpoint as in <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc].
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.10.1"></a><h3>3.10.1.
Requesting Userinfo</h3>
<p>Client SHOULD send the Compact Serialization of the UserInfo request defined in section 4.4 of the <a class='info' href='#cc'>OpenID Connect Core 1.0<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> [cc]. Unless atype in the authorization request was "openid2json+sig+enc", it is strongly recommended to use the signed request.
</p>
<p>The following is a non-normative example. Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=_artifact_received_
&client_id=https%3A%2F%2Frp.example.com%2Frpf.json
&client_secret=1234qwer&secret_type=shared</pre></div>
<p>
</p>
<a name="id_res"></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.11"></a><h3>3.11.
RP receives UserInfo Response</h3>
<p>Upon receipt of the UserInfo Request, the UserInfo Endpoint MUST return the JSON Serialization of the Userinfo Response as in <a class='info' href='#cc'>[cc]<span> (</span><span class='info'>Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “OpenID Connect Core 1.0,” September 2010.</span><span>)</span></a> in the HTTP response body.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.11.1"></a><h3>3.11.1.
Error Response</h3>
<p>(TBD)
</p>
<a name="security_considerations"></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.
Security Considerations</h3>
<p>Followings are the list of attack vectors and remedies that were considered for this specification.
</p>
<p>For details of the attack vector, see <a class='info' href='#SP800-63'>[SP800‑63]<span> (</span><span class='info'>National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .</span><span>)</span></a>.
</p>
<a name="assertion_manufacture"></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.
Assertion manufacture/modification</h3>
<p>To mitigate this attack, there are two ways to mitigate it.
</p>
<p></p>
<ol class="text">
<li>The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP.
</li>
<li>The assertion may be sent over a protected channel such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel.
</li>
</ol>
<a name="assertion_disclosure"></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.
Assertion disclosure</h3>
<p>The Assertion disclosure can be mitigated in the following two ways.
</p>
<p></p>
<ol class="text">
<li>Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret".
</li>
<li>Signed Assertion is encrypted by the RP's public key.
</li>
</ol>
<a name="assertion_repudiation"></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.
Assertion repudiation</h3>
<p>To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP.
</p>
<a name="assertion_redirect"></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.4"></a><h3>4.4.
Assertion redirect</h3>
<p>To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as "client_id". The RP verifies that incoming assertions include its identity as the recipient of the assertion.
</p>
<a name="assertion_reuse"></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.5"></a><h3>4.5.
Assertion reuse</h3>
<p>The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid.
</p>
<a name="artifact_manufacture"></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.6"></a><h3>4.6.
Secondary authenticator manufacture</h3>
<p>Due to the large entropy requirement of the Artifact ("code") and short life nature of its validity, the success probability of this attack is extremely low.
</p>
<a name="artifact_capture"></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.7"></a><h3>4.7.
Secondary authenticator capture</h3>
<p>Secondary authenticator (="code") is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP.
</p>
<p>Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption.
</p>
<a name="assertion_substitution"></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.8"></a><h3>4.8.
Assertion substitution</h3>
<p>Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets.
</p>
<a name="auth_req_disclosure"></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.9"></a><h3>4.9.
Authentication Request Disclosure</h3>
<p>If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request.
</p>
<p>If the Request File is encrypted by the OP's public key, the authentication request will not be disclosed unless OP's private key gets compromised or the encryption algorithm becomes vulnerable.
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.10"></a><h3>4.10.
Timing Attack</h3>
<p>Timing attack can be used to reduce the effctive key length of the signature if the time required to return the response in case of signature error and correct signature exists. Care should be taken in the implementation to avoid this attack.
</p>
<a name="authn_proc_threats"></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.11"></a><h3>4.11.
Authentication Process Threats</h3>
<p>In the category of Authentication Process Threats, following threats exists.
</p>
<p></p>
<ul class="text">
<li>Online guessing
</li>
<li>Phishing
</li>
<li>Pharming
</li>
<li>Eavesdropping
</li>
<li>Replay
</li>
<li>Session hijack
</li>
<li>Man-in-the-middle
</li>
</ul><p>Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection.
</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.5"></a><h3>5.
IANA Considerations</h3>
<a name="oauth_params"></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.
OAuth Parameters Registry</h3>
<p>The following is the parameter registration request for the "scope" parameter as defined in this specification:
</p>
<p>Parameter name: openid
</p>
<p>Parameter usage location: The end-user authorization endpoint request, the end-user authorization endpoint response, the token endpoint request, the token endpoint response, and the "WWW-Authenticate" header field.
</p>
<p>Parameter usage location: The end-user authorization endpoint request, the end-user authorization endpoint response, the token endpoint request, the token endpoint response, and the "WWW-Authenticate" header field.
</p>
<p>Change controller: IETF
</p>
<p>Specification document(s): [[ this document ]]
</p>
<p>Related information: None
</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.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>As a binding of OpenID Authentication, this specification heavily relies on OpenID Authentication 2.0. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for OpenID Authentication 2.0.
</p>
<p>In addition, the OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.
</p>
<p></p>
<blockquote class="text">
<p>Breno de Medeiros (breno@gmail.com)
</p>
<p>Hideki Nara (hideki.nara@gmail.com)
</p>
<p>John Bradley (jbradely@mac.com) <author>
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp) <author/editor>
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp)
</p>
</blockquote>
<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>6. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FIPS180-2">[FIPS180-2]</a></td>
<td class="author-text">U.S. Department of Commerce and National Institute of Standards and Technology, “<a href="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf">Secure Hash Signature Standard</a>,” FIPS 180-2.<p>
Defines Secure Hash Algorithm 256 (SHA256)
</p>
</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.authentication-2.0">[OpenID.authentication-2.0]</a></td>
<td class="author-text">specs@openid.net, “OpenID Authentication 2.0,” 2007 (<a href="http://www.openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a href="http://www.openid.net/specs/openid-authentication-2_0.html">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1421">[RFC1421]</a></td>
<td class="author-text"><a href="mailto:104-8456@mcimail.com">Linn, J.</a>, “<a href="http://tools.ietf.org/html/rfc1421">Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</a>,” RFC 1421, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1421.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1422">[RFC1422]</a></td>
<td class="author-text"><a href="mailto:kent@BBN.COM">Kent, S.</a>, “<a href="http://tools.ietf.org/html/rfc1422">Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management</a>,” RFC 1422, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1422.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1423">[RFC1423]</a></td>
<td class="author-text"><a href="mailto:balenson@tis.com">Balenson, D.</a>, “<a href="http://tools.ietf.org/html/rfc1423">Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</a>,” RFC 1423, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1423.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1424">[RFC1424]</a></td>
<td class="author-text"><a href="mailto:burt@rsa.com">Kaliski, B.</a>, “<a href="http://tools.ietf.org/html/rfc1424">Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services</a>,” RFC 1424, February 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1424.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1750">[RFC1750]</a></td>
<td class="author-text"><a href="mailto:dee@lkg.dec.com">Eastlake, D.</a>, <a href="mailto:crocker@cybercash.com">Crocker, S.</a>, and <a href="mailto:jis@mit.edu">J. Schiller</a>, “<a href="http://tools.ietf.org/html/rfc1750">Randomness Recommendations for Security</a>,” RFC 1750, December 1994 (<a href="http://www.rfc-editor.org/rfc/rfc1750.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="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2617">[RFC2617]</a></td>
<td class="author-text"><a href="mailto:john@math.nwu.edu">Franks, J.</a>, <a href="mailto:pbaker@verisign.com">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>,” RFC 2617, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2617.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2617.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2617.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3548">[RFC3548]</a></td>
<td class="author-text">Josefsson, S., “<a href="http://tools.ietf.org/html/rfc3548">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 3548, July 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3548.txt">TXT</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="SP800-63">[SP800-63]</a></td>
<td class="author-text">National Institute of Standards and Technology, “<a href="http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-Rev1_Dec2008.pdf">NIST SP800-63rev.1: Electronic Authentication Guideline</a>,” NIST SP800-63.<p>
Defines LoA
</p>
</td></tr>
<tr><td class="author-text" valign="top"><a name="cc">[cc]</a></td>
<td class="author-text">Recordon, D., Sakimura, N., Ed., Bradeley, J., de Madeiros, B., and M. Jones, “<a href="http://jsonenc.info/sig/1.0/">OpenID Connect Core 1.0</a>,” September 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="json_enc">[json_enc]</a></td>
<td class="author-text">Bradeley, J. and N. Sakimura, “<a href="http://jsonenc.info/1.0/">JSON Simple Encryption</a>,” September 2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="jwt">[jwt]</a></td>
<td class="author-text">Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://jsonenc.info/sig/1.0/">JSON Web Token</a>,” January 2011.</td></tr>
</table>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Nat Sakimura (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute, Ltd.</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">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Protiviti Government Services</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:jbradley@mac.com">jbradley@mac.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Breno de Madeiros</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Google Inc.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:breno@google.com">breno@google.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ryo Ito</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Yahoo Japan Corporation</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ritou.06@gmail.com">ritou.06@gmail.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Mike Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft Corporation</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a></td></tr>
</table>
</body></html>