<!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 Messages 1.0 - draft 01</title>
<meta http-equiv="Expires" content="Fri, 05 Aug 2011 21:32:26 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Messages 1.0 - draft 01">
<meta name="generator" content="xml2rfc v1.34 (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">D. Recordon</td></tr>
<tr><td class="header"> </td><td class="header">Facebook</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Protiviti</td></tr>
<tr><td class="header"> </td><td class="header">B. de Medeiros</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">E. Jay</td></tr>
<tr><td class="header"> </td><td class="header">MGI1</td></tr>
<tr><td class="header"> </td><td class="header">August 2, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Messages 1.0 - draft 01</h1>
<h3>Abstract</h3>
<p>OpenID Connect is an identity framework that provides authentication,
authorization, and attribute transmission capability. It allows third
party attested claims from distributed sources. The specification suite
builds on OAuth 2.0 and consists of Building Blocks (Messages,
Discovery, Dynamic Client Registration, Session Management, JSON Web
Token, JSON Web Signature, JSON WEB Encryption, JSON Web Keys, Simple
Web Discovery), Protocol Bindings (e.g., Standard and Lite) and
Extensions. This specification covers the core "Messages" 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>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<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="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#terminology">1.</a>
Terminology<br />
<a href="#anchor1">2.</a>
Overview<br />
<a href="#anchor2">3.</a>
Messages<br />
<a href="#anchor3">3.1.</a>
Authorization Endpoint<br />
<a href="#auth_req">3.1.1.</a>
Authorization Request<br />
<a href="#anchor6">3.1.2.</a>
Authorization Response<br />
<a href="#anchor7">3.1.3.</a>
Authorization Error Response<br />
<a href="#anchor9">3.2.</a>
Token Endpoint<br />
<a href="#access_token_request">3.2.1.</a>
Access Token Request<br />
<a href="#access_token_response">3.2.2.</a>
Access Token Response<br />
<a href="#anchor10">3.2.3.</a>
Token Error Response<br />
<a href="#anchor12">3.3.</a>
UserInfo Endpoint<br />
<a href="#anchor13">3.3.1.</a>
Requests<br />
<a href="#anchor14">3.3.2.</a>
Responses<br />
<a href="#anchor16">3.3.3.</a>
Errors<br />
<a href="#anchor17">3.3.4.</a>
Claim Types<br />
<a href="#anchor20">3.4.</a>
Introspection Endpoint<br />
<a href="#anchor21">3.4.1.</a>
Introspection Request<br />
<a href="#anchor22">3.4.2.</a>
Introspection Response<br />
<a href="#anchor23">3.4.3.</a>
Error Codes<br />
<a href="#verification">3.4.4.</a>
Verification<br />
<a href="#anchor26">3.5.</a>
Session Management Endpoints<br />
<a href="#Serializations">4.</a>
Serializations<br />
<a href="#qss">4.1.</a>
Query String Serialization<br />
<a href="#js">4.2.</a>
JSON Serialization<br />
<a href="#sigs">5.</a>
Signatures and Encryption<br />
<a href="#anchor27">6.</a>
Verification<br />
<a href="#anchor28">6.1.</a>
Authorization Request Verification<br />
<a href="#anchor29">6.2.</a>
Authorization Response Verification<br />
<a href="#anchor30">6.3.</a>
UserInfo Request Verification<br />
<a href="#anchor31">6.4.</a>
UserInfo Response Verification<br />
<a href="#extensions">7.</a>
Extensions<br />
<a href="#related">8.</a>
Related Specifications<br />
<a href="#security_considerations">9.</a>
Security Considerations<br />
<a href="#assertion_manufacture">9.1.</a>
Assertion Manufacture/Modification<br />
<a href="#assertion_disclosure">9.2.</a>
Assertion Disclosure<br />
<a href="#assertion_repudiation">9.3.</a>
Assertion Repudiation<br />
<a href="#assertion_redirect">9.4.</a>
Assertion Redirect<br />
<a href="#assertion_reuse">9.5.</a>
Assertion Reuse<br />
<a href="#artifact_manufacture">9.6.</a>
Secondary Authenticator Manufacture<br />
<a href="#artifact_capture">9.7.</a>
Secondary Authenticator Capture<br />
<a href="#assertion_substitution">9.8.</a>
Assertion Substitution<br />
<a href="#auth_req_disclosure">9.9.</a>
Authentication Request Disclosure<br />
<a href="#anchor32">9.10.</a>
Timing Attack<br />
<a href="#authn_proc_threats">9.11.</a>
Authentication Process Threats<br />
<a href="#iana">10.</a>
IANA Considerations<br />
<a href="#oauth_params">10.1.</a>
OAuth Parameters Registry<br />
<a href="#anchor33">10.1.1.</a>
Scope Parameters<br />
<a href="#anchor34">10.1.2.</a>
Authorization Request Parameters<br />
<a href="#anchor35">10.1.3.</a>
Access Token Response Parameters<br />
<a href="#anchor36">11.</a>
Open Issues and Things To Be Done (TBD)<br />
<a href="#rfc.references1">12.</a>
References<br />
<a href="#rfc.references1">12.1.</a>
Normative References<br />
<a href="#rfc.references2">12.2.</a>
Informative References<br />
<a href="#anchor39">Appendix A.</a>
Acknowledgements<br />
<a href="#anchor40">Appendix B.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<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.1"></a><h3>1.
Terminology</h3>
<p>In addition to the terms "Access Token", "Refresh Token",
"Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server", and
"Token Endpoint" that are defined by <a class='info' href='#OAuth.2.0'>OAuth
2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], this specification defines the following terms: </p>
<blockquote class="text"><dl>
<dt>Assertion</dt>
<dd>A set of Claims about the End-User that are
attested to by the OpenID Provider and Resource Servers.
</dd>
<dt>Authentication</dt>
<dd>An act of verifying End-User's identity
through the verification of the credential.
</dd>
<dt>Claim</dt>
<dd>A piece of information about an Entity that a
Claims Provider asserts about that Entity.
</dd>
<dt>Claims Provider</dt>
<dd>An Authorization Server that can
return claims about a user.
</dd>
<dt>End-User</dt>
<dd>A human resource owner.
</dd>
<dt>Entity</dt>
<dd>Something that has separate and distinct
existence and that can be identified in context.
</dd>
<dt>ID Token</dt>
<dd>An opaque token that contains information
about the authentication event.
</dd>
<dt>OpenID Provider (OP)</dt>
<dd>A service capable of providing
identity information to a Relying Party.
</dd>
<dt>OP Endpoints</dt>
<dd>End-User Authentication Endpoint,
Authorization Endpoint, and Token Endpoint.
</dd>
<dt>OpenID Request Object</dt>
<dd>A JSON object that holds the
request variables. It holds OpenID request variables. It MAY also
contain other OAuth parameters for the request signing purpose, in
which case the parameter values MUST match with the OAuth request
parameters.
</dd>
<dt>Relying Party (RP)</dt>
<dd>An application requiring identity
information from an OpenID Provider.
</dd>
<dt>RP Endpoint</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 an access token by the client, returns authorized
information about the user represented by that access token.
</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.2"></a><h3>2.
Overview</h3>
<p>The 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, id_token, and a few other
variables.
</li>
<li>The Client sends a request with the access_token to the UserInfo
endpoint <a class='info' href='#OpenID.UserInfo'>OpenID Connect UserInfo
1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, “OpenID Connect UserInfo 1.0,” July 2011.</span><span>)</span></a> [OpenID.UserInfo].
</li>
<li>UserInfo endpoint returns the additional user information
supported by the Server.
</li>
<li>The Client sends a request with the id_token to the Server's
token introspection endpoint.
</li>
<li>The token instrospection endpoint responds with authentication
information pertaining to the supplied id_token.
</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 message flow and message formats. The actual
use MUST be based on one of the companion protocol bindings
specifications such as <a class='info' href='#OpenID.Lite'>OpenID Connect
Lite<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Lite 1.0,” August 2011.</span><span>)</span></a> [OpenID.Lite] or <a class='info' href='#OpenID.Standard'>OpenID Connect
Standard<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” August 2011.</span><span>)</span></a> [OpenID.Standard].
</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.3"></a><h3>3.
Messages</h3>
<p>In OpenID Connect protocols, in abstract, the process proceeds by the
client interacting with endpoints. There are a number of endpoints
involved.
</p>
<p></p>
<ol class="text">
<li>Authorization Endpoint: The Client sends a request to the Server
at the authorization endpoint. The Server then authenticates 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 an Authorization Response that includes Authorization Code,
<tt>code</tt>. For some Clients, Implicit Grant
may be used to obtain <tt>access_token</tt>
without using <tt>code</tt>. In this case, <tt>response_type</tt> MUST be set to <tt>token</tt>.
</li>
<li>Token Endpoint: The Client sends the access token request to the
token endpoint to obtain Access Token Response which includes an
<tt>access_token</tt>.
</li>
<li>UserInfo Endpoint: The <tt>access_token</tt>
MAY be sent to the UserInfo endpoint to obtain claims about the
user.
</li>
<li>Token Introspection Endpoint: An id_token MAY be sent to the
Token Introspection endpoint to obtain information about the
authenticationevent.
</li>
<li>Session Management Endpoints: The ID Token MAY be sent to these
endpoints to manage the session.
</li>
</ol><p>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="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.1"></a><h3>3.1.
Authorization Endpoint</h3>
<p>The client sends an Authorization Request to the authorization
endpoint to obtain an Authorization Response and an ID Token. The ID
Token is an opaque token identifier which is used to obtain pertinent
information related to the authentication event at the Token
Introspection endpont.
</p>
<p>
</p>
<a name="auth_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.1.1"></a><h3>3.1.1.
Authorization Request</h3>
<p>Section 4.1.1 and 4.2.1 of <a class='info' href='#OAuth.2.0'>OAuth
2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0] defines the OAuth Authorization Request parameters. In
this specification, the values to the parameters are defined as
follows.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>A space delimited, case sensitive
list of string values. Acceptable values include <tt>code</tt>, <tt>token</tt>,
and <tt>none</tt>. The value MUST include
<tt>code</tt> for requesting an Authorization
Code, <tt>token</tt> for requesting an Access
Token, and <tt>none</tt> if no response is
needed.
</dd>
<dt>scope</dt>
<dd>A space delimited, case sensitive list of
string values. The values specify an additive list of claims
that are returned by the UserInfo endpoint. The following values
are defined :
<blockquote class="text"><dl>
<dt>openid</dt>
<dd>REQUIRED. This requests that the ID
Token associated with the authentication session be
returned. If the <tt>response_type</tt>
includes <tt>token</tt>, the ID Token is
returned in the authorization response along with the Access
Token. If the <tt>respone_type</tt>
includes <tt>code</tt>, the ID Token is
returned as part of the Token endpoint response.
</dd>
<dt>profile</dt>
<dd>OPTIONAL. This requests that access to
the user's <a class='info' href='#ClaimTable'>profile claims<span> (</span><span class='info'>Reserved Member Definitions</span><span>)</span></a>
excluding the <tt>address</tt> and <tt>email</tt> claims at the UserInfo endpoint
be granted by the issued Access Token.
</dd>
<dt>address</dt>
<dd>OPTIONAL. This requests that access to
the <tt>address</tt> claim at the
UserInfo endpoint be granted by the issued Access Token.
</dd>
<dt>email</dt>
<dd>OPTIONAL. This requests that access to
the <tt>email</tt> claim claim at the
UserInfo endpoint be granted by the issued Access Token.
</dd>
<dt>PPID</dt>
<dd>OPTIONAL. This requests that the <tt>id</tt> claim returned by the UserInfo
endpoint and the <tt>user_id</tt> claim
returned by the Token Introspection endpoint be a Pairwise
Pseudonymouse Identifier (PPID).
</dd>
</dl></blockquote>
</dd>
</dl></blockquote>
<p>Other required OAuth 2.0 parameters in the request include:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>The client identifier.
</dd>
<dt>redirect_uri</dt>
<dd>A redirection URI where the response
will be sent.
</dd>
</dl></blockquote>
<p>The following extension parameters are also defined:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>display</dt>
<dd>OPTIONAL. A string value that specifies
how the authorization server displays the authentication page to
the user.
<blockquote class="text"><dl>
<dt>none</dt>
<dd>The authorization server MUST NOT display
any authentication page.
</dd>
<dt>popup</dt>
<dd>The authorization server displays a
popup authentication page.
</dd>
<dt>mobile</dt>
<dd>The authorization server performs
authentication using a mobile device???
</dd>
</dl></blockquote>
</dd>
<dt>prompt</dt>
<dd>OPTIONAL. A space delimited, case sensitive
list of string values that specifies how the authorization
server prompts the user for reauthentication and reapproval. The
possible values are:
<blockquote class="text"><dl>
<dt>login</dt>
<dd>The authorization server MUST prompt the
user for reauthentication.
</dd>
<dt>consent</dt>
<dd>The authorization server MUST prompt
the user for reapproval before returning information to the
client.
</dd>
<dt>select_account</dt>
<dd>The authorization server MUST
prompt the user to select a user account if the current
account does not match the account in the request.
</dd>
</dl></blockquote>
</dd>
<dt>nonce</dt>
<dd>OPTIONAL. A random, unique string value used
to mitigate the replay attack.
</dd>
<dt>audience</dt>
<dd>OPTIONAL. The target audience identifier
for the ID Token.
</dd>
<dt>request</dt>
<dd>OPTIONAL. A <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT]
encoded <a class='info' href='#OpenIDReq'>OpenID Request
Object<span> (</span><span class='info'>OpenID Request Object</span><span>)</span></a>.
</dd>
<dt>request_uri</dt>
<dd>OPTIONAL. A URL that points to an
OpenID Request Object.
</dd>
</dl></blockquote>
<p>The request MAY contain the following optional parameters:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>state</dt>
<dd>An opaque value used to maintain state
between the request and the callback.
</dd>
</dl></blockquote>
<p>Following is a non-normative example of a request using
query parameters serialization:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&request=jwt_header.jwt_part2.jwt_part3 HTTP/1.1
Host: server.example.com</pre></div>
<a name="OpenIDReq"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.1.1"></a><h3>3.1.1.1.
OpenID Request Object</h3>
<p>The OpenID Request object is used to provide OpenID request
parameters that MAY differ from the default ones. Implementing
support for the OpenID Request object is OPTIONAL. Supporting it
is necessary for implementations that need to request or provide
sets of claims other than the default <a class='info' href='#OpenID.UserInfo'>UserInfo<span> (</span><span class='info'>Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, “OpenID Connect UserInfo 1.0,” July 2011.</span><span>)</span></a> [OpenID.UserInfo] and Token Introspection
claim sets.
</p>
<p>If present, the OpenID Request object is passed as the value of
a <tt>request</tt> OAuth 2.0 parameter and is
represented as a <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT]. Parameters that
affect the information returned from the UserInfo endpoint are in
the "userinfo" member. Parameters that affect the information
returned from the Token Introspection endpoint are in the
"id_token" member. If the same parameters are available both as
query strings and in the OpenID Request Object, the later takes
the precedence.
</p>
<p>
<p>An example an OpenID request object is as
follows:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"userinfo":
{
"claims":
{
"name": null,
"nickname": {"optional": true},
"email": null,
"verified": null,
"picture": {"optional": true},
},
"format": "signed"
}
"id_token":
{
"claims":
{
"auth_time": null
}
"max_age": 86400,
"iso29115": "2"
}
}</pre></div>
<p>The OpenID Request object is a <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT]
that MAY contain a set of members defined by this specification
and MAY contain other members that are not defined by this
specification. The JWT MAY be signed or unsigned. When it is
unsigned, it will be indicated by the JWT <tt>"signed":"none"</tt>
convention in the JWT header.
</p>
<p>The members defined by this specification are:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>userinfo</dt>
<dd>OPTIONAL. (UserInfo request): Requests
affecting the values to be returned from the UserInfo
endpoint. If not present, the UserInfo endpoint behaves in the
default manner.
</dd>
<dt>id_token</dt>
<dd>OPTIONAL. (ID request): Requests
affecting the values to be to be returned from the Token
Introspection endpoint. If not present, the default ID Token
contents are used. If present, these parameters are used to
request deltas to the default contents of the ID Token.
</dd>
</dl></blockquote><p>If signed, the OpenID Request object SHOULD contain the
standard JWT "iss" and "aud" claims.
</p>
<p>All members of the OpenID Request object are OPTIONAL. Other
members MAY be present and if so, SHOULD be understood by both
parties.
</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.1.1.1.1"></a><h3>3.1.1.1.1.
"userinfo" member</h3>
<p>The structure of the "userinfo" (UserInfo request) member is
a JSON object that MAY contain the following members:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>claims</dt>
<dd>OPTIONAL. (Requested Claims): Set of
requested claims from the UserInfo endpoint. If not present,
the default UserInfo claims held by the IdP are
returned.
</dd>
<dt>format</dt>
<dd>OPTIONAL. (Format): The requested
format for the UserInfo endpoint information. If not
present, the format is an unsigned JSON object.
</dd>
<dt>locale</dt>
<dd>OPTIONAL. (Locale): The default
languages and scripts of the entire claim request,
represented as a space-separated list of <a class='info' href='#RFC5646'>BCP47<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tags.
</dd>
</dl></blockquote><p>The "claims" member is a JSON object with a member for
each requested claim. The member names are the requested claim
names. The member values may be either:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>null</dt>
<dd>This indicates that this claim is being
requested in the default manner. In particular, this is a
required claim. OR
</dd>
<dt>A JSON Object</dt>
<dd>This is used to provide
additional information about the claim being requested.
</dd>
</dl></blockquote><p>The claims MAY be represented in multiple languages and
scripts. To specify languages and scripts for the claim request,
<a class='info' href='#RFC5646'>BCP47<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tags delimited by a
"#" MUST be added to each requested claim name for which a
particular language and script is requested. For example, the
claim <tt>family_name#ja-Kana-JP</tt> is used
for expressing Family Name in Katakana in Japanese, which is
commonly used to index and represent the phonetics of the Kanji
representation of the same value represented as <tt>family_name#ja-Hani-JP</tt>.
</p>
<p>All members of the "claims" object are OPTIONAL.
</p>
<p>The members of the JSON object value following a claim name
defined by this specification are:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>optional</dt>
<dd>If this is an optional claim, this
member's value MUST be <tt>true</tt>,
else, if present, its value MUST be <tt>false</tt>,
which indicates that it is a required claim. If it is not
present, it is a required claim.
</dd>
</dl></blockquote><p>Other members MAY be defined to provide additional
information about the requested claim. If the "claims" member is
present in the "userinfo" object, the claims requested within it
override the default claim set that would otherwise be returned
from the UserInfo endpoint.
</p>
<p>The "format" member of the "userinfo" object is used to
specify the requested format of the UserInfo endpoint contents.
Values defined are:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>unsigned</dt>
<dd>- in which case the contents are an
unsigned JSON object
</dd>
<dt>signed</dt>
<dd>- in which case the contents are a
signed JWT
</dd>
<dt>encrypted</dt>
<dd>- in which case the contents are an
signed and encrypted JWT
</dd>
</dl></blockquote><p>All members of the "userinfo" object are OPTIONAL.
Other members MAY be present and if so, SHOULD understood by
both parties.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.1.1.2"></a><h3>3.1.1.1.2.
"id_token" member</h3>
<p>The structure and function of the "id_token" (ID Token
request) member of the OpenID Request object is similar to that
of the "userinfo" member. It MAY include "claims", "format",
"locale". The same structure of these members are the same as
that for the "userinfo" member. If the "claims" member is
present in the "id_token" object, the claims requested within it
modify the default claim set that would otherwise be returned in
the ID Token. Unlike for the "userinfo" member, typically these
claims will augment, rather than override the default set.
</p>
<p>Following claim MAY be requested in the ID Token by
specifying it in the "claims" member:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>auth_time</dt>
<dd>OPTIONAL. (authenticated at):
Requests that the "auth_time" claim be present. The claim
value is the number of seconds from 1970-01-01T0:0:0Z as
measured in UTC until the date/time that the user
authentication occurred. (The "auth_time" claim semantically
corresponds to the openid.pape.auth_time response
parameter.)
</dd>
</dl></blockquote><p>In addition to the "claims" member, this additional
member is defined within the "id_token" member of the OpenID
Request object:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>max_age</dt>
<dd>OPTIONAL. (max authentication age):
Specifies that the user must be actively authenticated if
any present authentication is older than the specified
number of seconds. (The "max_age" request parameter
corresponds to the OpenID 2.0 openid.pape.max_auth_age
request parameter.)
</dd>
<dt>iso29115</dt>
<dd>OPTIONAL. (entity authentication
assurance): Specifies the X.eaa / <a class='info' href='#ISO29115'>ISO/IEC29115<span> (</span><span class='info'>McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology - Security techniques - Entity authentication assurance framework,” .</span><span>)</span></a> [ISO29115] entity authentication
assurance level that is requested by the client.
</dd>
</dl></blockquote><p>It is anticipated that additional "id_token" parameters
MAY be defined to request that additional properties hold for
the authentication - for instance, that certain authentication
policies be applied (in the same spirit of the OpenID 2.0
openid.pape.auth_policies values), or that the authentication
conform to the policies defined by a specified trust framework.
These parameters MAY be defined by extension specifications.
</p>
<p>All members of the "id_token" object are OPTIONAL. Other
members MAY be present and if so, SHOULD understood by both
parties
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.
Authorization Response</h3>
<p>When the <tt>response_type</tt> in the request
includes <tt>token</tt>, the Authorization
Response MUST return the parameters defined in section 4.2.2 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0]. In addition, the ID Token
MUST be returned as the value of the <tt>id_token</tt>
parameter in the response.
</p>
<p>When the <tt>response_type</tt> in the request
includes <tt>code</tt>, the Authorization
Response MUST return the parameters defined in section 4.1.2 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0]. The ID Token value is
returned at the Token endpoint.
</p>
<p>The <tt>response_type</tt> "<tt>none</tt>" preempts all other values and no other
response parameter values are returned.
</p>
<p>Example: The request is sent over to the Authorization Server
through HTTP redirect as follows: </p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://server.example.com/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&state=1f_8skd</pre></div><p>
</p>
<p>Then, after appropriate user authenticaiton and authorization,
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&state=1f_8skd</pre></div>
<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.1.3"></a><h3>3.1.3.
Authorization Error Response</h3>
<p>If the end-user denies the access request or if the request
fails, the authorization server informs the client by returning
parameters defined in section 4.1.2.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0].
</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.1.3.1"></a><h3>3.1.3.1.
Error Codes</h3>
<p>In addition to the error codes defined in section 4.1.2.1 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], this specification
defines the following additional error codes:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_request_redirect_uri</dt>
<dd>The redirect_uri in
the request is missing or malformed.
</dd>
<dt>login_required</dt>
<dd>The authorization server requires
user authentication.
</dd>
<dt>session_selection_required</dt>
<dd>The user is required
to select a session at the authorization server. The user may
be authenticated at the authorization server with different
associated accounts, but the user did not select a session or
no session selection is requested from the user due to the
<tt>display</tt> parameter being set to
<tt>none</tt>.
</dd>
<dt>approval_required</dt>
<dd>The authorization server
requires user approval.
</dd>
<dt>user_mismatched</dt>
<dd>The current logged in user at
the authorization server does not match the requested
user.
</dd>
</dl></blockquote>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Token Endpoint</h3>
<p>Access Token Request / Response interacts with a Token endpoint.
Upon a successful request, it returns an Access Token.
</p>
<a name="access_token_request"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1.
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>The request parameters of the Access Token Request are defined in
section 4.1.3 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<a name="access_token_response"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.2"></a><h3>3.2.2.
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 and an ID Token. The
parameters in the successful response are defined in Section 4.2.2
of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>In addition to the OAuth 2.0 response parameters, the following
parameters MUST be included in the response:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token value.
</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",
"expires_in": 3600,
"id_token": "LOsxIkE8XOWds8Yg"
}</pre></div>
<p>As in the <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], Clients
SHOULD ignore unrecognized response parameters.
</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.3.2.3"></a><h3>3.2.3.
Token Error Response</h3>
<p>If the token request is invalid or unauthorized, the
authorization server constructs the error response. The parameters
of the Token Error Response are defined as in Section 5.2 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0].
</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.3.2.3.1"></a><h3>3.2.3.1.
Error Codes</h3>
<p>In addition to the error codes defined in Section 5.2 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], this specification defines
the following error codes.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_authorization_code</dt>
<dd>The authorization
code is missing, malformed, or invalid.
</dd>
</dl></blockquote>
<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.3.3"></a><h3>3.3.
UserInfo Endpoint</h3>
<p>The UserInfo endpoint returns a claim object which contain claims
about the authenticated user. Claim objects are objects that contain
members and members' values which are the individual claims and claims
values. A claim object is represented by a JSON object which contains
a collection of name and value pairs for the claims.
</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.3.3.1"></a><h3>3.3.1.
Requests</h3>
<p>Clients MAY send requests with the following parameters to the
UserInfo endpoint to obtain further information about the user.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The access_token obtained
from an OpenID Connect authorization request. This parameter
MUST NOT be sent if the access token is sent in the HTTP
Authorization header.
</dd>
<dt>schema</dt>
<dd>OPTIONAL. The schema in which the data is
to be returned. The only predefined value is <tt>openid</tt>. If this parameter is not included,
the response may be a proprietary schema to support backwards
compatibility. A URL MAY be passed to define custom schemes not
specified by short names. Custom scheme names and responses are
out of scope for this specification.
</dd>
<dt>id</dt>
<dd>This identifier is reserved for backwards
compatibility. It MUST be ignored by the endpoint if the <tt>openid</tt> schema is used.
</dd>
</dl></blockquote>
<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.3.3.2"></a><h3>3.3.2.
Responses</h3>
<p>If the requested schema is "openid", the response MUST return a
JSON object that contains the full set or subset of claims that are
defined below. Additional claims (not specified below) MAY also be
returned.
</p>
<p>The members may be represented in multiple languages and scripts.
To specify the languages and scripts, <a class='info' href='#RFC5646'>BCP47<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tags MUST be added to each
member names delimited by a <tt>#</tt>, e.g.,
<tt>familyName#ja-Kana-JP</tt> for expressing
Family Name in Katakana in Japanese, which is commonly used to index
and represent the phonetics of the Kanji representation of the same
represented as <tt>familyName#ja-Hani-JP</tt>.
</p><br /><hr class="insert" />
<a name="ClaimTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left"><col align="left">
<tr><th align="left">Member</th><th align="left">Type</th><th align="left">Description</th></tr>
<tr>
<td align="left">id</td>
<td align="left">string</td>
<td align="left">Identifier for the user at the issuer.</td>
</tr>
<tr>
<td align="left">name</td>
<td align="left">string</td>
<td align="left">User's full name in displayable form including all name parts,
ordered according to user's locale and preferences.</td>
</tr>
<tr>
<td align="left">given_name</td>
<td align="left">string</td>
<td align="left">Given name or first name of the user.</td>
</tr>
<tr>
<td align="left">family_name</td>
<td align="left">string</td>
<td align="left">Surname or last name of the user.</td>
</tr>
<tr>
<td align="left">middle_name</td>
<td align="left">string</td>
<td align="left">Middle name of the user.</td>
</tr>
<tr>
<td align="left">nickname</td>
<td align="left">string</td>
<td align="left">Casual name of the user that may or may not be the same as the
<tt>given_name</tt>. For instance, a <tt>nickname</tt> value of <tt>Mike</tt>
might be returned alongside a <tt>given_name</tt>
value of <tt>Michael</tt>.</td>
</tr>
<tr>
<td align="left">profile</td>
<td align="left">string</td>
<td align="left">URL of user's profile page.</td>
</tr>
<tr>
<td align="left">picture</td>
<td align="left">string</td>
<td align="left">URL of the user's profile picture.</td>
</tr>
<tr>
<td align="left">website</td>
<td align="left">string</td>
<td align="left">URL of user's web page or blog.</td>
</tr>
<tr>
<td align="left">email</td>
<td align="left">string</td>
<td align="left">The user's preferred e-mail address.</td>
</tr>
<tr>
<td align="left">verified</td>
<td align="left">boolean</td>
<td align="left">True if the user's e-mail address has been verified; otherwise
false.</td>
</tr>
<tr>
<td align="left">gender</td>
<td align="left">string</td>
<td align="left">The user's gender: <tt>female</tt> or <tt>male</tt>.</td>
</tr>
<tr>
<td align="left">birthday</td>
<td align="left">string</td>
<td align="left">The user's birthday, represented as a date string in MM/DD/YYYY
format. The year MAY be <tt>0000</tt>,
indicating that it is omitted.</td>
</tr>
<tr>
<td align="left">zoneinfo</td>
<td align="left">string</td>
<td align="left">String from zoneinfo <a class='info' href='#zoneinfo'>[zoneinfo]<span> (</span><span class='info'>Public Domain, “The tz database,” June 2011.</span><span>)</span></a> timezone
database. For example, <tt>Europe/Paris</tt> or
<tt>America/Los_Angeles</tt>.</td>
</tr>
<tr>
<td align="left">locale</td>
<td align="left">string</td>
<td align="left">The user's locale, represented as an <a class='info' href='#RFC5646'>RFC
5646<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tag. This is typically an <a class='info' href='#ISO639-1'>ISO 639-1 Alpha-2<span> (</span><span class='info'>International Organization for Standardization, “ISO 639-1:2002. Codes for the representation of names of languages -- Part 1: Alpha-2 code,” 2002.</span><span>)</span></a> [ISO639‑1] language code in
lowercase and an <a class='info' href='#ISO3166-1'>ISO 3166-1
Alpha-2<span> (</span><span class='info'>International Organization for Standardization, “ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes,” 1997.</span><span>)</span></a> [ISO3166‑1] country code in uppercase, separated by a dash. For
example, <tt>en-US</tt> or <tt>fr-CA</tt>.
As a compatibility note, some implementations have used an
underscore as the separator rather than a dash, for example,
<tt>en_US</tt>; Implementations MAY choose to
accept this locale syntax as well.</td>
</tr>
<tr>
<td align="left">phone_number</td>
<td align="left">string</td>
<td align="left">The user's preferred telephone number. For example, <tt>+1 (425)
555-1212</tt> or <tt>+56 (2) 687 2400</tt>.</td>
</tr>
<tr>
<td align="left">address</td>
<td align="left">JSON object</td>
<td align="left">The user's preferred address. The value of the <tt>address</tt> member is a <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] structure containing some or all of
these string-valued fields: <tt>formatted</tt>,
<tt>street_address</tt>, <tt>locality</tt>,
<tt>region</tt>, <tt>postal_code</tt>,
and <tt>country</tt>. The <tt>street_address</tt>
field MAY contain multiple lines if the address representation
requires it. Implementations MAY return only a subset of the
fields of an <tt>address</tt>, depending upon
the information available and the user's privacy preferences. For
example, the <tt>country</tt> and <tt>region</tt> might be returned without returning
more fine-grained address information.</td>
</tr>
<tr>
<td align="left">updated_time</td>
<td align="left">string</td>
<td align="left">Time the user's information was last updated, represented as a
<a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a> [RFC3339] datetime. For example,
<tt>2011-01-03T23:58:42+0000</tt>.</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Table 1: Reserved Member Definitions </b></font><br /></td></tr></table><hr class="insert" />
<p>For privacy reasons, OpenID providers may elect to not provide
values for some schema elements as part of the "openid" scope.
</p>
<p>The UserInfo endpoint MUST return claims in JSON format unless a
request for a different format is made by the client in the
authorization request. The UserInfo endpoint MAY return claims in
JWT format which can be signed or encrypted via <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS] and <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.</span><span>)</span></a> [JWE]
respectively. <a class='info' href='#OpenIDReq'>The OpenID REquest
Object<span> (</span><span class='info'>OpenID Request Object</span><span>)</span></a> describes how to request a different format. The
UserInfo endpoint MUST return a content-type header to indicate
which format is being returned. The following are accepted content
types:
</p><table class="all" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Content-Type</th><th align="left">Format Returned</th></tr>
<tr>
<td align="left">application/json</td>
<td align="left">plain text JSON object</td>
</tr>
<tr>
<td align="left">application/jwt</td>
<td align="left">A JWT</td>
</tr>
</table>
<br clear="all" />
<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.3.3.2.1"></a><h3>3.3.2.1.
Example Responses</h3>
<p>The following is a non-normative normal claims responses:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}</pre></div><p>
</p>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3.3"></a><h3>3.3.3.
Errors</h3>
<p>In addition to the error codes defined in section 4.1.2.1 of
<a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], this specification
defines the following additional error codes:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_schema</dt>
<dd>The requested schema is invalid or
unsupported.
</dd>
</dl></blockquote>
<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.3.3.4"></a><h3>3.3.4.
Claim Types</h3>
<p>The UserInfo endpoint MAY return a claim object with the
following three types of claims:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Normal Claims</dt>
<dd>Claims that are directly asserted by
the OpenID Provider.
</dd>
<dt>Aggregated Claims</dt>
<dd>Claims that are asserted by a
claims provider other than the OpenID Provider but are returned
by OpenID Provider.
</dd>
<dt>Distributed Claims</dt>
<dd>Claims that are asserted by a
claims provider other than the OpenID Provider but are returned
as references by the OpenID Provider.
</dd>
</dl></blockquote><p>The UserInfo endpoint MUST support normal claims.
</p>
<p>Aggregated and distributed claims support is OPTIONAL.
</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.3.3.4.1"></a><h3>3.3.4.1.
Normal Claims</h3>
<p>Normal claims are represented as members in a claim object. The
claim name is the member name and the claim value is the member
value.
</p>
<p>The following is a non-normative normal claims responses:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}</pre></div>
<p>
</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.3.3.4.2"></a><h3>3.3.4.2.
Aggregated and Distributed Claims</h3>
<p>Aggregated and distributed claims are represented within the
"_claim_names" and "_claim_sources" members of a claim object.
Both "_claim_names" and "_claim_sources" members are claim
objects.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>_claim_names</dt>
<dd>This is a JSON object whose member
names are the claims names for the aggregated and distributed
claims. The member values are references to the member names
in the "_claim_sources" member of the claim object from which
the actual value can be retrieved.
</dd>
<dt>_claim_sources</dt>
<dd>This is a JSON object whose
member names are referenced by the member values of the
"_claim_names" member of the claim object. The member values
contain sets of aggregated claims or reference locations for
distributed claims. The member values can have one of the
following formats depending on whether it's providing
aggregated or distributed claims:
<blockquote class="text"><dl>
<dt>Aggregated Claims</dt>
<dd>A JSON object which MUST
contain the "JWT" member whose value is a <a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” July 2011.</span><span>)</span></a> [JWT] which MUST contain all the claims
in the "_claim_names" object which references the
corresponding "_claim_sources" member. Other members MAY
be present if they are understood by both parties.
<blockquote class="text"><dl>
<dt>JWT</dt>
<dd>REQUIRED. JWT Value
</dd>
</dl></blockquote>
</dd>
<dt>Distributed Claims</dt>
<dd>A JSON object which
contains the following members and values:
<blockquote class="text"><dl>
<dt>endpoint</dt>
<dd>REQUIRED. The value is the
OAuth 2.0 resource endpoint from which the associated
claim can be retrieved. The endpoint URL MUST return
the claim as a JWT.
</dd>
<dt>access_token</dt>
<dd>OPTIONAL. Access token
enabling retrieval of the claims from the endpoint URL
by using the <a class='info' href='#OAuth.2.0.Bearer'>OAuth 2.0
BEARER<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” July 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] scheme. Claims SHOULD be requested using
the Authorization request header field and claims
sources MUST support this method.
</dd>
</dl></blockquote>
</dd>
</dl></blockquote> Other members MAY be present, if understood by both
parties
</dd>
</dl></blockquote>
<p>The following is a non-normative response with aggregated
claims:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"_claim_names": {
"birthday": "src1",
"eye_color": "src1",
},
"_claim_sources": {
"src1": {"JWT": "JWT_header.JWT_part2.JWT_part3"},
}
}</pre></div><p>
</p>
<p>The following is a non-normative response with distributed
claims:
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"name": "Jane Doe"
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"_claim_names": {
"payment_info": "src1",
"shipping_address": "src1",
"credit_score": "src2"
},
"_claim_sources": {
"src1": {"endpoint": "https://merchant.example.com/claimsource"},
"src2": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"}
}
}</pre></div><p>
</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.3.4"></a><h3>3.4.
Introspection Endpoint</h3>
<p>The Introspection endpoint returns a <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] object which contains information about
the end user and authentication event associated with the supplied ID
Token.
</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.3.4.1"></a><h3>3.4.1.
Introspection Request</h3>
<p>To request the information about the authentication performed on
the user, the following parameters are sent to the Introspection
Endpoint. Note that the Introspection endpoint MAY use the same URL
as the UserInfo endpoint.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token obtained from an
OpenID Connect authorization request.
</dd>
</dl></blockquote>
<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.3.4.2"></a><h3>3.4.2.
Introspection Response</h3>
<p>The response is a <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] object
containing the following claims:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>iss</dt>
<dd>REQUIRED. The unique identifier of the issuer
of the response.
</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. <tt>24400320</tt>
or <tt>AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</tt>.
It MUST NOT exceed 255 ASCII characters in length.
</dd>
<dt>aud</dt>
<dd>REQUIRED. This member identifies the audience
that this ID Token is intended for. It is RECOMENDED that <tt>aud</tt> be the OAuth <tt>client_id</tt>
of the RP.
</dd>
<dt>exp</dt>
<dd>REQUIRED. Type Integer. Identifies the
expiration time on or after which the ID Token MUST NOT be
accepted for processing. The processing of this parameter
requires that the current date/time MUST be before the
expiration date/time listed in the value. Implementers MAY
provide for some small leeway, usually no more than a few
minutes, to account for clock skew. The value is number of
seconds from 1970-01-01T0:0:0Z as measured in UTC until the
desired date/time. See <a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a> [RFC3339]
for details regarding date/times in general and UTC in
particular.
</dd>
<dt>iso29115</dt>
<dd>OPTIONAL. (entity authentication
assurance): Specifies the X.eaa / <a class='info' href='#ISO29115'>ISO/IEC29115<span> (</span><span class='info'>McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology - Security techniques - Entity authentication assurance framework,” .</span><span>)</span></a> [ISO29115] entity authentication
assurance level of the authentication performed.
</dd>
<dt>nonce</dt>
<dd>OPTIONAL. If the authorization request
includes a nonce request value, then this value is REQUIRED and
its value is set to the same value as the request value.
</dd>
<dt>issued_to</dt>
<dd>OPTIONAL. The OAuth identifier of the
client the token was issued to; this SHOULD only present if
different from the <tt>aud</tt> value.
</dd>
</dl></blockquote>
<p>The Token Introspection endpoint MUST return claims in JSON
format unless a request for a different format is made by the client
in the authorization request. The Token Introspection endpoint MAY
return claims in JWT format which can be <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS] signed or <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.</span><span>)</span></a> [JWE]
encrypted. <a class='info' href='#OpenIDReq'>The OpenID REquest Object<span> (</span><span class='info'>OpenID Request Object</span><span>)</span></a>
describes how to request a different format. The Token Introspection
endpoint MUST return a content-type header to indicate which format
is being returned. The following are accepted content types:
</p><table class="all" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Content-Type</th><th align="left">Format Returned</th></tr>
<tr>
<td align="left">application/json</td>
<td align="left">plain text JSON object</td>
</tr>
<tr>
<td align="left">application/jwt</td>
<td align="left">A JWT</td>
</tr>
</table>
<br clear="all" />
<p>The following is a non-normative example of a request to
the Introspection endpoint:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>Request:
GET /id_token?id_token=eyJ0eXAiOiJKV1QiL HTTP/1.1
Host: server.example.com
Response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"iss": "http://server.example.com",
"user_id": "248289761001",
"aud": "http://client.example.net",
"exp": 1311281970
}
</pre></div>
<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.3.4.3"></a><h3>3.4.3.
Error Codes</h3>
<p>In addition to the error codes defined in Section 5.2 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” Jul 2011.</span><span>)</span></a> [OAuth.2.0], this specification defines the
following error codes.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>invalid_id_token</dt>
<dd>The ID Token is not valid for the
requested resource, is malformed, is in an incorrect format, or
is expired.
</dd>
</dl></blockquote>
<a name="verification"></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.4"></a><h3>3.4.4.
Verification</h3>
<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.3.4.4.1"></a><h3>3.4.4.1.
Request Verification</h3>
<p>The authorization server validates the request to ensure all
required parameters are present and valid.
</p>
<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.3.4.4.2"></a><h3>3.4.4.2.
Response Verification</h3>
<p>To verify the validity of the Response, the client MUST to the
following:
</p>
<p></p>
<ol class="text">
<li>Check that current time is within the validity period of
the <tt>exp</tt> contained within the
response.
</li>
<li>Verify that the response was intended for the recipient,
using the <tt>aud</tt> (audience) contained
within the response.
</li>
<li>If <tt>issued_to</tt> is present, then
it MUST contain an identifier for a party trusted by the
Relying Party. If <tt>issued_to</tt> is
unknown or untrusted, then the assertion MUST be rejected.
</li>
<li>Check that the server that responded was really the
intended server through a TLS/SSL server certificate
check.
</li>
</ol>
<a name="anchor26"></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.
Session Management Endpoints</h3>
<p>The Session Mangement endpoints provide endpoints to manage and
synchronize authentication sessions at the authorization server and
clients. The endpoints are specified in the <a class='info' href='#OpenID.Session'>OpenID Connect Session Management<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” July 2011.</span><span>)</span></a> [OpenID.Session]
specification.
</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.4"></a><h3>4.
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.4.1"></a><h3>4.1.
Query String Serialization</h3>
<p>In order to serialize the parameters using the 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='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
</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
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/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.4.2"></a><h3>4.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"
}</pre></div>
<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.5"></a><h3>5.
Signatures and Encryption</h3>
<p>Depending on the transport through which the messages are sent, the
integrity of the message may not be guaranteed and the originator of the
message may not be authenticated. To mitigate these risks, OpenID
Connect tokens MAY utilize <a class='info' href='#JWS'>JSON Web Signatures
(JWS)<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS] to sign the token content.
</p>
<p>To achieve message confidentiality, OpenID Connect tokens MAY use
<a class='info' href='#JWE'>JSON Web Encryption (JWE)<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.</span><span>)</span></a> [JWE] to encrypt the token
content.
</p>
<a name="anchor27"></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.
Verification</h3>
<a name="anchor28"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
Authorization Request Verification</h3>
<p>If the request was signed, the Server MUST verify the signature as
in JWT.
</p>
<a name="anchor29"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
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 token
signature as the first step.
</li>
<li>Check that current time is within the validity period contained
within the token.
</li>
<li>Verify that the token was intended for the recipient, using the
audience contained within the token.
</li>
<li>Check that the OP that responded was really the intended OP
through a TLS/SSL server certificate check.
</li>
</ol>
<p>If the client does not directly verify the signature, it MUST make
a request to the Introspection Endpoint to validate the token.
</p>
<a name="anchor30"></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.3"></a><h3>6.3.
UserInfo Request Verification</h3>
<p>If the request was signed, the Server MUST verify the signature as
in <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</p>
<a name="anchor31"></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.4"></a><h3>6.4.
UserInfo Response Verification</h3>
<p>To verify the validity of the UserInfo response, the client MUST do
the following:
</p>
<p></p>
<ol class="text">
<li>If the response was signed, the Client SHOULD verify the token
signature as the first step.
</li>
<li>If the response was signed, check that current time is within
the validity period contained within the response.
</li>
<li>If the response was signed, verify that the response was
intended for the recipient, using the audience contained within
the response.
</li>
<li>Check that the OP that responded was really the intended OP
through a TLS/SSL server certificate check.
</li>
</ol>
<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.7"></a><h3>7.
Extensions</h3>
<a name="related"></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.
Related Specifications</h3>
<p>These related OpenID Connect specifications MAY OPTIONALLY be used in
combination with this specification to provide additional functionality:
</p>
<ul class="text">
<li><a class='info' href='#OpenID.UserInfo'>OpenID Connect UserInfo 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, “OpenID Connect UserInfo 1.0,” July 2011.</span><span>)</span></a> [OpenID.UserInfo]
- Schema and format of claims returned by the UserInfo endpoint of
OpenID Connect
</li>
<li><a class='info' href='#OpenID.Discovery'>OpenID Connect Discovery
1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” July 2011.</span><span>)</span></a> [OpenID.Discovery] - Dynamic discovery for user and server endpoints and
information
</li>
<li><a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client
Registration 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Ed., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0 - draft 02,” July 2011.</span><span>)</span></a> [OpenID.Registration] - Dynamic registration of OpenID Connect
clients with OpenID Providers
</li>
<li><a class='info' href='#OpenID.Session'>OpenID Connect Session Management
1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” July 2011.</span><span>)</span></a> [OpenID.Session] - Session management for OpenID Connect sessions
</li>
<li><a class='info' href='#OpenID.Standard'>OpenID Connect Standard 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” August 2011.</span><span>)</span></a> [OpenID.Standard]
- Protocol binding for the full set of OpenID Connect Messages
</li>
<li><a class='info' href='#OpenID.Lite'>OpenID Connect Lite 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Lite 1.0,” August 2011.</span><span>)</span></a> [OpenID.Lite] -
Protocol binding for a subset of of the OpenID Connect Messages
which is intended for use by relying parties.
</li>
</ul>
<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.9"></a><h3>9.
Security Considerations</h3>
<p>This specification references the security considerations defined in
<a class='info' href='#OAuth.2.0.SC'>OAuth 2.0 Security
Considerations<span> (</span><span class='info'>Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” July 2011.</span><span>)</span></a> [OAuth.2.0.SC].
</p>
<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.9.1"></a><h3>9.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.9.2"></a><h3>9.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.9.3"></a><h3>9.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.9.4"></a><h3>9.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.9.5"></a><h3>9.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.9.6"></a><h3>9.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.9.7"></a><h3>9.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.9.8"></a><h3>9.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.9.9"></a><h3>9.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="anchor32"></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.10"></a><h3>9.10.
Timing Attack</h3>
<p>Timing attack can be used to reduce the effective key length of the
signature if the time required to return the response in case of a
signature error and a correct signature differs. 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.9.11"></a><h3>9.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.10"></a><h3>10.
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.10.1"></a><h3>10.1.
OAuth Parameters Registry</h3>
<a name="anchor33"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.1.1"></a><h3>10.1.1.
Scope Parameters</h3>
<p>The following is the parameter registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Parameter name: openid
</li>
<li>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.
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[ this document ]]
</li>
<li>Related information: None
</li>
</ul>
<a name="anchor34"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.1.2"></a><h3>10.1.2.
Authorization Request Parameters</h3>
<p>The following is the parameter registration request for the
Authorization Request in this specification:
</p>
<p></p>
<ul class="text">
<li>Parameter name: openid
</li>
<li>Parameter usage location: Authorization Request
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[ this document ]]
</li>
<li>Related information: None
</li>
</ul>
<a name="anchor35"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.1.3"></a><h3>10.1.3.
Access Token Response Parameters</h3>
<p>The following is the parameter registration request for the
Access Token Response in this specification:
</p>
<p></p>
<ul class="text">
<li>Parameter name: openid
</li>
<li>Parameter usage location: Access Token Response
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[ this document ]]
</li>
<li>Related information: None
</li>
</ul>
<a name="anchor36"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
Open Issues and Things To Be Done (TBD)</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>Following items remain to be done in this draft:
</p>
<p></p>
<ul class="text">
<li>
</li>
</ul>
<p>
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>12.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ISO29115">[ISO29115]</a></td>
<td class="author-text">McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 --
Information technology - Security techniques - Entity authentication
assurance framework,” ISO/IEC 29115.</td></tr>
<tr><td class="author-text" valign="top"><a name="ISO3166-1">[ISO3166-1]</a></td>
<td class="author-text">International Organization for
Standardization, “<a href="http://www.w3.org/WAI/ER/IG/ert/iso639.htm">ISO 3166-1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country codes</a>,” 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="ISO639-1">[ISO639-1]</a></td>
<td class="author-text">International Organization for
Standardization, “ISO 639-1:2002. Codes for the representation of names of
languages -- Part 1: Alpha-2 code,” 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://self-issued.info/docs/draft-jones-json-web-encryption.html">JSON Web Encryption</a>,” March 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://tools.ietf.org/html/draft-jones-json-web-signature">JSON Web Signatures</a>,” April 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “<a href="http://tools.ietf.org/html/draft-jones-json-web-token">JSON Web Token</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.2.0">[OAuth.2.0]</a></td>
<td class="author-text">Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">OAuth 2.0 Authorization Protocol</a>,” Jul 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.2.0.Bearer">[OAuth.2.0.Bearer]</a></td>
<td class="author-text">Jones, M., Hardt, D., and D. Recordon, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer">OAuth 2.0 Protocol: Bearer Tokens</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.2.0.SC">[OAuth.2.0.SC]</a></td>
<td class="author-text">Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel">OAuth 2.0 Threat Model and Security Considerations</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Lite">[OpenID.Lite]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-lite-1_0.html">OpenID Connect Lite 1.0</a>,” August 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Registration">[OpenID.Registration]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Ed., and M. Jones, “<a href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client
Registration 1.0 - draft 02</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Session">[OpenID.Session]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-session-1_0.html">OpenID Connect Session Management
1.0</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Standard">[OpenID.Standard]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-standard-1_0.html">OpenID Connect Standard
1.0</a>,” August 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.UserInfo">[OpenID.UserInfo]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., de Medeiros, B., Jones, M., Jay, E., and G. George, “<a href="http://openid.net/specs/openid-connect-userinfo-1_0.html">OpenID Connect UserInfo 1.0</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text"><a href="mailto:GK@ACM.ORG">Klyne, G., Ed.</a> and <a href="mailto:chris.newman@sun.com">C. Newman</a>, “<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,” RFC 3339, July 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3339.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3339.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3339.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="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="RFC5646">[RFC5646]</a></td>
<td class="author-text">Phillips, A. and M. Davis, “<a href="http://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>,” BCP 47, RFC 5646, September 2009 (<a href="http://www.rfc-editor.org/rfc/rfc5646.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.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a></td>
<td class="author-text">Hors, A., Raggett, D., and I. Jacobs, “<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="zoneinfo">[zoneinfo]</a></td>
<td class="author-text">Public Domain, “<a href="http://www.twinsun.com/tz/tz-link.htm">The tz database</a>,” June 2011.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>12.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OpenID.2.0">[OpenID.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>
</table>
<a name="anchor39"></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 successor version of OpenID, this specification heavily relies
on <a class='info' href='#OpenID.2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>specs@openid.net, “OpenID Authentication 2.0,” 2007.</span><span>)</span></a> [OpenID.2.0]. Please
refer to Appendix C of OpenID Authentication 2.0 for the full list of
the contributors for that specification.
</p>
<p>This specification is largely compliant with OAuth 2.0 draft 16.
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>
<blockquote class="text">
<p>Anthony Nadalin (tonynad@microsoft.com), Microsoft
</p>
<p>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
</p>
<p>Casper Biering (cb@peercraft.com), Peercraft
</p>
<p>Breno de Medeiros (breno@gmail.com), Google
</p>
<p>Chuck Mortimore (cmortimore@salesforce.com), Salesforce.com
</p>
<p>David Recordon (dr@fb.com), Facebook
</p>
<p>George Fletcher (george.fletcher@corp.aol.com), AOL
</p>
<p>Hideki Nara (hideki.nara@gmail.com), Takt Communications
</p>
<p>John Bradley (jbradely@mac.com), Protiviti Government
Services
</p>
<p>Mike Jones (Michael.Jones@microsoft.com), Microsoft
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute,
Ltd.
</p>
<p>Paul Tarjan (pt@fb.com), Facebook
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan
</p>
</blockquote>
<a name="anchor40"></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>[[ To be removed from the final specification ]]
</p>
<p>-01 </p>
<ul class="text">
<li>First Draft that incorporates the merge of the Core and Framework
specs.
</li>
</ul>
<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">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">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 Medeiros</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">Michael B. 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:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Edmund Jay</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">MGI1</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ejay@mgi1.com">ejay@mgi1.com</a></td></tr>
</table>
</body></html>