<!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 Basic
    Client 1.0 - draft 12</title>
<meta http-equiv="Expires" content="Mon, 19 Sep 2011 18:03:33 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Basic
    Client 1.0 - draft 12">
<meta name="generator" content="xml2rfc v1.34 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">N. Sakimura, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley, Ed.</td></tr>
<tr><td class="header"> </td><td class="header">Independent</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">C. Mortimore</td></tr>
<tr><td class="header"> </td><td class="header">Salesforce</td></tr>
<tr><td class="header"> </td><td class="header">September 6, 2011</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Basic
    Client 1.0 - draft 12</h1>

<h3>Abstract</h3>

<p>OpenID Connect 1.0 is a simple identity layer on top of OAuth 2.0
      protocol. It allows a web site to verify the identity of the user based
      on the authentication performed by the authorization server, as well as to
      obtain basic profile information about the user in an interoperable and 
      RESTful manner.
</p>
<p>OpenID Connect Basic Client is a profile of the OpenID Connect
      Standard 1.0 Specification that is designed to be easy to read and 
      implement for Relying Parties. OpenID Providers should consult the 
      main specification. This profile omits implementation and security
      considerations for OpenID Providers.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#rnc">1.</a> 
Requirements Notation and Conventions<br />
<a href="#terminology">2.</a> 
Terminology<br />
<a href="#anchor1">3.</a> 
Protocol Flows<br />
    <a href="#anchor2">3.1.</a> 
OpenID Connect Scopes<br />
    <a href="#anchor3">3.2.</a> 
Implicit Flow<br />
        <a href="#rf_prep">3.2.1.</a> 
Client Prepares an Authorization Request<br />
        <a href="#implicit_req">3.2.2.</a> 
Client Sends a Request to the Authorization Server<br />
        <a href="#anchor4">3.2.3.</a> 
Authorization Server Obtains the End-User Consent/Authorization<br />
        <a href="#implicit_res">3.2.4.</a> 
Authorization Server Sends the End-User Back to the Client<br />
    <a href="#anchor5">3.3.</a> 
Check ID Endpoint<br />
        <a href="#anchor6">3.3.1.</a> 
Check ID Request<br />
        <a href="#anchor7">3.3.2.</a> 
Check ID Response<br />
        <a href="#anchor8">3.3.3.</a> 
Error Codes<br />
        <a href="#verification">3.3.4.</a> 
Verification<br />
<a href="#userinfo">4.</a> 
UserInfo Endpoint<br />
    <a href="#anchor11">4.1.</a> 
Requesting UserInfo<br />
    <a href="#id_res">4.2.</a> 
Client Receives UserInfo Response<br />
        <a href="#anchor12">4.2.1.</a> 
Error Response<br />
<a href="#disco_reg">5.</a> 
Discovery and Registration<br />
<a href="#qss">6.</a> 
Query String Serialization<br />
<a href="#security_considerations">7.</a> 
Security Considerations<br />
    <a href="#assertion_manufacture">7.1.</a> 
Assertion Manufacture/Modification<br />
    <a href="#assertion_disclosure">7.2.</a> 
Assertion Disclosure<br />
    <a href="#assertion_redirect">7.3.</a> 
Assertion Redirect<br />
    <a href="#assertion_reuse">7.4.</a> 
Assertion Reuse<br />
    <a href="#assertion_substitution">7.5.</a> 
Assertion Substitution<br />
    <a href="#auth_req_disclosure">7.6.</a> 
Authentication Request Disclosure<br />
    <a href="#authn_proc_threats">7.7.</a> 
Authentication Process Threats<br />
    <a href="#anchor13">7.8.</a> 
Implicit Flow Threats<br />
    <a href="#anchor14">7.9.</a> 
Availability<br />
<a href="#privacy_considerations">8.</a> 
Privacy Considerations<br />
<a href="#IANA">9.</a> 
IANA Considerations<br />
<a href="#rfc.references1">10.</a> 
Normative References<br />
<a href="#anchor16">Appendix A.</a> 
Acknowledgements<br />
<a href="#anchor17">Appendix B.</a> 
Document History<br />
<a href="#rfc.authors">§</a> 
Authors' Addresses<br />
</p>
<br clear="all" />

<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1. 
Requirements Notation and Conventions</h3>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> .
</p>
<p>Throughout this document, values are quoted to indicate that they are
      to be taken literally. When using these values in protocol messages, the
      quotes MUST NOT be used as part of the value.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2. 
Terminology</h3>

<p>The following definitions define additional terminology used in this
      specification in addition to those defined in <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,” July 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Relying Party (RP)</dt>
<dd>An application requiring identity
          information from an OpenID Provider.
</dd>
<dt>OpenID Provider (OP)</dt>
<dd>A service capable of providing
          identity information to a Relying Party.
</dd>
<dt>Assertion</dt>
<dd>A set of Claims about the End-User that are
          attested to by the OpenID Provider and Resource Servers.
</dd>
<dt>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>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 information about the
          authentication event. It is a signed token, but can be treated as
          opaque by clients that uses the Check ID Endpoint. Relying 
          Parties wanting to process the token directly should refer to the 
          OpenID Connect Standard 1.0 specification.
</dd>
<dt>Check ID Endpoint</dt>
<dd>A protected resource that, when
          presented with an ID Token by the client, returns authentication
          information about the user 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.3"></a><h3>3. 
Protocol Flows</h3>

<p>Authorization requests follow two paths; the implicit flow
      and the authorization code flow. The authorization code flow is
      suitable for clients that can securely maintain a client secret between
      itself and the authorization server whereas the implicit flow is
      suitable for clients that cannot. Clients that do not support TLS MUST
      use the authorization code flow to prevent the interception of access 
      tokens.
</p>
<p>The OpenID Connect Basic Client profile only documents clients using
      the implicit flow. OpenID Providers MUST support both flows.
      Clients wanting to use the authorization code flow and OpenID Providers 
      should consult the OpenID Connect Standard 1.0 specification.
</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.1"></a><h3>3.1. 
OpenID Connect Scopes</h3>

<p>This profile describes two OpenID Connect endpoints that the client
        may request scopes for.
</p>
<p>The scopes request what information is to be made available from
        each of the endpoints for the current user. The User may decline a
        scope request by the client.
</p>
<p>To increase conversion, a site may elect to only request a subset
        of the information from the User Info endpoint.
</p>
<p>OpenID Connect uses scopes as defined in 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,” July 2011.</span><span>)</span></a> [OAuth.2.0].
</p>
<p>The Check ID Endpoint has a single scope</p>
<blockquote class="text"><dl>
<dt>openid</dt>
<dd>REQUIRED. Requests the user_id and other
            session information.
</dd>
</dl></blockquote>

<p>The User Info Endpoint scopes are:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>profile</dt>
<dd>OPTIONAL requests default profile
            information.
</dd>
<dt>email</dt>
<dd>OPTIONAL requests an email address.
</dd>
<dt>address</dt>
<dd>OPTIONAL requests an address.
</dd>
</dl></blockquote>

<p>These scopes are additive if a RP wanted the default profile
        including email and address they would request:
</p>
<p>
<p>The following is a non-normative example of a Scope
            Request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>scope=openid profile email phone</pre></div>

<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.2"></a><h3>3.2. 
Implicit Flow</h3>

<p>The implicit flow consists of the following steps:
</p>
<p></p>
<ol class="text">
<li>Client Prepares an Authorization Request containing the desired
            request parameters.
</li>
<li>Client sends a request to the Authorization Server.
</li>
<li>Authorization Server Authenticates the End-User.
</li>
<li>Authorization Server Obtains the End-User
            Consent/Authorization.
</li>
<li>Authorization Server Sends the End-User back to the Client with
            an Access Token and ID Token.
</li>
</ol>

<a name="rf_prep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.1"></a><h3>3.2.1. 
Client Prepares an Authorization Request</h3>

<p>When the user wishes to access a Protected Resource, and the
          End-User Authorization has not yet been obtained, the Client
          prepares an Authorization Request to the authorization endpoint.
</p>
<p>The scheme used in the Authorization URL MUST be HTTPS.
</p>
<p>This profile further constrains the following request
          parameters:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>It MUST include <tt>token and id_token</tt>,
              as a space separated list. This requests both an access token
              and id_token to be returned in the URL fragment of the
              response.
</dd>
</dl></blockquote>

<p>Other REQUIRED parameters in the request include the
          following:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>The OAuth client identifier.
</dd>
<dt>scope</dt>
<dd>It MUST include <tt>openid</tt>
              as one of the space separated strings. Optional scope strings of
              <tt>profile</tt>, <tt>email</tt>,
              and <tt>address</tt> are also supported.
</dd>
<dt>redirect_uri</dt>
<dd>A redirection URI where the response
              will be sent. This MUST be pre-registered with the provider.
</dd>
<dt>nonce</dt>
<dd>A random, unique string value used to
              mitigate the replay attack this value is returned from the Check
              ID Endpoint.
</dd>
</dl></blockquote>

<p>The request MAY contain the following optional parameters:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>state</dt>
<dd>RECOMENDED. An opaque value used to maintain
              state between the request and the callback, used to protect
              against XSRF attacks.
</dd>
<dt>display</dt>
<dd>A string value used to convey desired
              display format. The value are either <tt>none</tt>,
              <tt>popup</tt>, <tt>touch</tt>,
              or <tt>mobile</tt>.
</dd>
<dt>prompt</dt>
<dd>A space delimited list that can contain
              <tt>login</tt>, <tt>consent</tt>,
              and <tt>select_account</tt>. It is used to
              control the dialogue that is to be shown to the user upon the
              request.
</dd>
</dl></blockquote>

<p>Authorization servers MUST support the use of the HTTP <tt>GET</tt> method as defined in <a class='info' href='#RFC2616'>RFC 2616<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> [RFC2616] and MAY support the <tt>POST</tt> method at the authorization endpoint.
</p>
<p>If using the HTTP <tt>GET</tt> method, the
          parameters are serialized using <a class='info' href='#qss'>Query String 
          Serialization<span> (</span><span class='info'>Query String Serialization</span><span>)</span></a>. If using the HTTP <tt>POST
          </tt> method, the request parameters are added to the HTTP request 
          entity-body 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., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
</p>
<p>The following is a non-normative example of an
            Authorization Request URL. Note that the line wraps within the
            values are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj</pre></div>
<a name="implicit_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.2.2"></a><h3>3.2.2. 
Client Sends a Request to the Authorization Server</h3>

<p>Having constructed the Authorization Request, the client sends it
          to the Authorization Endpoint. This MAY happen via HTTPS redirect, 
          hyperlinking, or any other secure means of directing the User-Agent 
          to the URL.
</p>
<p>Following is a non-normative example using HTTP redirect. Note:
          Line wraps are for display purpose only.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&state=af0ifjsldkj
</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.2.3"></a><h3>3.2.3. 
Authorization Server Obtains the End-User Consent/Authorization</h3>

<p>The Authorization Server MUST obtain an authorization decision,
          for the requested scopes. This MAY be done by presenting the user
          with a dialogue that allows the user to recognize what he is
          consenting to and obtain his consent or by establishing approval via
          other means (for example, via previous administrative approval).
</p>
<p>The <tt>openid</tt> scope grants the RP access
          to the user identifier of the authenticated user of the session.
</p>
<p>All other scopes are optional. It is up to the OpenID Provider
          to determine if an error should be returned in the case of the user 
          declining to authorize scopes other than 
          <tt>openid</tt>.
</p>
<a name="implicit_res"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.4"></a><h3>3.2.4. 
Authorization Server Sends the End-User Back to the Client</h3>

<p>Once the authorization is determined, the Authorization Server
          returns a positive or negative response.
</p>
<a name="implicit_ok"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.4.1"></a><h3>3.2.4.1. 
End-User Grants Authorization</h3>

<p>If the resource owner grants the access request, the
            authorization server issues an access token and delivers it to the
            client by adding the following parameters to the fragment
            component of the redirection URI using the 
            <tt>application/x-www-form-urlencoded</tt>
            format as 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,” July 2011.</span><span>)</span></a> [OAuth.2.0]
</p>
<p>In the implicit flow, the entire response is returned in the
            fragment component of the redirect URL, as defined in 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,” July 2011.</span><span>)</span></a> [OAuth.2.0]
</p>
<p></p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access Token for the
                User Info Endpoint.
</dd>
<dt>token_type</dt>
<dd>REQUIRED. The value MUST be
                "bearer"
</dd>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token for the
                Check ID Endpoint.
</dd>
<dt>state</dt>
<dd>REQUIRED if the <tt>state</tt>
                parameter is present in the request. It MUST be set to the
                exact value of the <tt>state</tt> parameter
                received from the client in the authorization request.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The expiration time in
                seconds of the access_token
</dd>
</dl></blockquote>

<p>The client can then use the Access Token to access protected
            resources at Resource Servers.
</p>
<p>The following is a non-normative example. Line wraps
              after the second line is for the display purpose
              only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://client.example.com/#
access_token=SlAV32hkKG&
token_type=bearer&
id_token=1234567.SlAV32hkKG.abcde1234&
expires_in=3600&
&state=af0ifjsldkj</pre></div>
<a name="implicit_authz_error"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2.4.2"></a><h3>3.2.4.2. 
End-User Denies Authorization or Invalid Request</h3>

<p>If the user denies the authorization or the user authentication
            fails, the authorization server MUST return the negative 
            authorization response as defined in 4.2.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,” July 2011.</span><span>)</span></a> [OAuth.2.0]. No other parameters 
            SHOULD be returned.
</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.3"></a><h3>3.3. 
Check ID Endpoint</h3>

<p>The Check ID Endpoint validates the id_token and returns a
        text <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 associated with the supplied
        id-token.
</p>
<p>The id_token is used to manage the signon event and user
        identifier, separately from access to the UserInfo Endpoint and other
        OAuth 2.0 protected resources that the user is granting access to. The
        id_token is audience restricted to a particular client via the audience 
        and nonce.
</p>
<p>A full explanation of how to use the 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'>de Medeiros, B., “OpenID Connect Session Management 1.0,” September 2011.</span><span>)</span></a> [OpenID.Session]
</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.3.1"></a><h3>3.3.1. 
Check ID Request</h3>

<p>To request the information about the authentication performed on
          the user, the following listed parameters are sent to the Check ID
          Endpoint.
</p>
<p>The paramaters MAY be passed as query paramaters in a GET or as
          form encoded in a POST.
</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>
<p><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>Request:

GET /op/check_id?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

Host: server.example.com


</pre></div>

<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3.2"></a><h3>3.3.2. 
Check ID Response</h3>

<p>The response is a text <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
          using the <tt>application/json</tt> media type
          with the following parameters.
</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 client_id 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>REQUIRED. It MUST be set to the
              exact value of the <tt>nonce</tt> parameter
              received from the client in the authorization request.
</dd>
</dl></blockquote>

<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>Request:

GET /op/check_id?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

Host: server.example.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
"iss": "http://server.example.com",
"user_id": "Jane Doe",
"aud": "http://client.example.net",
"exp":1311281970
}
</pre></div>
<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.3.3"></a><h3>3.3.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,” July 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, malformed, is in an incorrect format, or
              expired.
</dd>
</dl></blockquote>

<a name="verification"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.3.4"></a><h3>3.3.4. 
Verification</h3>

<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.3.4.1"></a><h3>3.3.4.1. 
Request Verification</h3>

<p>The authorization server validates the request to ensure all
            required parameters are present and valid.
</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.3.4.2"></a><h3>3.3.4.2. 
Response Verification</h3>

<p>To verify the validity of the Response, the client MUST to the
            following:
</p>
<p></p>
<ol class="text">
<li>Check that the returned nonce is equal to the nonce in the
                Authorization Request.
</li>
<li>Verify that the response was intended for the recipient,
                using the <tt>aud</tt> (audience) contained
                within the response.
</li>
<li>If <tt>issued_to</tt> is present then it
                MUST contain an identifier for a trusted intermediary. If
                <tt>issued_to </tt>is unknown then the
                assertion MUST be rejected.
</li>
<li>Check that the authorization server that responded was really
                the intended authorization server through a TLS/SSL server 
                certificate check.
</li>
<li>The Check ID Endpoint has not returned an error for
                the ID Token being expired or invalid.
</li>
</ol>

<a name="userinfo"></a><br /><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. 
UserInfo Endpoint</h3>

<p>To obtain the additional attributes and tokens, the client makes a
      GET or POST request to the UserInfo Endpoint.
</p>
<p>NOTE: The UserInfo Endpoint response is not guaranteed to be about the
      Subject in the session. Therefore, it MUST NOT be used as an assertion
      about the user in the session unless the user_id matches the user_id in
      the ID Token.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1. 
Requesting UserInfo</h3>

<p>Clients MAY send requests with the following parameters to the
        UserInfo Endpoint to obtain further information about the user. The
        UserInfo Endpoint is an <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,” July 2011.</span><span>)</span></a> [OAuth.2.0]
        protected resource that complies with the <a class='info' href='#OAuth.2.0.Bearer'>Bearer Token<span> (</span><span class='info'>Jones, M., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol: Bearer Tokens,” July 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] specification. As such,
        the access token SHOULD be specified via the HTTP Authorization
        header.
</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
            only be sent using one method through either HTTP Authorization
            header or query string.
</dd>
<dt>schema</dt>
<dd>OPTIONAL. The schema in which the data is to
            be returned. The only predefined value is <tt>openid</tt>.
            If this parameter is not included, the response may be a
            proprietary schema to support backwards compatibility. A URL MAY
            be passed to define custom schemes not specified by short names.
            Custom 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>

<p>The following is a non-normative example. Line wraps are
          for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /userinfo HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT
</pre></div>
<a name="id_res"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2. 
Client Receives UserInfo Response</h3>

<p>If the requested schema is <tt>openid</tt>, the
        response MUST return a plain text <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 that contains a set of members that are a subset of those
        defined below. Additional members (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>Following is a non-normative example of such
          response:
</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>
<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.4.2.1"></a><h3>4.2.1. 
Error Response</h3>

<p>When some error condition arises, the UserInfo Endpoint returns
          the Error Response. In addition to the standard <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,” July 2011.</span><span>)</span></a> [OAuth.2.0] errors, the UserInfo Endpoint
          may return the following errors:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>unsupported_schema</dt>
<dd>The requested schema is
              unsupported.
</dd>
</dl></blockquote>

<a name="disco_reg"></a><br /><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. 
Discovery and Registration</h3>

<p>Some OpenID Connect installations can use a pre-configured set of
      OpenID Providers and/or Relying Parties. In those cases, it may not be
      necessary to support dynamic discovery of information about identities
      or services or dynamic registration of clients.
</p>
<p>However, if installations choose to support unanticipated
      interactions between Relying Parties and OpenID Providers that do not
      have pre-configured relationships, they SHOULD accomplish this by
      implementing the facilities defined in the <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] and <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] specifications.
</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.6"></a><h3>6. 
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., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
</p>
<p>Following is a non-normative example of such
        serialization:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com</pre></div>
<a name="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.7"></a><h3>7. 
Security Considerations</h3>

<p>In addition to the Security Considerations in <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,” July 2011.</span><span>)</span></a> [OAuth.2.0], the following are the list of 
      threats and remedies that were considered for this specification.
</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.7.1"></a><h3>7.1. 
Assertion Manufacture/Modification</h3>

<p>An assertion is the result of the authentication performed by the
        authorization server that was provided to the client. The assertion is 
        used to pass information about the user or the authentication process 
        from the authorization server to the client.
</p>
<p></p>
<ol class="text">
<li>To mitigate this attack, 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 authorization 
            server MUST be authenticated. In this specification, the assertion 
            is always sent over TLS/SSL protected channel.
</li>
</ol>

<p>For details of the threat, 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_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.7.2"></a><h3>7.2. 
Assertion Disclosure</h3>

<p>This profile is subject to assertion disclosure in the user's
        browser, if it is compromised. Other OpenID Connect profiles should be
        used if this threat needs to be mitigated.
</p>
<p>For details of the threat, 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_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.7.3"></a><h3>7.3. 
Assertion Redirect</h3>

<p>To mitigate this threat, the assertion includes the identity of the
        client for whom it was generated as <tt>client_id</tt>.
        The client verifies that incoming assertions include its identity as
        the recipient of the assertion.
</p>
<p>For details of the threat, 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_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.7.4"></a><h3>7.4. 
Assertion Reuse</h3>

<p>The assertion includes a timestamp and a short lifetime of
        validity. The client checks the timestamp and lifetime values to
        ensure that the assertion is currently valid.
</p>
<p>The use of a nonce in the request is RECOMMENDED. The response from
        the Check ID Endpoint contains the nonce sent in the authorization
        request. This SHOULD be checked against a list of already received ID
        assertions to check for replays.
</p>
<p>For details of the threat, 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_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.7.5"></a><h3>7.5. 
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>
<p>For details of the threat, 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="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.7.6"></a><h3>7.6. 
Authentication Request Disclosure</h3>

<p>Since the authentication request is sent over a protected channel,
        the disclosure may only happen at the User-Agent where the information
        is decrypted.
</p>
<p>For details of the threat, 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="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.7.7"></a><h3>7.7. 
Authentication Process Threats</h3>

<p>In the category of Authentication Process Threats, the following
        threats exist:
</p>
<p></p>
<ul class="text">
<li>Online Guessing
</li>
<li>Phishing
</li>
<li>Pharming
</li>
<li>Eavesdropping
</li>
<li>Replay
</li>
<li>Session Hijacking
</li>
<li>Man-in-the-Middle
</li>
</ul><p> The authentication process, per se, as described in <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> is out of scope for this protocol, but care
        SHOULD be taken to achieve appropriate protection.
</p>
<p>For details of the threat, 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="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.7.8"></a><h3>7.8. 
Implicit Flow Threats</h3>

<p>In the implicit flow, the access token is returned in the
        fragment part of the client's redirect_uri through HTTPS. Thus it is
        protected between the Authorization Server and the User-Agent, and 
        User-Agent and the Client. The 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 malware.
</p>
<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.7.9"></a><h3>7.9. 
Availability</h3>

<p>When the authorization server is down, users will likely be unable 
        to access it. To mitigate this risk, the client SHOULD allow users to
        associate multiple authorization servers.
</p>
<a name="privacy_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. 
Privacy Considerations</h3>

<p>The UserInfo response typically contains Personally Identifiable
      Information. As such, user consent for the release of the information
      for the specified purpose SHOULD be obtained at or prior to the
      authorization time in accordance with relevant regulations. The purpose
      of use is typically registered in association with the <tt>redirect_uri</tt>.
</p>
<p>Only necessary UserInfo data should be stored at the client and the
      client SHOULD associate the received data with the purpose of use
      statement.
</p>
<p>The Resource Server SHOULD make the UserInfo access log available to 
      the user so that the user can monitor who accessed his data.
</p>
<p>To protect the user from a possible correlation among clients, the
      use of a Pairwise Pseudonymous Identifier (PPID) as the <tt>user_id</tt> SHOULD be considered.
</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>

<p>This document makes no request of IANA.
</p>
<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. 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="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>,” July 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., Ed., Recordon, D., and D. Hardt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer">The OAuth 2.0 Protocol: Bearer Tokens</a>,” July 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Discovery">[OpenID.Discovery]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., and E. Jay, “<a href="http://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Connect Discovery 1.0</a>,” 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"><a href="mailto:breno@google.com">de Medeiros, B.</a>, “<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="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text"><a href="mailto:fielding@ics.uci.edu">Fielding, R.</a>, <a href="mailto:jg@w3.org">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com">Mogul, J.</a>, <a href="mailto:frystyk@w3.org">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com">Leach, P.</a>, and <a href="mailto:timbl@w3.org">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc2616.pdf">PDF</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2616.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2616.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="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-Draft3_June2011.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., Hors, A., and I. Jacobs, “<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="zoneinfo">[zoneinfo]</a></td>
<td class="author-text">Public Domain, “<a href="http://www.twinsun.com/tz/tz-link.htm">The tz database</a>,” June 2011.</td></tr>
</table>

<a name="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.A"></a><h3>Appendix A. 
Acknowledgements</h3>

<p>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>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
</p>
<p>Casper Biering (cb@peercraft.com), Peercraft
</p>
<p>John Bradley (jbradely@mac.com), Protiviti Government
          Services
</p>
<p>Breno de Medeiros (breno@gmail.com), Google
</p>
<p>George Fletcher (gffletch@aol.com), AOL
</p>
<p>Edmund Jay (ejay@mgi1.com), MGI1
</p>
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
</p>
<p>Chuck Mortimore (cmortimore@salesforce.com), Salesforce
</p>
<p>Hideki Nara (hideki.nara@gmail.com), Takt Communications
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp)), Nomura Research Institute,
          Ltd.
</p>
<p>Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan
</p>
</blockquote>

<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B. 
Document History</h3>

<p>[[ To be removed from the final specification ]]
</p>
<p>-12</p>
<ul class="text">
<li>Ticket #48 Changed Check Session to take the id_token as a
          paramater.
</li>
</ul>

<p>-11 </p>
<ul class="text">
<li>Renamed from "Lite" to "Basic Client".
</li>
<li>Numerous cleanups, including updating references.
</li>
</ul>

<p>-10 </p>
<ul class="text">
<li>Add back id_token to the response type per issue 27.
</li>
<li>Changed endpoint name in example from id_token to
          check_session.
</li>
<li>Added token_type to the response and explanations of the optional
          parameters.
</li>
</ul>

<p>-09 </p>
<ul class="text">
<li>Clean up typos.
</li>
<li>Clean up scope explanation.
</li>
<li>Fix 3.2.4.1 to include id_token in response.
</li>
</ul>

<p>-08 </p>
<ul class="text">
<li>Added note about OP needing to read the full spec.
</li>
<li>Reverted back to GET for introspection based on Google
          feedback.
</li>
<li>Changed scopes to <tt>openid</tt>, <tt>profile</tt>, <tt>address</tt>,
          and <tt>email</tt> to make them additive.
</li>
<li>Changed introspection to Check Session Endpoint to be consistent
          with session management.
</li>
<li>Changed validation rules, the Check session endpoint will return
          an error for expired or invalid tokens, so the client doesn't need
          to check expiration.
</li>
<li>Added explanation of why an id_token is used to verify identity
          rather than the user_info access token.
</li>
</ul>

<p>-07 </p>
<ul class="text">
<li>Changed introspection to post
</li>
<li>Changed user_info from <tt>ide</tt> to <tt>user_ide</tt> to be consistent with introspection
          endpoint.
</li>
<li>Fixed introspection example to use id_token rather than access
          token.
</li>
<li>Removed asking for id_token in response type.
</li>
<li>Fixed Sec 3 to be clear it is client secret that is maintained
          between the client and the OP.
</li>
</ul>

<p>-06 </p>
<ul class="text">
<li>Only require the <tt>token</tt> flow in Lite.
          Removed <tt>code</tt> flow.
</li>
<li>Make <tt>id_token</tt> required. The <tt>id_token</tt> is treated as opaque.
</li>
<li>Rearranged sections for readability.
</li>
<li>Dropped the <tt>schema</tt> parameter to the
          Introspection endpoint, which was formerly a string with the value
          <tt>user_id</tt>. This is unnecessary since the
          <tt>id_token</tt> parameter already can be used
          to disambiguate the intended uses(s) of the endpoint.
</li>
<li>Dropped the requested audience from the Lite spec, which was
          formerly the identifier of the target audience of the response. This
          could be part of the Standard spec, but is an advanced scenario, and
          so not appropriate for Lite.
</li>
<li>Reference the Discovery and Registration specs, since they're
          needed for interaction between non-pre-configured parties (so that
          OpenID Connect installations can be Open).
</li>
</ul>

<p>-05 </p>
<ul class="text">
<li>Corrected issues raised by Casper Biering.
</li>
<li>Created the OpenID Connect Lite specification.
</li>
</ul>

<p>-04 </p>
<ul class="text">
<li>Correct issues raised by Pam Dingle and discussed on the mailing
          list after the 7-Jul-11 working group call.
</li>
<li>Adopted long_names.
</li>
</ul>

<p>-03 </p>
<ul class="text">
<li>Correct issues raised by Johnny Bufu and discussed on the
          7-Jul-11 working group call.
</li>
</ul>

<p>-02 </p>
<ul class="text">
<li>Consistency and cleanup pass, including removing unused
          references.
</li>
</ul>

<p>-01 </p>
<ul class="text">
<li>Initial draft
</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">John Bradley (editor)</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Independent</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</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>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Chuck Mortimore</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Salesforce</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a></td></tr>
</table>
</body></html>