<!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 Core 1.0 - draft 01</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Core 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">D. Recordon</td></tr>
<tr><td class="header"> </td><td class="header">Facebook</td></tr>
<tr><td class="header"> </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">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 Core 1.0 - draft 01</h1>
<h3>Abstract</h3>
<p>OpenID Connect is an identity framework that provides authentication, authorization, and attribute transmition capability. It allows third party attested claims from distributed sources. The specification suite consists of Core, Protocol Bindings, Dynamic Registration, Discovery and Extensions. This specification is the "Core" of the suite that defines the messages used and abstract flow which will be further constrained or extended in the companion specifications in the suite.
</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="#anchor1">3.</a>
Overview<br />
<a href="#anchor2">4.</a>
Messages<br />
<a href="#rpf">4.1.</a>
Authorization Request<br />
<a href="#anchor3">4.2.</a>
Access Grant Response<br />
<a href="#anchor4">4.3.</a>
Access Grant Error Response<br />
<a href="#anchor6">4.4.</a>
Access Token Request<br />
<a href="#atr">4.5.</a>
Access Token Response<br />
<a href="#anchor7">4.6.</a>
Token Error Response<br />
<a href="#anchor9">4.7.</a>
UserInfo Request<br />
<a href="#anchor10">4.8.</a>
UserInfo Response<br />
<a href="#serializations">5.</a>
serializations<br />
<a href="#qss">5.1.</a>
Query String serialization<br />
<a href="#js">5.2.</a>
JSON Serialization<br />
<a href="#anchor12">5.3.</a>
Conversions of OpenID 2.0 encodings<br />
<a href="#sigs">6.</a>
Signatures<br />
<a href="#enc">7.</a>
Encryption<br />
<a href="#anchor16">8.</a>
Requests and Responses<br />
<a href="#anchor17">9.</a>
Verification<br />
<a href="#anchor18">9.1.</a>
Authorization Request Verification<br />
<a href="#anchor19">9.2.</a>
Authorization Response Verification<br />
<a href="#anchor20">9.3.</a>
UserInfo Request Verification<br />
<a href="#anchor21">9.4.</a>
UserInfo Response Verification<br />
<a href="#extensions">10.</a>
Extensions<br />
<a href="#security_considerations">11.</a>
Security Considerations<br />
<a href="#assertion_manufacture">11.1.</a>
Assertion manufacture/modification<br />
<a href="#assertion_disclosure">11.2.</a>
Assertion disclosure<br />
<a href="#assertion_repudiation">11.3.</a>
Assertion repudiation<br />
<a href="#assertion_redirect">11.4.</a>
Assertion redirect<br />
<a href="#assertion_reuse">11.5.</a>
Assertion reuse<br />
<a href="#artifact_manufacture">11.6.</a>
Secondary authenticator manufacture<br />
<a href="#artifact_capture">11.7.</a>
Secondary authenticator capture<br />
<a href="#assertion_substitution">11.8.</a>
Assertion substitution<br />
<a href="#auth_req_disclosure">11.9.</a>
Authentication Request Disclosure<br />
<a href="#anchor22">11.10.</a>
Timing Attack<br />
<a href="#authn_proc_threats">11.11.</a>
Authentication Process Threats<br />
<a href="#iana">12.</a>
IANA Considerations<br />
<a href="#oauth_params">12.1.</a>
OAuth Parameters Registry<br />
<a href="#anchor23">13.</a>
Open Issues and Things To Be Done (TBD)<br />
<a href="#anchor24">Appendix A.</a>
Acknowledgements<br />
<a href="#anchor25">Appendix B.</a>
Document History<br />
<a href="#rfc.references1">14.</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></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.
</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 Web Token<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>
<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"></a><h3>3.
Overview</h3>
<p>OpenID Connect protocol in abstract follows the following steps.
</p>
<p></p>
<ol class="text">
<li>The Client sends a request to the Server's End-User Authorization Endpoint.
</li>
<li>The Server authenticates the user and obtains appropriate authorization.
</li>
<li>The Server responds with access_token and a few other variables.
</li>
<li>The Client sends a request with the access_token to the Userinfo Endpoint.
</li>
<li>Userinfo Endpoint returns the additional user information supported by the Server.
</li>
</ol><p>Each message may be signed and encrypted. When the message is encrypted, it MUST be signed first then encrypted. This specification only defines the abstract messsage flow and message formats. The actual use MUST base on one of the companion protocol bindings specifications such as <a class='info' href='#OpenID.AB'>OpenID Connect Artifact Binding 1.0<span> (</span><span class='info'>Sakimura, N., Ed., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “OpenID Connect Artifact Binding 1.0,” January 2011.</span><span>)</span></a> [OpenID.AB] .
</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.4"></a><h3>4.
Messages</h3>
<p>
</p>
<p>In OpenID Connect protocols in abstract, the Client sends an Authorization Request to the Server at the End-User Authorization endpoint. The Server then authenticate the End-User to find out if he is eligible to make the authorization. Then, upon the authorization action of the End-User, the Server returns a response. The respose is either a positive response or error response. A positive response is either an Access Grant Response, which is an intermedially step, or the Access Token Response which includes <tt>access_token</tt>. The <tt>access_token</tt> MAY be used as a query parameter to obtain user information/assertion/claims about the user by sending a request to the userinfo endpoint. Both Request and Response may either be serialized into <a class='info' href='#qss'>Query String serialization<span> (</span><span class='info'>Query String serialization</span><span>)</span></a> or <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627].
</p>
<a name="rpf"></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.
Authorization Request</h3>
<p>Following is the list of variables to be sent as the top level keys:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>REQUIRED. The requested response: an access token, an authorization code, or both. The parameter value MUST be set to <tt>token</tt> for requesting an Access Token, <tt>code</tt> for requesting an Authorization Code, or <tt>code_and_token</tt> to request both. The Authorization Server MAY decline to provide one or more of these response types.
</dd>
<dt>client_id </dt>
<dd>REQUIRED. The client identifier recognized by the Authorization Server.
</dd>
<dt>redirect_uri</dt>
<dd>REQUIRED unless a redirection URI has been established between the client and authorization server via other means. An absolute URI to which the authorization server will redirect the user-agent to when the End-User authorization step is completed. The authorization server SHOULD require the client to pre-register their redirection URI.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. It MUST include <tt>openid</tt> as one of the string. [[ToDo: Maybe we do not need it, as openid param is required.]]
</dd>
<dt>state</dt>
<dd>OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.
</dd>
<dt>openid</dt>
<dd>REQUIRED. A JSON object that holds OpenID request variables.
</dd>
<dt>type</dt>
<dd>REQUIRED. Indicates the type of this JSON object. A URI <tt>http://openid.net/specs/cc/1.0#env</tt> .
</dd>
</dl></blockquote>
<p>Following is the list of <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0] variables are to be sent under the key <tt>"openid"</tt>:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>type</dt>
<dd>REQUIRED. A type identifier that identifies the message type. Set to <tt>"http://openid.net/specs/cc/1.0/#req"</tt>.
</dd>
<dt>immediate</dt>
<dd>OPTIONAL. indicates if the authorization server should display the authorization user interface. <tt>"True"</tt> if it should not display the user interface or <tt>"False"</tt> to display. Default is <tt>"False"</tt>.
</dd>
<dt>claimed_id</dt>
<dd>OPTIONAL. The claimed_id as in <a class='info' href='#OpenID.authentication-2.0'>OpenID 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0]
</dd>
<dt>identity</dt>
<dd>OPTIONAL. The local identifier as in <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0].
</dd>
<dt>realm</dt>
<dd>REQUIRED if PPID were used in previous authentications. URL pattern the OP SHOULD ask the end user to trust. See Section 9.2 of <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0].
</dd>
<dt>server_id</dt>
<dd>OPTIONAL. The intended recipient of this request.
</dd>
<dt>pubkey</dt>
<dd>OPTIONAL. The base64url encoded DER format X.509 certificate of the RP.
</dd>
<dt>atype</dt>
<dd>OPTIONAL. Type of assertion to be returned at the end. Values are one of the following:
<ul class="text">
<li>openid2json : (Default) OpenID Artifact Binding's default assertion format, which is JSON.
</li>
<li>openid2jsonp : openid2json wrapped in "openidjsonp();" so that it will be a JSONP format.
</li>
<li>openid2json+sig: openid2json assertion signed.
</li>
<li>openid2json+sig+enc: openid2json assertion signed and encrypted.
</li>
<li>saml2: SAML ver.2 assertion.
</li>
<li>wss : WS-Security assertion.
</li>
</ul>
</dd>
</dl></blockquote>
<p>These variables are sent from the client to the end-user authorization endpoint according to the protocol bindings of this specification. There are two serialization of the above variables: Query Parameters serialization and JSON serialization.
</p>
<p>Following is a non-normative example when they are sent in the query parameters serialization.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code
&openid.type=http%3A%2F%2Fopenid.net%2Fspecs%2Fcc%2F1.0%2F%23req
&client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com</pre></div>
<p>
</p>
<p>Following is a non-normative example when they are sent as a JSON object serialization.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"type": "http://openid.net/specs/cc/1.0#env,
"openid": {
"type": "http://openid.net/specs/cc/1.0#req",
"server_id": "http://example.com/op/",
"immediate": "true",
"claimed_id":"http://specs.openid.net/auth/2.0/identifier_select",
"identity": "http://specs.openid.net/auth/2.0/identifier_select",
"ns.ax": "http://openid.net/srv/ax/1.0",
"ax.mode": "fetch_request",
"ax.type.fname": "http://example.com/schema/fullname",
"ax.type.gender": "http://example.com/schema/gender",
"ax.required": "fname,gender"
},
"redirect_uri": "https://example.com/rp/endpoint_url",
"response_type":"code",
"client_id": "http://example.com/rp/",
"scope": "openid",
"state": "af0ifjsldkj"
}</pre></div>
<p>
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.
Access Grant Response</h3>
<p>If the End-User grants the access request, the Authorization Server issues an Access Token, an Authorization Code, or both, and delivers them to the Client by adding the following parameters to the redirection URI (as described below):
</p>
<p></p>
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED if the response type is either <tt>code</tt> or <tt>code_and_token</tt>, otherwise MUST NOT be included. The authorization code received from the authorization server.
</dd>
<dt>access_token</dt>
<dd>REQUIRED if the response type is <tt>token</tt> or <tt>code_and_token</tt>, otherwise MUST NOT be included. The Access Token issued by the Authorization Server.
</dd>
<dt>refresh_token</dt>
<dd>OPTIONAL. The Refresh Token used to obtain new Access Tokens using the same End-User authorization. The authorization server SHOULD NOT issue a Refresh Token when the access grant type is set to none.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The duration in seconds of the access token lifetime if an access token is included. For example, the value 3600 denotes that the access token will expire in one hour from the time the response was generated by the authorization server.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the access token as a list of space-delimited strings if an access token is included. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server SHOULD include the parameter if the requested scope is different from the one requested by the client.
</dd>
<dt>state</dt>
<dd>REQUIRED if the state parameter was present in the client authorization request. Set to the exact value received from the client.
</dd>
</dl></blockquote><p>The method in which the authorization server adds the parameter to the redirection URI is determined by the Response Type requested by the client in the authorization request using the <tt>response_type</tt> parameter.
</p>
<p>If the response type is <tt>code</tt>, the authorization server adds the parameters to the redirection URI query component using the <tt>application/x-www-form-urlencoded</tt> format as defined by <a class='info' href='#html401'>W3C.REC‑html401‑19991224<span> (</span><span class='info'>Ragget, D., “HTML 4.01 Specification,” December 1999.</span><span>)</span></a> [html401] .
</p>
<p>For example, the Authorization Server redirects the End-User's user-agent by sending the following HTTP response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=i1WsRn1uB1</pre></div>
<p>
</p>
<p>If the response type is <tt>token</tt> or <tt>code_and_token</tt> the Authorization Server adds the parameters to the redirection URI fragment component using the <tt>application/x-www-form-urlencoded</tt> format as defined by <a class='info' href='#html401'>W3C.REC‑html401‑19991224<span> (</span><span class='info'>Ragget, D., “HTML 4.01 Specification,” December 1999.</span><span>)</span></a> [html401] .
</p>
<p>For example, the authorization server redirects the end-user's user-agent by sending the following HTTP response (URI line breaks are for display purposes only):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: http://example.com/rd#access_token=FJQbwq9&
token_type=example&expires_in=3600</pre></div>
<p>
</p>
<p>Clients SHOULD ignore unrecognized response parameters. The sizes of tokens and other values received from the authorization server, are left undefined by this specification. Clients should avoid making assumptions about value sizes. Servers should document the expected size of any value they issue.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.
Access Grant Error Response</h3>
<p>If the end-user denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the redirection URI query component using the <tt>application/x-www-form-urlencoded</tt> format as defined by <a class='info' href='#html401'>W3C.REC‑html401‑19991224<span> (</span><span class='info'>Ragget, D., “HTML 4.01 Specification,” December 1999.</span><span>)</span></a> [html401]:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>error</dt>
<dd>REQUIRED. A single error code as described below.
</dd>
<dt>error_description</dt>
<dd>OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred.
</dd>
<dt>error_uri</dt>
<dd>OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the end-user with additional information about the error.
</dd>
<dt>state</dt>
<dd>REQUIRED if the state parameter was present in the client authorization request. Set to the exact value received from the client.
</dd>
</dl></blockquote>
<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.4.3.1"></a><h3>4.3.1.
Error Codes</h3>
<p>The Authorization Server includes one of the following error codes with the error response:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_request </dt>
<dd>The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
</dd>
<dt>invalid_client</dt>
<dd>The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type.
</dd>
<dt>unauthorized_client </dt>
<dd>The authenticated client is not authorized to use the access grant type provided.
</dd>
<dt>invalid_grant</dt>
<dd>The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI).
</dd>
<dt>unsupported_grant_type</dt>
<dd>The access grant included - its type or another attribute - is not supported by the authorization server.
</dd>
<dt>invalid_scope</dt>
<dd>The requested scope is invalid, unknown, malformed, or exceeds the previously granted scope.
</dd>
</dl></blockquote><p>The error codes can be extended by the string prefixed by <tt>x_</tt>. If custome error code are used, <tt>error_uri</tt> MUST be provided.
</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.4.4"></a><h3>4.4.
Access Token Request</h3>
<p>The client obtains an access token by authenticating with the authorization server and presenting its access grant (in the form of an authorization code, resource owner credentials, an assertion, or a refresh token).
</p>
<p>To make the Access Token Request, the Client sends the following parameters to the Token Endpoint:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>grant_type</dt>
<dd>REQUIRED. The access grant type included in the request. Value MUST be one of <tt>authorization_code</tt>, <tt>refresh_token</tt>, or an absolute URI identifying an assertion format supported by the authorization server.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. If the access grant being used already represents an approved scope (e.g. authorization code, assertion), the requested scope MUST be equal or lesser than the scope previously granted, and if omitted is treated as equal to the previously approved scope.
</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>In addition, the client MUST include the appropriate parameters specified in the bindings used.
</p>
<a name="atr"></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.
Access Token Response</h3>
<p>After receiving and verifying a valid and authorized access token request from the client, the Authorization Server returns a Positive Assertion that includes an Access Token.
</p>
<p>The token response contains the following parameters which are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED if the response type is <tt>token</tt> or <tt>code_and_token</tt>, otherwise MUST NOT be included. The Access Token issued by the Authorization Server.
</dd>
<dt>refresh_token</dt>
<dd>OPTIONAL. The Refresh Token used to obtain new Access Tokens using the same End-User authorization. The authorization server SHOULD NOT issue a Refresh Token when the access grant type is set to none.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The duration in seconds of the access token lifetime if an access token is included. For example, the value 3600 denotes that the access token will expire in one hour from the time the response was generated by the authorization server.
</dd>
<dt>scope</dt>
<dd>OPTIONAL. The scope of the access token as a list of space-delimited strings. The value of the scope parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server SHOULD include the parameter if the requested scope is different from the one requested by the client.
</dd>
<dt>openid</dt>
<dd>REQUIRED if it was requested in the request.
</dd>
</dl></blockquote>
<p>It MAY include any other extension parameters.
</p>
<p>The key <tt>"openid"</tt> has sub-keys including the following:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>type</dt>
<dd>REQUIRED. A type identifier that identifies the message type. Set to <tt>"http://openid.net/specs/cc/1.0#id_res"</tt>.
</dd>
<dt>user_id</dt>
<dd>REQUIRED. A locally unique and never reassigned identifier for the user, which is intended to be consumed by the Client. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length.
</dd>
<dt>domain</dt>
<dd>REQUIRED. The domain of the authorization server such that when paired with the user_id creates a globally unique and never reassigned identifier. e.g. "facebook.com", "google.com", or "recordon.com".
</dd>
<dt>access_tokens</dt>
<dd>OPTIONAL. An array of JSON objects that has "endpoint", "access_token", "user_id" and "expires_in" as its subkey.
</dd>
<dt>claimed_id</dt>
<dd>OPTIONAL. The OpenID 2.0 verified identifier of this user, if the user has OpenID 2.0 account.
</dd>
<dt>identity</dt>
<dd>OPTIONAL. The OpenID 2.0 Local ID that this user was verified against, if the user has OpenID 2.0 account.
</dd>
<dt>server_id</dt>
<dd>REQUIRED. The unique identifier of the authorization server such that when paired with the user_id creates a globally unique and never reassigned identifier.
</dd>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier recognized by the authorization server.
</dd>
<dt>issued_at</dt>
<dd>REQUIRED. A unix timestamp of when this assertion was created.
</dd>
<dt>op_endpoint</dt>
<dd>OPTIONAL. The OP Endpoint URL.
</dd>
</dl></blockquote><p>The key <tt>"openid"</tt> MAY have any other <a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.authentication‑2.0] key-value form encoding encoded in JSON.
</p>
<p>The key <tt>"access_tokens" </tt>holds an array of JSON object composed of the following parameters.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>endpoint</dt>
<dd>REQUIRED. Resource Endpoint URL to which the token is used to access.
</dd>
<dt>access_token</dt>
<dd>REQUIRED. Access token used to access the resource. [Alternatively: An array of JSON objects that has "user_id", "expires_in" and other variables that the resource requires, which is encoded into Encrypted JWT.]
</dd>
<dt>user_id</dt>
<dd>OPTIONAL. The End-User's identifier for the Resource Endpoint. [ToDo. We should not need it. In fact, we had better not have it. It should be encoded into the Encrypted JWT access_token. This is here only for the case where access_token is not JWT.]
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The duration in seconds of the access token lifetime if an access token is included. For example, the value 3600 denotes that the access token will expire in one hour from the time the response was generated by the authorization server.
</dd>
<dt>token_type</dt>
<dd>OPTIONAL. "plain", "jwt", or a fully qualified type URI of the token's type. Defaults to "plain".
</dd>
</dl></blockquote>
<p>Following is a non-normative example.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"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": "af0skdjffarosjf2dkfj.a0tkdjskw23s03f8fs2fjs.afhjlwsdf",
"token_type": "jwt",
"expires_in": 3600
},
{
"endpoint": "https://ds2.example.com/cal",
"access_token": "Z9fl3i",
"user_id": "P8fhs",
"expires_in": 3600
}
]
}
}</pre></div>
<p>
</p>
<p>Clients SHOULD ignore unrecognized response parameters. The sizes of tokens and other values received from the authorization server, are left undefined by this specification. Clients should avoid making assumptions about value sizes. Servers should document the expected size of any value they issue.
</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.4.6"></a><h3>4.6.
Token Error Response</h3>
<p>If the assertion request is invalid or unauthorized, the authorization server constructs the response by adding the following parameter to the entity body of the HTTP response using the "application/json" media type:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>error</dt>
<dd>REQUIRED. A single error code as described below.
</dd>
<dt>error_description</dt>
<dd>OPTIONAL. A human-readable text providing additional information, used to assist in the understanding and resolution of the error occurred.
</dd>
<dt>error_uri</dt>
<dd>OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the end-user with additional information about the error.
</dd>
</dl></blockquote>
<p>
</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.4.6.1"></a><h3>4.6.1.
Error Codes</h3>
<p>The Authorization Server includes one of the following error codes with the error response:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_request </dt>
<dd>The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
</dd>
<dt>invalid_client</dt>
<dd>The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type.
</dd>
<dt>unauthorized_client </dt>
<dd>The authenticated client is not authorized to use the access grant type provided.
</dd>
<dt>invalid_grant</dt>
<dd>The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI).
</dd>
<dt>unsupported_grant_type</dt>
<dd>The access grant included - its type or another attribute - is not supported by the authorization server.
</dd>
<dt>invalid_scope</dt>
<dd>The requested scope is invalid, unknown, malformed, or exceeds the previously granted scope.
</dd>
</dl></blockquote><p>The error codes can be extended by the string prefixed by <tt>x_</tt>. If custome error code are used, <tt>error_uri</tt> MUST be provided.
</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.4.7"></a><h3>4.7.
UserInfo Request</h3>
<p>Client MAY send request with following parameters to the UserInfo Endpoint to obtain further information about the user.
</p>
<p>[[TBD: How to ask the attributes the Client is requesting?]]
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The access_token obtained above.
</dd>
<dt>user_id</dt>
<dd>OPTIONAL. A locally unique and never reassigned identifier for the user. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. [ToDo: We probably do not need it. Actually, for the sake of privacy, the RP SHOULD NOT have it. Instead, it should be encoded into the access_token. ]
</dd>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier recognized by the authorization server.
</dd>
</dl></blockquote>
<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.8"></a><h3>4.8.
UserInfo Response</h3>
<p>The response is a JSON object which contains some (or all) of the following reserved keys:
</p>
<p>[[TBD: How to return the additional attributes like PoCo?]]
</p>
<p></p>
<blockquote class="text"><dl>
<dt>user_id</dt>
<dd>REQUIRED. A locally unique and never reassigned identifier for the user. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length.
</dd>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier recognized by the authorization server.
</dd>
<dt>asserted_user</dt>
<dd>REQUIRED. One of "true" if the access was issued for this user or "false" if it is for a different user.
</dd>
<dt>profile_urls</dt>
<dd>OPTIONAL. An array of URLs that belong to the user across any number of domains.
</dd>
<dt>display_name</dt>
<dd>OPTIONAL. The display name of the user. e.g., "David Recordon".
</dd>
<dt>given_name</dt>
<dd>OPTIONAL. The first name of the user. e.g., "David".
</dd>
<dt>family_name</dt>
<dd>OPTIONAL. The family name of the user. e.g., "Recordon".
</dd>
<dt>email</dt>
<dd>OPTIONAL. The verified email address of the user. e.g., "recordond@gmail.com".
</dd>
<dt>language</dt>
<dd>OPTIONAL. End User's preferred language as specified by ISO639.
</dd>
<dt>picture</dt>
<dd>OPTIONAL. The URL of End User's Picture. e.g., "http://graph.facebook.com/davidrecordon/picture".
</dd>
</dl></blockquote>
<p>
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.8.1"></a><h3>4.8.1.
UserInfo Error Response</h3>
<p>(TBD)
</p>
<a name="serializations"></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.
serializations</h3>
<p>Each message can be serialized either in query parameter serialization or JSON serialization unless it was explicitly stated in the previous sections.
</p>
<a name="qss"></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.
Query String serialization</h3>
<p>In order to serialize the parameters into Query String Serialization, the client constructs the string by adding the following parameters to the end-user authorization endpoint URI query component using the <tt>application/x-www-form-urlencoded</tt> format as defined by <a class='info' href='#html401'>HTML 4.01 Specification<span> (</span><span class='info'>Ragget, D., “HTML 4.01 Specification,” December 1999.</span><span>)</span></a> [html401]:
</p>
<p>Following is a non-normative example of such Serialization.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code&openid.type=http%3A%2F%2Fopenid.net%2Fspecs%2Fcc%2F1.0%2F%23req&
client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HT
TP/1.1
Host: server.example.com</pre></div>
<a name="js"></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.2"></a><h3>5.2.
JSON Serialization</h3>
<p>The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. Each parameter may have JSON Structure as its value.
</p>
<p>Following is a non-normative example of such Serialization.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"access_token":"SlAV32hkKG",
"expires_in":3600,
"refresh_token":"8xLOxBtZp8",
"openid": {
"type": "http://openid.net/specs/ab/1.0#id_res",
"mode": "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
}
}</pre></div>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.
Conversions of OpenID 2.0 encodings</h3>
<p>The two encoding form used in <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a>, "HTTP encoding" and "key-value form encoding" can be converted to the OpenID Connect JSON form as follows:
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3.1"></a><h3>5.3.1.
key-value form encoding Conversion</h3>
<p>Section 4.1.1 of <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> defines key-value form encoding. Each line begins with a key, followed by a colon, and the value associated with the key. The line is terminated by a single newline (UCS codepoint 10, "\n"). A key or value MUST NOT contain a newline and a key also MUST NOT contain a colon.
</p>
<p>This encoding can be trivially converted to JSON objects by making the key the JSON key and the value the JSON value. The resulting JSON object is stored as the value of the top-level key "openid".
</p>
<p>For example, the key-value form encoding
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>mode:error
error:This is an example message
</pre></div>
<p>is converted to a OpenID JSON Encoding as
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"openid": {
"mode": "error",
"error": "This is an example message"
}
}</pre></div>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3.2"></a><h3>5.3.2.
HTTP encoding Conversion</h3>
<p>In <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a>, OpenID query parameters are prefixed by "openid." : e.g., openid.sreg.fname and openid.pape.level. They can be translated into a JSON object by listing all the query parameters under the key "openid". Subkeys are constructed by removing "openid." prefix from each parameters. For values, strings are converted to JSON String and num
</p>
<p>For example, a query string openid.sreg.fname=Nat&openid.pape.level=1 are converted to JSON as follows:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"openid":{
"sreg.fname":"Nat",
"pape.level":1
}
}</pre></div>
<p>
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3.3"></a><h3>5.3.3.
Additional Constraint</h3>
<p>To simplify the implementations, the following practice is strongly RECOMMENDED.
</p>
<p></p>
<ul class="text">
<li>For the support of the <a class='info' href='#PAPE1.0'>[PAPE1.0]<span> (</span><span class='info'>Recordon, D., Jones, M., Bufu, J., Ed., Daughty, J., and N. Sakimura, “OpenID Provider Authentication Property Extension 1.0,” December 2008.</span><span>)</span></a>, use "pape" as the prefix.
</li>
<li>For the support of the <a class='info' href='#AX1.0'>[AX1.0]<span> (</span><span class='info'>Hardt, D., Bufu, J., and J. Hoyt, “OpenID Attribute Exchange 1.0,” December 2007.</span><span>)</span></a>, use "ax" as the prefix.
</li>
<li>For the support of the SREG1.1, use "sreg" as the prefix.
</li>
</ul>
<a name="sigs"></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.
Signatures</h3>
<p>Depending on the transport through wich the messages are transported, the integrity of the message may not be guaranteed, nor the originator of the message is not authenticated. To mitigate these risks, OpenID Connect supports <a class='info' href='#jwt'>JSON Web Token(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].
</p>
<p>Following is the parameters for JWT.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>typ</dt>
<dd>OPTIONAL. One of <tt>"JWT"</tt>, <tt>"openid2json+sig"</tt>.
</dd>
<dt>alg</dt>
<dd>REQUIRED. One of the algorithm specified in Table 4 of <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]
</dd>
</dl></blockquote><p>Compact Serialization SHOULD BE used when passing it through query parameters, while JSON serialization SHOULD BE used when returning it in HTTP Body.
</p>
<p>Following is a non-normative example of such signature in Compact serialization, where HS256 algorithm was used (with line breaks for display purposes only):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk</pre></div>
<p>
</p>
<p>Following is a non-normative example of such signature in JSON serialization, where ES256 algorithm was used.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"header": [
"eyJhbGciOiJFUzI1NiJ9"
],
"payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"signature": [
"DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
]
}</pre></div>
<p>
</p>
<a name="enc"></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.
Encryption</h3>
<p>To achieve message confidentiality and audience restriction, OpenID Connect uses <a class='info' href='#json_enc'>JSON Simple Encryption<span> (</span><span class='info'>Bradeley, J. and N. Sakimura, “JSON Simple Encryption,” September 2010.</span><span>)</span></a> [json_enc].
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Requests and Responses</h3>
<p>Requests and Responses can either be plain or signed. Signature should be applied to the entire request or response. Signed request and responses in the query are sent in the parameter "signed". If the request and responses are in the JSON Serialization, the JWT signed version MUST use the JSON serialization.
</p>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
Verification</h3>
<p>
</p>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1.
Authorization Request Verification</h3>
<p>If the request was signed, the Server MUST verify the signature as in JWT.
</p>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.2"></a><h3>9.2.
Authorization Response Verification</h3>
<p>To verify the validity of the Authorization Response, the client MUST to the following:
</p>
<p></p>
<ol class="text">
<li>If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
</li>
<li>Check that OP that it connected was really the intended OP through TLS/SSL server certificate check if the endpoint is TLS/SSL endpoint.
</li>
<li>Check if "type" is "http://openid.net/specs/cc/1.0/#id_res".
</li>
<li>Verify that the "domain" matches the domain including sub-domain of the server's token endpoint URI.
</li>
<li>Check if the current time is after "issued_at" and before "issued_at" + "expires_in".
</li>
<li>If the claimed_id field is present, the client MUST verify that the user info endpoint is authoritative to issue assertions about it. This is done by performing OpenID 2.0 discovery on the URL and finding a <xrd:Service> element with the following information:
<ul class="text">
<li><xrd:Type> - whose text content is "http://openid.net/specs/cc/1.0/".
</li>
<li><xrd:URI> - whose text content is the URL of this user info endpoint.
</li>
</ul>
</li>
<li>If this tag is not found via OpenID 2.0 discovery or if the URI does not match, the client MUST ignore the presence of the <tt>claimed_id</tt> parameter.
</li>
</ol><p>Note: An authorization server MUST only issue assertions about user identifiers on its domain. The authorization server is responsible for managing its own local namespace and enforcing that each user_id is locally unique and never reassigned.
</p>
<p>If the client does not verify the signature, it MUST make a User Info API request.
</p>
<a name="anchor20"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.3"></a><h3>9.3.
UserInfo Request Verification</h3>
<p>If the request was signed, the Server MUST verify the signature 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> [jwt].
</p>
<a name="anchor21"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.4"></a><h3>9.4.
UserInfo Response Verification</h3>
<p>To verify the validity of the UserInfo Response, the client MUST to the following:
</p>
<p></p>
<ol class="text">
<li>If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
</li>
<li>Check that OP that it connected was really the intended OP through TLS/SSL server certificate check if the endpoint is TLS/SSL endpoint.
</li>
<li>Check if the current time is after "issued_at" and before "issued_at" + "expires_in".
</li>
</ol>
<p>
</p>
<a name="extensions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
Extensions</h3>
<p>OpenID Connect supports the extensions that are as defined in Section 12 of <a class='info' href='#OpenID.authentication-2.0'>[OpenID.authentication‑2.0]<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> . This specification adds following list to the disallowed aliases.
</p>
<p>request_uri, refresh_uri, op_endpoint, user_id, redirect_uri, client_id, server_id, client_meta_uri, server_meta_uri, client_secret, immediate, pubkey, certs_uri, state, code, atype, proofkey, enc_data, enc_key, enc_iv, enc_type, enc_ref, access_token, access_token_secret, issued_at, expires_in, refresh_token.
</p>
<p>
</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.11"></a><h3>11.
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.11.1"></a><h3>11.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.11.2"></a><h3>11.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.11.3"></a><h3>11.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.11.4"></a><h3>11.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.11.5"></a><h3>11.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.11.6"></a><h3>11.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.11.7"></a><h3>11.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.11.8"></a><h3>11.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.11.9"></a><h3>11.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="anchor22"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.10"></a><h3>11.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.11.11"></a><h3>11.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.12"></a><h3>12.
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.12.1"></a><h3>12.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 <tt>WWW-Authenticate</tt> header field.
</p>
<p>Change controller: IETF
</p>
<p>Specification document(s): [[ this document ]]
</p>
<p>Related information: None
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.
Open Issues and Things To Be Done (TBD)</h3>
<p>[[To be removed from the final specification.]]
</p>
<p>Following items remains to be done in this draft.
</p>
<p></p>
<ol class="text">
<li>Check that all the "protocols" has been abstracted and "messages" are protocol independent.
</li>
<li>IANA registration issue while OAuth registry is not up yet.
</li>
<li>Clean Up and add references.
</li>
<li>Update JWT related items when new version of JWT/JSON Signature comes up in the week of Jan. 10.
</li>
<li>Finish the security consideration section.
</li>
<li>Better to list the authors in the header than acknowledgement?
</li>
<li>Properly capitalize the Defined Words.
</li>
<li>Better to split the Authentication and Authorization server? (Model-wise, yes, but it gets complicated. Current model is implicitly assuming that the Authentication and Authorization server are operated by the same entity and the protocol between them are proprietary.)
</li>
</ol>
<a name="anchor24"></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>This specification is largely compliant with OAuth 2.0 draft 11. As the draft is not yet referenceable, relevant text has been incorporated into this draft. Please refer to the OAuth 2.0 specification for the list of contributors.
</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>
<p></p>
<blockquote class="text">
<p>Breno de Medeiros (breno@gmail.com), Google.
</p>
<p>David Recordon (dr@fb.com)<author>, Facebook.
</p>
<p>Hideki Nara (hideki.nara@gmail.com), Takt Communications.
</p>
<p>John Bradley (jbradely@mac.com) <author>, Protiviti Government Service.
</p>
<p>Mike Jones (Michael.Jones@microsoft.com), Microsoft.
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp) <author/editor>, Nomura Research Institute, Ltd.
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan.
</p>
</blockquote>
<a name="anchor25"></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.
Document History</h3>
<p></p>
<blockquote class="text"><dl>
<dt>-00</dt>
<dd>First Draft that incorporates the core of both openidonnect.com proposal and OpenID Artifact Binding RC3 and abstracted.
</dd>
</dl></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>14. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="AX1.0">[AX1.0]</a></td>
<td class="author-text">Hardt, D., Bufu, J., and J. Hoyt, “<a href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID Attribute Exchange 1.0</a>,” December 2007.</td></tr>
<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.AB">[OpenID.AB]</a></td>
<td class="author-text">Sakimura, N., Ed., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “<a href="http://openid.net/specs/ab/1.0/">OpenID Connect Artifact Binding 1.0</a>,” January 2011.</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="PAPE1.0">[PAPE1.0]</a></td>
<td class="author-text">Recordon, D., Jones, M., Bufu, J., Ed., Daughty, J., and N. Sakimura, “<a href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID Provider Authentication Property Extension 1.0</a>,” December 2008.</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="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,” RFC 5246, August 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5246.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="SREG1.0">[SREG1.0]</a></td>
<td class="author-text">Hoyt, J., Hoyt, J., and D. Recordon, “<a href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID Simple Registration Extension 1.0</a>,” December 2007.</td></tr>
<tr><td class="author-text" valign="top"><a name="html401">[html401]</a></td>
<td class="author-text">Ragget, D., “<a href="http://www.w3.org/TR/html401/">HTML 4.01 Specification</a>,” December 1999.</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">David Recordon</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Facebook Inc.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:dr@fb.com">dr@fb.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<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">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>