<!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 05</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Messages 1.0 - draft 05">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">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">September 30, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Messages 1.0 - draft 05</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 Basic Client)
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="#id_token">3.1.1.</a>
ID Token<br />
<a href="#auth_req">3.1.2.</a>
Authorization Request<br />
<a href="#anchor6">3.1.3.</a>
Authorization Response<br />
<a href="#anchor7">3.1.4.</a>
Authorization Error Response<br />
<a href="#token_ep">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="#anchor9">3.2.3.</a>
Token Error Response<br />
<a href="#userinfo_ep">3.3.</a>
UserInfo Endpoint<br />
<a href="#anchor11">3.3.1.</a>
Requests<br />
<a href="#anchor12">3.3.2.</a>
Responses<br />
<a href="#anchor13">3.3.3.</a>
Errors<br />
<a href="#anchor14">3.3.4.</a>
Claim Types<br />
<a href="#check_id_ep">3.4.</a>
Check ID Endpoint<br />
<a href="#anchor17">3.4.1.</a>
Check ID Request<br />
<a href="#anchor18">3.4.2.</a>
Check ID Response<br />
<a href="#anchor19">3.4.3.</a>
Error Codes<br />
<a href="#anchor20">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="#sigenc">5.</a>
Signatures and Encryption<br />
<a href="#sigs">5.1.</a>
Signing<br />
<a href="#enc">5.2.</a>
Encryption<br />
<a href="#anchor21">6.</a>
Verification<br />
<a href="#anchor22">6.1.</a>
Authorization Request Verification<br />
<a href="#anchor23">6.2.</a>
Authorization Response Verification<br />
<a href="#anchor24">6.3.</a>
Token Request Verification<br />
<a href="#anchor25">6.4.</a>
Token Response Verification<br />
<a href="#anchor26">6.5.</a>
UserInfo Request Verification<br />
<a href="#anchor27">6.6.</a>
UserInfo Response Verification<br />
<a href="#anchor28">6.7.</a>
Check ID Request Verification<br />
<a href="#anchor29">6.8.</a>
Check ID Response Verification<br />
<a href="#related">7.</a>
Related Specifications<br />
<a href="#security_considerations">8.</a>
Security Considerations<br />
<a href="#assertion_manufacture">8.1.</a>
Assertion Manufacture/Modification<br />
<a href="#assertion_disclosure">8.2.</a>
Assertion Disclosure<br />
<a href="#assertion_repudiation">8.3.</a>
Assertion Repudiation<br />
<a href="#assertion_redirect">8.4.</a>
Assertion Redirect<br />
<a href="#assertion_reuse">8.5.</a>
Assertion Reuse<br />
<a href="#artifact_manufacture">8.6.</a>
Secondary Authenticator Manufacture<br />
<a href="#artifact_capture">8.7.</a>
Secondary Authenticator Capture<br />
<a href="#assertion_substitution">8.8.</a>
Assertion Substitution<br />
<a href="#auth_req_disclosure">8.9.</a>
Authentication Request Disclosure<br />
<a href="#anchor30">8.10.</a>
Timing Attack<br />
<a href="#authn_proc_threats">8.11.</a>
Authentication Process Threats<br />
<a href="#iana">9.</a>
IANA Considerations<br />
<a href="#oauth_params">9.1.</a>
OAuth Parameters Registry<br />
<a href="#anchor31">9.1.1.</a>
Scope Parameters<br />
<a href="#anchor32">9.1.2.</a>
Authorization Request Parameter (display)<br />
<a href="#anchor33">9.1.3.</a>
Authorization Request Parameter (prompt)<br />
<a href="#anchor34">9.1.4.</a>
Authorization Request Parameter (nonce)<br />
<a href="#anchor35">9.1.5.</a>
Authorization Request Parameter (audience)<br />
<a href="#anchor36">9.1.6.</a>
Authorization Request Parameter (request)<br />
<a href="#anchor37">9.1.7.</a>
Authorization Request Parameter (request_uri)<br />
<a href="#anchor38">9.1.8.</a>
ID Token Response Parameters<br />
<a href="#anchor39">9.2.</a>
OAuth Extensions Error Registry<br />
<a href="#anchor40">9.2.1.</a>
Authorization endpoint error (invalid_request_redirect_uri)<br />
<a href="#anchor41">9.2.2.</a>
Authorization endpoint error (login_required)<br />
<a href="#anchor42">9.2.3.</a>
Authorization endpoint error (session_selection_required)<br />
<a href="#anchor43">9.2.4.</a>
Authorization endpoint error (approval_required)<br />
<a href="#anchor44">9.2.5.</a>
Authorization endpoint error (user_mismatched)<br />
<a href="#anchor45">9.2.6.</a>
Token endpoint error (invalid_authorization_code)<br />
<a href="#anchor46">9.2.7.</a>
UserInfo endpoint error (invalid_schema)<br />
<a href="#anchor47">9.2.8.</a>
Check ID endpoint error (invalid_id_token)<br />
<a href="#rfc.references1">10.</a>
References<br />
<a href="#rfc.references1">10.1.</a>
Normative References<br />
<a href="#rfc.references2">10.2.</a>
Informative References<br />
<a href="#anchor50">Appendix A.</a>
Acknowledgements<br />
<a href="#anchor51">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,” September 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 that are attested to
by an Issuer.
</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>A token that contains claims about the
authentication event.
</dd>
<dt>Issuer</dt>
<dd>An Entity who issues an Assertion.
</dd>
<dt>Issuer Identifier</dt>
<dd>A verifiable identifier of an Issuer.
An issuer Identifier is a HTTPS URL with no path component.
</dd>
<dt>Message</dt>
<dd>A request or a response between an OpenID
Relying Party and an OpenID Provider.
</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>Check ID Endpoint</dt>
<dd>A resource that, when
presented with an ID Token by the client, returns authentication
information about the user session represented by that ID Token.
</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 Authorization Server's end-user
authorization endpoint.
</li>
<li>The Authorization Server authenticates the user and obtains
appropriate authorization.
</li>
<li>The Authorization 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 <a class='info' href='#userinfo_ep'>UserInfo endpoint<span> (</span><span class='info'>UserInfo Endpoint</span><span>)</span></a>.
</li>
<li>UserInfo endpoint returns the additional user information
supported by the Resource Server.
</li>
<li>OPTIONAL. The Client sends a request with the id_token to the
Authorization Server's <a class='info' href='#check_id_ep'>Check ID
endpoint<span> (</span><span class='info'>Check ID Endpoint</span><span>)</span></a>.
</li>
<li>OPTIONAL. The Check ID endpoint responds with authentication
information pertaining to the supplied id_token.
</li>
</ol><p>
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.Basic'>OpenID Connect
Basic Client<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Basic Client 1.0,” September 2011.</span><span>)</span></a> [OpenID.Basic] 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,” September 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
Authorization Server at the authorization endpoint. The Authorization
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 Authorization 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>Check ID Endpoint: An id_token MAY be sent to the Check
Session endpoint to obtain information about the authentication
event.
</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 <a class='info' href='#id_token'>ID Token<span> (</span><span class='info'>ID Token</span><span>)</span></a>.
</p>
<a name="id_token"></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.
ID Token</h3>
<p>The ID Token is a token that contains claims pertinent to the
authentication event. The default format of an ID Token is a JWT
which contains JSON claims. Authorization servers MAY return ID
Tokens in a different format. Clients can discover the ID Token
format used by authorization servers via <a class='info' href='#OpenID.Discovery'>OpenID Connect Discovery<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” September 2011.</span><span>)</span></a> [OpenID.Discovery] or by
possessing prior knowledge of the authorization server.
</p>
<p>The ID Token is used to manage the authentication event and user
identifier and is scoped to a particular client via the <tt>audience</tt> and <tt>nonce</tt>
claims. It MUST NOT be used as an access token to access OAuth 2.0
protected resources.
</p>
<p>The ID Token MUST attests minimally to 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>
</dl></blockquote>
<p>JWT ID Tokens MAY be signed or signed and 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., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE]
respectively, thereby providing authentication, integrity,
non-repudiation and/or confidentiality. ID Tokens in other formats
MAY be signed or encrypted with methods suitable for the respective
formats.
</p>
<p>Clients SHOULD verify and decipher signed or encrypted ID Tokens
independently. Clients that do not understand the ID Token format or
do not wish to process ID Tokens MAY treat ID Tokens as opaque
values and submit them to the <a class='info' href='#check_id_ep'>Check
ID Endpoint<span> (</span><span class='info'>Check ID Endpoint</span><span>)</span></a> for verification and decoding.
</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.2"></a><h3>3.1.2.
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,” September 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>id_token</tt>.
The value MUST include <tt>code</tt> for
requesting an Authorization Code, <tt>token</tt>
for requesting an Access Token, and <tt>id_token</tt> for requesting an ID Token.
</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. Informs the Authorization
Server that the client is making an OpenID request. If the
<tt>openid</tt> scope is not specified,
the server SHOULD treat the request as a generic OAuth 2.0
request, and perform no OpenID Connect processing.
The <tt>openid</tt> value also 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>response_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
<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 at the UserInfo
endpoint be granted by the issued Access Token.
</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>nonce</dt>
<dd>REQUIRED. A random, unique string value used
to mitigate replay attacks.
</dd>
<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 or confirmation
user interface pages. An error is returned if either the user
is not already authenticated or the client does not have
pre-configured approval for the requested
<tt>scopes</tt>. This can be used as a
method to check for existing authentication and/or approval.
</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 account has
multiple accounts associated with it
</dd>
</dl></blockquote>
This can be used by the client to make sure that the user is
still present for the current session or to bring attention to the
request. If this parameter is used in conjunction with the
<tt>display</tt> parameter set to "none", an
error is returned.
</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. An URL that points to an
OpenID Request Object. This is used to pass an OpenID Request
Object by reference.
</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>
<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.2.1"></a><h3>3.1.2.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='#userinfo_ep'>UserInfo<span> (</span><span class='info'>UserInfo Endpoint</span><span>)</span></a>, ID Token, and <a class='info' href='#check_id_ep'>Check ID<span> (</span><span class='info'>Check ID Endpoint</span><span>)</span></a> claim sets.
</p>
<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 is passed as the value of the "<tt>request</tt>"
parameter in the authorization request. The OpenID Request Object
can also be sent by reference. Parameters that affect the
information returned from the UserInfo endpoint are in the "<tt>userinfo</tt>" member. Parameters that affect the
information returned from the ID Token and Check ID endpoint
are in the "<tt>id_token</tt>" member. If the
same parameters are available both as query strings and in the
OpenID Request Object, the later takes the precedence.
</p>
<p>The OpenID Request Object MUST contain all REQUIRED OAuth 2.0
authorization request parameters and MAY contain optional and
extension parameters.
</p>
<p>The OpenID Request object MAY contain a set of members defined
by this specification and MAY contain other members that are not
defined by this specification. OpenID Request object members
SHOULD be understood by both parties.
</p>
<p>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. If signed, the OpenID Request object
SHOULD contain the standard JWT "<tt>iss</tt>"
and "<tt>aud</tt>" claims.
</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 ID Token
and Check ID 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><p>An example an OpenID request object before JWT
encoding is as follows:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.com/cb",
"scope": "openid profile",
"state": "af0ifjsldkj", "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>
<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.2.1.1"></a><h3>3.1.2.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 OP 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.2.1.2"></a><h3>3.1.2.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 structure of these members is 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.3"></a><h3>3.1.3.
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,” September 2011.</span><span>)</span></a> [OAuth.2.0]. This specification only
supports <a class='info' href='#OAuth.2.0.Bearer'>Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer]. The
OAuth 2.0 response parameter "<tt>token_type</tt>"
MUST be set to "<tt>Bearer</tt>".
</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,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>When the <tt>response_type</tt> includes <tt>id_token</tt>, the ID Token MUST be returned as the
value of the <tt>id_token</tt> parameter in the
response.
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.4"></a><h3>3.1.4.
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,” September 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.4.1"></a><h3>3.1.4.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,” September 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="token_ep"></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 and ID
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>Clients required to authenticate with the authorization server
MUST do so according to section 3.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,” September 2011.</span><span>)</span></a> [OAuth.2.0]. OAuth defines an alternative
method for clients to authenticate with symmetric client keys
through the use of the <tt>client_id</tt> and
<tt>client_secret</tt> parameter in the message
request body. This specification extends the client authentication
scheme to allow clients to authenticate with asymmetric keys.
Asymmetric client authentication allows the client to authenticate
with the authorization server without sending its secret key. The
asymmetric client authentication parameters are the following:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>REQUIRED. The client identifier of the
client.
</dd>
<dt>secret_type</dt>
<dd>OPTIONAL. Specifies the client
authentication type which determines how the <tt>client_secret</tt> parameter is interpreted. It
can be one of "basic" or "JWT". The defaults value is "<tt>basic</tt>". If the value is "basic", the client
is performing symmetric key authentication as specified in OAuth
2.0. If the value is "JWT", the client is performing asymmetric
key authentication.
</dd>
<dt>client_secret</dt>
<dd>REQUIRED. The client secret. If the
secret_type is "<tt>basic</tt>", the value is
the pre-shared secret that was issued to the client during
client registration. If the "<tt>secret_type</tt>"
is "JWT", the value is the <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS]
signature of a JSON object containing one of the following
claims:
<blockquote class="text"><dl>
<dt>code</dt>
<dd>REQUIRED. The authorization code that was
issued by the authorization server.
</dd>
<dt>refresh_token</dt>
<dd>REQUIRED. The refresh token that
was issued.
</dd>
</dl></blockquote>
</dd>
</dl></blockquote>
<p>In addition to the client authentication parameters, the client
MUST send the request parameter for the Access Token endpoint as
specified 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,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>
</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,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>This specification further constrains that only <a class='info' href='#OAuth.2.0.Bearer'>Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] are issued at the
Token endpoint. The OAuth 2.0 response parameter "<tt>token_type</tt>" MUST be set to "<tt>Bearer</tt>".
</p>
<p>In addition to the OAuth 2.0 response parameters, the following
parameters MUST be included in the response if the Authorization
Request <tt>scope</tt> parameter contains
<tt>openid</tt>:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>id_token</dt>
<dd>The ID Token value associated with the
authentication session.
</dd>
</dl></blockquote>
<p>
</p>
<p>Following is a non-normative example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
}</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,” September 2011.</span><span>)</span></a> [OAuth.2.0], Clients
SHOULD ignore unrecognized response parameters.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.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,” September 2011.</span><span>)</span></a> [OAuth.2.0].
</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.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,” September 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="userinfo_ep"></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 is an OAuth 2.0 protected resource that
returns a claim object which contains 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="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.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 as described in Section 7.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,” September 2011.</span><span>)</span></a> [OAuth.2.0]. Access tokens sent in the
authorization header must be <a class='info' href='#OAuth.2.0.Bearer'>Bearer tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “OAuth 2.0 Protocol: Bearer Tokens,” September 2011.</span><span>)</span></a> [OAuth.2.0.Bearer].
</dd>
<dt>schema</dt>
<dd>REQUIRED. The schema in which the data is
be returned. The default value is <tt>openid</tt>. If the value of this parameter is
omitted, or not <tt>openid</tt>, 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 schema 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="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.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">user_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., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 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" />
<p>
</p>
<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="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.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,” September 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="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.4"></a><h3>3.3.4.
Claim Types</h3>
<p>The UserInfo endpoint MAY return a claim object containing 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="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.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="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.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,” September 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. If the access token
is not available, clients MAY need to retrieve the
access token out of band or use an a priori access
token that was negotiated between the claim source and
client, or the claim source MAY reauthenticate the
user and/or reauthorize the client.
</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>Claims Provider A contains the following claims for Jane Doe :
{
"address": "1234 Hollywood Blvd., Los Angeles, CA 90210",
"phone_number": "+1 (310) 123-4567"
}
Claims Provider A signs the JSON claims, resulting in a signed JWT:
jwt_header.jwt_part2.jwt_part3
Authorization Server returns Jane Doe's aggregated claims from Claims Provider A :
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"birthday": "01/01/2001",
"eye_color": "blue",
"email": "janedoe@example.com",
"_claim_names": {
"address": "src1",
"phone_number": "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>
Claims Provider A (Jane Doe's Bank) contains the following claims for Jane Doe :
{
"shipping_address": "1234 Hollywood Blvd., Los Angeles, CA 90210",
"payment_info": "Some_Card 1234 5678 90123 4562"
"phone_number": "+1 (310) 123-4567"
}
A Claims Provider B (Credit Agency) contains the following claims for Jane Doe :
{
"credit_score": "650"
}
Authorization Server returns Jane Doe's claims along with the distributed claims from
Claims Provider A and B by sending the access tokens and URL locations where the claims
may be retrieved.
{
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com",
"birthday": "01/01/2001",
"eye_color": "blue",
"_claim_names": {
"payment_info": "src1",
"shipping_address": "src1",
"credit_score": "src2"
},
"_claim_sources": {
"src1": {"endpoint": "https://bank.example.com/claimsource"},
"src2": {"endpoint": "https://creditagency.example.com/claimshere", "access_token": "ksj3n283dke"}
}
}
</pre></div><p>
</p>
<a name="check_id_ep"></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.
Check ID Endpoint</h3>
<p>The Check ID endpoint validates ID Tokens and 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>
<p>This endpoint can be used by clients that are not able to or do not
wish to handle ID Tokens. In such cases, clients MAY treat the ID
Token as an opaque value, and use the Check ID endpoint to
retrieve and examine the claims associated with the token.
</p>
<p>A full explanation of how to use an ID Token to perform session
management can be found in the <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,” September 2011.</span><span>)</span></a> [OpenID.Session].
</p>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4.1"></a><h3>3.4.1.
Check ID Request</h3>
<p>To request the information about the authentication performed on
the user, the following parameters are sent to the Check ID
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="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.4.2"></a><h3>3.4.2.
Check ID 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 <a class='info' href='#id_token'>ID Token<span> (</span><span class='info'>ID Token</span><span>)</span></a> claims.
</p>
<p>Other claims MAY be returned by specifying the desired ID Token
claims to be returned in an <a class='info' href='#OpenIDReq'>OpenID Request Object<span> (</span><span class='info'>OpenID Request Object</span><span>)</span></a> when making an
authorization request. The Check ID endpoint MUST return
claims in JSON format unless a request for a different format is
made by the client in the authorization request. The Check ID
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., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 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 Check ID
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 Check ID endpoint:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /id_token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-encoded
id_token=eyJ0eXAiOiJKV1QiL
HTTP/1.1 200 OK
Content-Type: application/json
{
"iss": "http://server.example.com",
"user_id": "248289761001",
"aud": "http://client.example.com",
"exp": 1311281970
}
</pre></div>
<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.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,” September 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="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.5"></a><h3>3.5.
Session Management Endpoints</h3>
<p>The Session Management 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,” September 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
parameters and values to the 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'>Raggett, D., Jacobs, I., and A. Hors, “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="sigenc"></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 messages 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 content.
</p>
<p>To achieve message confidentiality, OpenID Connect messages MAY use
<a class='info' href='#JWE'>JSON Web Encryption (JWE)<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Encryption,” July 2011.</span><span>)</span></a> [JWE] to encrypt the
content.
</p>
<p>When the message is both signed and
encrypted, it MUST be signed first then encrypted.
</p>
<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.1"></a><h3>5.1.
Signing</h3>
<p></p>
<blockquote class="text"><dl>
<dt>HMAC-SHA256 Signatures</dt>
<dd>
When using HMAC-SHA256 Signatures, <tt>
alg</tt> claim of the JWS header MUST be set to
<tt>HS256</tt>.
The <tt>client_secret</tt> MUST
be used as the signature key.
</dd>
<dt>RSA and ECDSA Signatures</dt>
<dd>
When using RSA-SHA256 or ECDSA-SHA256 Signatures,
<tt>alg</tt> MUST be set to
<tt>RS256</tt> and
<tt>ES256</tt> respectively.
As the key, either <tt>x5u</tt>
or <tt>x5t</tt> registered/obtained
MUST be used to retrieve the relevant key.
If there were multiple keys in <tt>jku</tt>,
<tt>kid</tt> MUST be specified in JWS header.
If there were multiple certificates in <tt>
x5u</tt>, then <tt>x5t</tt> MUST be
specified in JWS header.
The key usage of the respective keys MUST include signature.
</dd>
</dl></blockquote>
<a name="enc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Encryption</h3>
<p></p>
<blockquote class="text"><dl>
<dt>Using client_secret</dt>
<dd>
[tbd] To use client_secret to encrypt the payload,
Keywrap MUST be used.
</dd>
<dt>Asymmetric Encryption</dt>
<dd>
[tbd] .
As the key, either <tt>x5u</tt>
or <tt>x5t</tt> registered/obtained
MUST be used to retrieve the relevant key.
If there were multiple keys in <tt>jku</tt>,
<tt>kid</tt> MUST be specified in JWS header.
If there were multiple certificates in <tt>
x5u</tt>, then <tt>x5t</tt> MUST be
specified in JWS header.
The key usage of the respective keys MUST include signature.
</dd>
</dl></blockquote>
<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.6"></a><h3>6.
Verification</h3>
<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.6.1"></a><h3>6.1.
Authorization Request Verification</h3>
<p>If the request is signed, the authorization server MUST validate
the signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.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 response.
</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 Check ID Endpoint to validate the token.
</p>
<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.6.3"></a><h3>6.3.
Token Request Verification</h3>
<p>If the request is signed, the authorization server MUST validate
the signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</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.6.4"></a><h3>6.4.
Token Response Verification</h3>
<p>To verify the validity of the Token response, the client MUST do
the following:
</p>
<p></p>
<ol class="text">
<li>If the response is signed, the Client SHOULD validate the
signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</li>
<li>Check that current time is within the validity period 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="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.6.5"></a><h3>6.5.
UserInfo Request Verification</h3>
<p>If the request is signed, the authorization server MUST validate
the signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</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.6"></a><h3>6.6.
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 validate the
signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</li>
<li>Check that the OP that responded was really the intended OP
through a TLS/SSL server certificate check.
</li>
</ol>
<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.7"></a><h3>6.7.
Check ID Request Verification</h3>
<p>If the request is signed, the authorization server MUST validate
the signature according to Section 5 of <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” April 2011.</span><span>)</span></a> [JWS].
</p>
<p>The authorization server also MUST validate the request to ensure
all required parameters are present and valid.
</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.8"></a><h3>6.8.
Check ID Response Verification</h3>
<p>To verify the validity of the Response, the client MUST do 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>Verify that <tt>iss</tt> is a trusted issuer
of the response.
</li>
<li>If <tt>nonce</tt> is present, verify that
it is the same value as the one that was sent in the authorization
request.
</li>
<li>Check that the server that responded was really the intended
server through a TLS/SSL server certificate check.
</li>
</ol>
<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.7"></a><h3>7.
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.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,” September 2011.</span><span>)</span></a> [OpenID.Discovery] - Dynamic discovery for user and authorization 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,” September 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,” September 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,” September 2011.</span><span>)</span></a> [OpenID.Standard]
- Protocol binding for the full set of OpenID Connect Messages
</li>
<li><a class='info' href='#OpenID.Basic'>OpenID Connect Basic Client 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Basic Client 1.0,” September 2011.</span><span>)</span></a> [OpenID.Basic] -
Protocol binding for a subset of the OpenID Connect Messages
which is intended for use by basic 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.8"></a><h3>8.
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.8.1"></a><h3>8.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.8.2"></a><h3>8.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.8.3"></a><h3>8.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.8.4"></a><h3>8.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.8.5"></a><h3>8.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.8.6"></a><h3>8.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.8.7"></a><h3>8.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.8.8"></a><h3>8.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.8.9"></a><h3>8.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="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.8.10"></a><h3>8.10.
Timing Attack</h3>
<p>Timing attacks 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.8.11"></a><h3>8.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.9"></a><h3>9.
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.9.1"></a><h3>9.1.
OAuth Parameters Registry</h3>
<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.9.1.1"></a><h3>9.1.1.
Scope Parameters</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Parameter name: openid, profile, email, address, PPID
</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="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.1.2"></a><h3>9.1.2.
Authorization Request Parameter (display)</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: display
</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="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.9.1.3"></a><h3>9.1.3.
Authorization Request Parameter (prompt)</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: prompt
</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="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.9.1.4"></a><h3>9.1.4.
Authorization Request Parameter (nonce)</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: nonce
</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.9.1.5"></a><h3>9.1.5.
Authorization Request Parameter (audience)</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: audience
</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="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.9.1.6"></a><h3>9.1.6.
Authorization Request Parameter (request)</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: request
</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="anchor37"></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.7"></a><h3>9.1.7.
Authorization Request Parameter (request_uri)</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: request_uri
</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="anchor38"></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.8"></a><h3>9.1.8.
ID Token Response Parameters</h3>
<p>The following is the parameter registration request for the ID
Token Response in this specification:
</p>
<p></p>
<ul class="text">
<li>Parameter name: id_token
</li>
<li>Parameter usage location: Authorization Response, Access Token
Response
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[ this document ]]
</li>
<li>Related information: None
</li>
</ul>
<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.9.2"></a><h3>9.2.
OAuth Extensions Error Registry</h3>
<p>
</p>
<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.9.2.1"></a><h3>9.2.1.
Authorization endpoint error (invalid_request_redirect_uri)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: invalid_request_redirect_uri
</li>
<li>Error usage location: Authorization endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor41"></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.2"></a><h3>9.2.2.
Authorization endpoint error (login_required)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: login_required
</li>
<li>Error usage location: Authorization endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor42"></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.3"></a><h3>9.2.3.
Authorization endpoint error (session_selection_required)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: session_selection_required
</li>
<li>Error usage location: Authorization endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor43"></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.4"></a><h3>9.2.4.
Authorization endpoint error (approval_required)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: approval_required
</li>
<li>Error usage location: Authorization endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor44"></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.5"></a><h3>9.2.5.
Authorization endpoint error (user_mismatched)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: user_mismatched
</li>
<li>Error usage location: Authorization endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor45"></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.6"></a><h3>9.2.6.
Token endpoint error (invalid_authorization_code)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: invalid_authorization_code
</li>
<li>Error usage location: Token endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor46"></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.7"></a><h3>9.2.7.
UserInfo endpoint error (invalid_schema)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: invalid_schema
</li>
<li>Error usage location: UserInfo endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<a name="anchor47"></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.8"></a><h3>9.2.8.
Check ID endpoint error (invalid_id_token)</h3>
<p>The following is the parameter value registration request for the
"scope" parameter as defined in this specification:
</p>
<p></p>
<ul class="text">
<li>Error name: invalid_schema
</li>
<li>Error usage location: UserInfo endpoint
</li>
<li>Related protocol extension:
</li>
<li>Change controller: IETF
</li>
<li>Specification document(s): [[this document ]]
</li>
</ul>
<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.10"></a><h3>10.
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>10.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., Bradley, J., and N. Sakimura, “<a href="http://self-issued.info/docs/draft-jones-json-web-encryption.html">JSON Web Encryption</a>,” July 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>,” September 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>,” September 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.Basic">[OpenID.Basic]</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-basic-1_0.html">OpenID Connect Basic Client 1.0</a>,” September 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>,” September 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</a>,” September 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>,” September 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>,” September 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">Raggett, D., Jacobs, I., and A. Hors, “<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>10.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="anchor50"></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 20.
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>Michael B. Jones (mbj@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="anchor51"></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>-05</p>
<ul class="text">
<li>Changed check_session to check_id.
</li>
<li>schema=openid now required when requesting UserInfo.
</li>
<li>Removed issued_to, since not well defined.
</li>
<li>Removed display values popup, touch, and mobile, since not well defined.
</li>
</ul>
<p>-04 </p>
<ul class="text">
<li>Changes associated with renaming "Lite" to "Basic Client"
and replacing "Core" and "Framework" with "Messages" and
"Standard".
</li>
<li>Numerous cleanups, including updating references.
</li>
</ul>
<p>-03 </p>
<ul class="text">
<li>Added secret_type to the Token endpoint.
</li>
<li>Minor edits to the samples.
</li>
</ul>
<p>-02 </p>
<ul class="text">
<li>Incorporates feedback from Nat Sakimura.
</li>
</ul>
<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</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>