<!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 Implicit 
    Client Profile 1.0 - draft 02</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect Implicit 
    Client Profile 1.0 - draft 02">
<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</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</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">B. de Medeiros</td></tr>
<tr><td class="header"> </td><td class="header">Google</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">E. Jay</td></tr>
<tr><td class="header"> </td><td class="header">Illumila</td></tr>
<tr><td class="header"> </td><td class="header">July 23, 2012</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect Implicit 
    Client Profile 1.0 - draft 02</h1>

<h3>Abstract</h3>

<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
      protocol. It allows Clients to verify the identity of the End-User based
      on the authentication performed by an Authorization Server, as well as to
      obtain basic profile information about the End-User in an interoperable and 
      RESTful manner.
</p>
<p>OpenID Connect Implicit Client Profile is a profile of the 
      OpenID Connect Standard 1.0 Specification
      that is designed to be easy to read and implement for basic
      web-based Relying Parties using the OAuth implicit grant type.
      OpenID Providers should consult the Standard 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="#anchor1">1.</a> 
Introduction<br />
    <a href="#rnc">1.1.</a> 
Requirements Notation and Conventions<br />
    <a href="#terminology">1.2.</a> 
Terminology<br />
<a href="#anchor2">2.</a> 
Protocol Flows<br />
    <a href="#anchor3">2.1.</a> 
OpenID Connect Scopes<br />
    <a href="#anchor4">2.2.</a> 
Implicit Flow<br />
        <a href="#rf_prep">2.2.1.</a> 
Client Prepares an Authorization Request<br />
        <a href="#implicit_req">2.2.2.</a> 
Client sends a request to the Authorization Server<br />
        <a href="#anchor5">2.2.3.</a> 
Authorization Server Authenticates the End-User<br />
        <a href="#anchor6">2.2.4.</a> 
Authorization Server Obtains the End-User Consent/Authorization<br />
        <a href="#implicit_res">2.2.5.</a> 
Authorization Server Sends the End-User Back to the Client<br />
            <a href="#implicit_ok">2.2.5.1.</a> 
End-User Grants Authorization<br />
            <a href="#implicit_authz_error">2.2.5.2.</a> 
End-User Denies Authorization or Invalid Request<br />
            <a href="#implicit_callback">2.2.5.3.</a> 
Example Redirect URI response<br />
    <a href="#id_token">2.3.</a> 
ID Token<br />
    <a href="#id.token.verification">2.4.</a> 
ID Token Verification<br />
    <a href="#userinfo">2.5.</a> 
UserInfo Endpoint<br />
        <a href="#anchor7">2.5.1.</a> 
UserInfo Request<br />
        <a href="#id_res">2.5.2.</a> 
UserInfo Response<br />
            <a href="#address_claim">2.5.2.1.</a> 
Address Claim<br />
            <a href="#claim.stability">2.5.2.2.</a> 
Claim Stability and Uniqueness<br />
        <a href="#anchor8">2.5.3.</a> 
UserInfo Error Response<br />
<a href="#self_issued">3.</a> 
Self Issued Identity Provider<br />
    <a href="#self_issued.discovery">3.1.</a> 
Self Issued Identity Provider Discovery<br />
    <a href="#self_issued.registration">3.2.</a> 
Client Registration to Self Issued Identity Provider<br />
    <a href="#self_issued.request">3.3.</a> 
Self Issued Identity Provider Request<br />
    <a href="#self_issued.response">3.4.</a> 
Self Issued Identity Provider Response<br />
    <a href="#self_issued.verification">3.5.</a> 
Self Issued Identity ID Token Verification<br />
<a href="#disco_reg">4.</a> 
Discovery and Registration<br />
<a href="#qss">5.</a> 
Query String Serialization<br />
<a href="#form_serialization">6.</a> 
Form Serialization<br />
<a href="#stringops">7.</a> 
String Operations<br />
<a href="#security_considerations">8.</a> 
Security Considerations<br />
<a href="#privacy_considerations">9.</a> 
Privacy Considerations<br />
<a href="#IANA">10.</a> 
IANA Considerations<br />
<a href="#rfc.references1">11.</a> 
References<br />
    <a href="#rfc.references1">11.1.</a> 
Normative References<br />
    <a href="#rfc.references2">11.2.</a> 
Informative References<br />
<a href="#anchor11">Appendix A.</a> 
Acknowledgements<br />
<a href="#anchor12">Appendix B.</a> 
Notices<br />
<a href="#anchor13">Appendix C.</a> 
Document History<br />
<a href="#rfc.authors">§</a> 
Authors' Addresses<br />
</p>
<br clear="all" />

<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.1"></a><h3>1. 
Introduction</h3>

<p>OpenID Connect Implicit Client Profile is a profile of the 
      <a class='info' href='#OpenID.Standard'>OpenID Connect Standard 1.0 Specification<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 2012.</span><span>)</span></a> [OpenID.Standard]
      that is designed to be easy to read and implement for basic
      web-based Relying Parties using the OAuth implicit grant type.
      See the
      <a class='info' href='#OpenID.Basic'>OpenID Connect Basic Client Profile<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” June 2012.</span><span>)</span></a> [OpenID.Basic]
      specification for a related profile for basic
      web-based Relying Parties using the OAuth code grant type.
      OpenID Providers and non web-based applications
      should consult the Standard specification.
      This profile omits implementation and security
      considerations for OpenID Providers.
</p>
<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.1"></a><h3>1.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.1.2"></a><h3>1.2. 
Terminology</h3>

<p>
          This specification uses 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" defined by <a class='info' href='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0].
          This specification also defines the following terms:
          </p>
<blockquote class="text"><dl>
<dt>Relying Party (RP)</dt>
<dd>
              Application requiring Claims from an OpenID Provider
            
</dd>
<dt>OpenID Provider (OP)</dt>
<dd>
              Service capable of providing Claims to a Relying Party
            
</dd>
<dt>Claim</dt>
<dd>
              Piece of information about an Entity that a Claims Provider
              asserts about that Entity 
            
</dd>
<dt>Claims Provider</dt>
<dd>
              Server that can return Claims about an Entity 
            
</dd>
<dt>End-User</dt>
<dd>
              Human Resource Owner
            
</dd>
<dt>Entity</dt>
<dd>
              Something that has a separate and distinct existence and that can be
              identified in a context. An End-User is one example of an Entity 
            
</dd>
<dt>Personally Identifiable Information (PII)</dt>
<dd>
              Information that (a) can be used to identify the natural person 
              to whom such information relates, or 
              (b) is or might be directly or indirectly linked to a 
              natural person to whom such information relates. 
            
</dd>
<dt>Pairwise Pseudonymous Identifier (PPID)</dt>
<dd> 
              Identifier that identifies the Entity to a Relying Party that cannot be correlated 
              with the Entity's PPID at another Relying Party 
            
</dd>
<dt>ID Token</dt>
<dd>
              <a class='info' href='#JWT'>JSON Web Token (JWT)<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.</span><span>)</span></a> [JWT] that contains Claims about the authentication event
              <br />
<br />

            
</dd>
<dt>Issuer</dt>
<dd>
              Entity that issues a set of Claims. 
            
</dd>
<dt>Issuer Identifier</dt>
<dd>
              HTTPS URL that acts as a verifiable identifier for an Issuer 
            
</dd>
<dt>UserInfo Endpoint</dt>
<dd>
              Protected resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding 
              Authorization Grant  
            
</dd>
</dl></blockquote><p>
        
</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.2"></a><h3>2. 
Protocol Flows</h3>

<p>Authorization Requests can follow one of two paths; the Implicit Flow
      or the Authorization Code Flow. The Authorization Code Flow is
      suitable for Clients that can securely maintain a Client Secret between
      themselves 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 Implicit 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 <a class='info' href='#OpenID.Standard'>OpenID Connect Standard 
      1.0 Specification<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 2012.</span><span>)</span></a> [OpenID.Standard].
</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.2.1"></a><h3>2.1. 
OpenID Connect Scopes</h3>

<p>OpenID Connect Clients use <tt>scope</tt> values as defined in 3.3 of 
        <a class='info' href='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0] to specify what
        access privileges are requested for Access Tokens. The scopes associated
        with Access Tokens determine what resources will be available when they are 
        used to access OAuth 2.0 protected endpoints. For OpenID Connect, scopes
        can be used to request that specific sets of information
        be made available from the UserInfo Endpoint,
        and to request an ID Token.
        OAuth 2.0 allows additional scope values to be specified, as extensions.
        This specification describes only the scope values used by OpenID Connect.
</p>
<p>OpenID Connect defines the following <tt>scope</tt> values:
</p>
<p>
          </p>
<blockquote class="text"><dl>
<dt>openid</dt>
<dd>REQUIRED. Informs the Authorization
            Server that the Client is making an OpenID Connect request. If the
            <tt>openid</tt> scope value is not present,
            the request MUST NOT be treated as an OpenID Connect request.
            This scope value requests access to the <tt>user_id</tt>
            Claim at the UserInfo Endpoint.
</dd>
<dt>profile</dt>
<dd>OPTIONAL. This scope value
            requests that access to the End-User's default <a class='info' href='#ClaimTable'>profile Claims<span> (</span><span class='info'>Reserved Member Definitions</span><span>)</span></a> at the
            UserInfo Endpoint be granted by the issued Access Token.
            These claims are:

            <tt>name</tt>,
            <tt>family_name</tt>,
            <tt>given_name</tt>,
            <tt>middle_name</tt>,
            <tt>nickname</tt>,
            <tt>preferred_username</tt>,
            <tt>profile</tt>,
            <tt>picture</tt>,
            <tt>website</tt>,
            <tt>gender</tt>,
            <tt>birthday</tt>,
            <tt>zoneinfo</tt>,
            <tt>locale</tt>, and
            <tt>updated_time</tt>.
</dd>
<dt>email</dt>
<dd>OPTIONAL. This scope value requests that access to
            the <tt>email</tt> and 
            <tt>email_verified</tt> Claims at the
            UserInfo Endpoint be granted by the issued Access Token.
</dd>
<dt>address</dt>
<dd>OPTIONAL. This scope value requests that access to
            the <tt>address</tt> Claim at the
            UserInfo Endpoint be granted by the issued Access Token.
</dd>
<dt>phone</dt>
<dd>OPTIONAL. This scope value requests that access to 
            the <tt>phone_number</tt> Claim at the 
            UserInfo Endpoint be granted by the issued Access Token.
</dd>
</dl></blockquote><p>
        
</p>
<p>Multiple scopes MAY be requested by creating a space delimited, case
        sensitive list of ASCII scope values.
</p>
<p>In some cases, the End-User will be given the option to
        have the OpenID Provider decline to provide some or all
        information requested by Clients.
</p>
<p>To increase new account activation, a Client may elect to
        only request a subset of the information available from the
        UserInfo Endpoint.
</p>
<p>
          
<p>The following is a non-normative example of a <tt>scope</tt>
            Request.
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>scope=openid profile email phone</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.2.2"></a><h3>2.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><p>
        
</p>
<a name="rf_prep"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.1"></a><h3>2.2.1. 
Client Prepares an Authorization Request</h3>

<p>When the Client 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 Endpoint URL MUST be HTTPS.
</p>
<p>Clients MAY construct the request using the HTTP
          <tt>GET</tt> or the HTTP 
          <tt>POST</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].
</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'>Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
</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</tt> and
                <tt>id_token</tt>, as a space delimited list.
                This requests that both an Access Token and an ID Token be returned
                in the URL fragment of the response.
              
</dd>
</dl></blockquote><p>
          
</p>
<p>Other REQUIRED parameters in the request include the
          following:
</p>
<p>
            </p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>The OAuth 2.0 Client Identifier.
</dd>
<dt>scope</dt>
<dd>It MUST include <tt>openid</tt>
              as one of the space delimited ASCII strings.
              OPTIONAL <tt>scope</tt> strings of
              <tt>profile</tt>, <tt>email</tt>,
              <tt>address</tt>, and <tt>phone</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>
</dl></blockquote><p>
          
</p>
<p>The request MAY contain the following OPTIONAL and sometimes REQUIRED parameters:
</p>
<p>
            </p>
<blockquote class="text"><dl>
<dt>nonce</dt>
<dd>A string value used to associate a Client session 
              with an ID Token, and to mitigate replay attacks. 
              The value is passed through unmodified to the ID Token.
              One method to achieve this is to store a random value as a signed session cookie, and
              pass the value in the <tt>nonce</tt> parameter.
              In that case, the <tt>nonce</tt> in the returned ID Token
              is compared to the signed session cookie to detect ID Token replay by third 
              parties.
</dd>
<dt>state</dt>
<dd>RECOMMENDED.  An opaque value used
              to maintain state between the request and the callback;
              serves as a protection against XSRF attacks.
</dd>
<dt>display</dt>
<dd>An ASCII string value that specifies
              how the Authorization Server displays the authentication and
              consent user interface pages to the End-User. The following values
              are supported:

              
<blockquote class="text"><dl>
<dt>page</dt>
<dd>The Authorization Server SHOULD display
              authentication and consent UI consistent with a full user-agent page
              view. If the display parameter is not specified this is the
              default display mode.
</dd>
<dt>popup</dt>
<dd>The Authorization Server SHOULD display
              authentication and consent UI consistent with a popup user-agent
              window. The popup user-agent window SHOULD be 450 pixels wide
              and 500 pixels tall.
</dd>
<dt>touch</dt>
<dd>The Authorization Server SHOULD display
              authentication and consent UI consistent with a device that
              leverages a touch interface. The Authorization Server MAY attempt
              to detect the touch device and further customize the interface.
</dd>
<dt>wap</dt>
<dd>The Authorization Server SHOULD display
              authentication and consent UI consistent with a "feature phone"
              type display.
</dd>
</dl></blockquote>
          
</dd>
<dt>prompt</dt>
<dd>A space delimited, case sensitive list of
          ASCII string values that specifies whether the Authorization Server prompts
          the End-User for reauthentication and consent. The possible values
          are:

          
<blockquote class="text"><dl>
<dt>none</dt>
<dd>This value informs the Authorization Server
            that it MUST NOT display any authentication or consent
            user interface pages. An error is returned if the End-User 
            is not already authenticated or the Client does not have 
            pre-configured consent for the requested
            <tt>scopes</tt>. This can be used as a
            method to check for existing authentication and/or consent.
</dd>
<dt>login</dt>
<dd>The Authorization Server MUST prompt the
            End-User for reauthentication.
</dd>
<dt>consent</dt>
<dd>The Authorization Server MUST prompt
            the End-User for consent before returning information to the
            Client.
</dd>
<dt>select_account</dt>
<dd>The Authorization Server MUST
            prompt the End-User to select a user account.  This allows 
            a user who has multiple accounts at the Authorization Server
            to select amongst the multiple accounts that they may have 
            current sessions for.
</dd>
</dl></blockquote>

          The <tt>prompt</tt> parameter
          can be used by the Client to make sure that the End-User is
          still present for the current session or to bring attention to the
          request. If this parameter contains <tt>none</tt>
          with any other value, an
          error is returned.
          
</dd>
</dl></blockquote><p>
          
</p>
<p>The following is a non-normative example of an
            Authorization Request URL
            (with line wraps for display purposes 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.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj</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.2.2.2"></a><h3>2.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
            (with line wraps for display purposes 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.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj</pre></div>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.3"></a><h3>2.2.3. 
Authorization Server Authenticates the End-User</h3>

<p>The authorization server authenticates the resource owner
          to make sure that the consent is obtained from the right
          party. The exact method of how the authentication is
          performed is out of scope of this specification. 
</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.2.2.4"></a><h3>2.2.4. 
Authorization Server Obtains the End-User Consent/Authorization</h3>

<p>The Authorization Server obtains an authorization decision,
          for the requested scopes. This can done by presenting the End-User
          with a dialogue that allows the End-User to recognize what he is
          consenting to and obtain his consent or by establishing consent via
          other means (for example, via previous administrative consent).
</p>
<p>The <tt>openid</tt> scope grants the RP access
          to the user identifier of the authenticated End-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 End-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.2.2.5"></a><h3>2.2.5. 
Authorization Server Sends the End-User Back to the Client</h3>

<p>Once the authorization is determined, the Authorization Server
          returns a successful response or an error 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.2.2.5.1"></a><h3>2.2.5.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='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0] and 
            <a class='info' href='#OAuth.Responses'>OAuth 2.0 Multiple Response Type
            Encoding Practices<span> (</span><span class='info'>de Medeiros, B., Scurtescu, M., and P. Tarjan, “OAuth 2.0 Multiple Response Type Encoding Practices,” May 2012.</span><span>)</span></a> [OAuth.Responses].
</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='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0]
</p>
<p>
              </p>
<blockquote class="text"><dl>
<dt>access_token</dt>
<dd>REQUIRED. The Access Token for the
                UserInfo Endpoint.
</dd>
<dt>token_type</dt>
<dd>REQUIRED. The value MUST be
                "bearer"
</dd>
<dt>id_token</dt>
<dd>REQUIRED. The ID Token.
</dd>
<dt>state</dt>
<dd>REQUIRED if the 
                <tt>state</tt> parameter is present in the
                client Authorization Request. Clients MUST verify that the 
                <tt>state</tt> value is equal to the exact 
                value of <tt>state</tt> parameter in the 
                Authorization Request.
</dd>
<dt>expires_in</dt>
<dd>OPTIONAL. The expiration time in
                seconds of the Access Token.
</dd>
</dl></blockquote><p>
            
</p>
<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
              (with line wraps after the second line for the display purposes only):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&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.2.2.5.2"></a><h3>2.2.5.2. 
End-User Denies Authorization or Invalid Request</h3>

<p>If the End-User denies the authorization or the End-User authentication
            fails, the Authorization Server MUST return the error
            authorization response as defined in 4.2.2.1 of 
            <a class='info' href='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0]. No other parameters 
            SHOULD be returned.
</p>
<a name="implicit_callback"></a><br /><hr />
<table summary="layout" 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.2.5.3"></a><h3>2.2.5.3. 
Example Redirect URI response</h3>

<p>The client must provide a way for the user agent to parse the fragment encoded
          response and POST it to the web server client for validation.
</p>
<p>The following is an example of a JavaScript file that a Client might host at its
          <tt>redirect_uri</tt>.  This is loaded by the redirect from
          the Authorization Server.  The fragment is parsed and then sent by POST to a URI 
          that will validate the information received.
</p>
<p>Following is a non-normative example of a
            Redirect URI response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /cb HTTP/1.1
Host: client.example.org

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<script type="text/javascript">

// First, parse the query string
var params = {}, postBody = location.hash.substring(1),
    regex = /([^&=]+)=([^&]*)/g, m;
while (m = regex.exec(postBody)) {
  params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}

// And send the token over to the server
var req = new XMLHttpRequest();
// using POST so query isn't logged
req.open('POST', 'https://' + window.location.host +
                 '/catch_response', true);
req.setRequestHeader('Content-Type',
                     'application/x-www-form-urlencoded');

req.onreadystatechange = function (e) {
  if (req.readyState == 4) {
    if (req.status == 200) {
// If the response from the POST is 200 OK, redirect the user
      window.location = 'https://'
        + window.location.host + '/redirect_after_login'
    }
// if the OAuth response is invalid, generate an error message
    else if (req.status == 400) {
      alert('There was an error processing the token')
    } else {
      alert('Something other than 200 was returned')
    }
  }
};
req.send(postBody);</pre></div>
<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.2.3"></a><h3>2.3. 
ID Token</h3>

<p>The ID Token is a security token that contains Claims about the
          authentication event and other requested Claims.  
          The ID Token is represented as a <a class='info' href='#JWT'>JSON Web Token (JWT)<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” May 2012.</span><span>)</span></a> [JWT].
</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>aud</tt> (audience) and <tt>nonce</tt>
          Claims. 
</p>
<p>The following Claims are REQUIRED within the ID Token:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>iss</dt>
<dd>REQUIRED. The Issuer Identifier for the Issuer
              of the response.
</dd>
<dt>user_id</dt>
<dd>REQUIRED. A locally unique and never
              reassigned identifier within the Issuer for the End-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 MUST be the OAuth 2.0 <tt>client_id</tt>
              of the Client.
</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>iat</dt>
<dd>REQUIRED. Type Integer. The <tt>iat</tt> 
              (issued at) Claim identifies the time at which the JWT was issued. 
              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>nonce</dt>
<dd>A string value used to associate a Client session 
              with an ID Token, and to mitigate replay attacks. 
              The value is passed through unmodified from the Authorization Request to the ID Token.
              If present in the <a class='info' href='#id_token'>ID Token<span> (</span><span class='info'>ID Token</span><span>)</span></a>,
              clients MUST verify that
              the <tt>nonce</tt> Claim value is equal to
              the value of the <tt>nonce</tt>
              parameter sent in the Authorization Request.
              If present in the Authorization Request, Authorization Servers
              MUST include a <tt>nonce</tt> Claim in the
              <a class='info' href='#id_token'>ID Token<span> (</span><span class='info'>ID Token</span><span>)</span></a> with the Claim value
              being the nonce value sent in the Authorization Request.
              Use of the nonce is REQUIRED when using the implicit flow
              and OPTIONAL when using the code flow.
</dd>
<dt>at_hash</dt>
<dd>
              If the ID Token is issued with an <tt>access_token</tt>
              in an implicit flow, this is REQUIRED.
              The value is produced by base64url encoding the left-most half of the hash 
              created by hashing the <tt>access_token</tt> 
              with the SHA-2 family hash algorithm
              of the same length as the hash used in the <tt>alg</tt>
              parameter of the <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.</span><span>)</span></a> [JWS] header.
              For instance, if the <tt>alg</tt> is
              <tt>HS256</tt>, hash <tt>access_token</tt>
              with SHA-256, then take the left-most 128 bits and base64url encode them.
</dd>
</dl></blockquote>

<p>Additional optional claims may be present in the ID Token.
</p>
<p>ID Tokens MUST be signed using <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.</span><span>)</span></a> [JWS] and OPTIONALLY both signed and
            encrypted using <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.</span><span>)</span></a> [JWS] and <a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2012.</span><span>)</span></a> [JWE] respectively, thereby providing
            authentication, integrity,
            non-repudiation, and optionally, confidentiality.
</p>
<p>
              Clients MUST directly validate the ID Token per 
              <a class='info' href='#id.token.verification'>ID Token Verification<span> (</span><span class='info'>ID Token Verification</span><span>)</span></a>. 
            
</p>
<a name="id.token.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.2.4"></a><h3>2.4. 
ID Token Verification</h3>

<p>To verify the validity of ID Token in the Authorization Response,
        the Client MUST do the following:
</p>
<p>
          </p>
<ol class="text">
<li>The Client MUST validate that the <tt>client_id</tt> in the 
            <tt>aud</tt> (audience) Claim is one
            it has registered for the Issuer identified by the value in the 
            <tt>iss</tt> (issuer) Claim.
            The ID Token MUST be rejected if the value of 
            <tt>aud</tt> (audience) is not valid for the 
            Issuer.
</li>
<li>The Client MUST verify the signature of the ID Token according to
            <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.</span><span>)</span></a> [JWS] using the algorithm specified in the 
            <tt>alg</tt> parameter of the JWT header.
</li>
<li>The <tt>alg</tt> value SHOULD be <tt>RS256</tt>.
            Validation of tokens using other signing algorithms is described in the
            <a class='info' href='#OpenID.Messages'>OpenID Connect Messages<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.</span><span>)</span></a> [OpenID.Messages]
            specification.
</li>
<li>The Client MUST use the signing key provided
            in Discovery by the Issuer.
            The Issuer must exactly match the value of the 
            <tt>iss</tt> (issuer) Claim.
</li>
<li>The current time MUST be less than the value of the 
            <tt>exp</tt> Claim.
</li>
<li>The <tt>iat</tt> Claim may be used to reject tokens that
            were issued too far away from the current time, limiting the amount of
            time that nonces must be stored to prevent attacks. 
            The acceptable range is Client specific.
</li>
<li>The value of the <tt>nonce</tt>
            Claim MUST be checked to verify that
            it is the same value as the one that was sent in the Authorization
            Request. The Client SHOULD check the <tt>nonce</tt> value for replay attacks.
            The precise method for detecting replay attacks is Client specific.
</li>
<li>If the <tt>acr</tt> Claim was requested, the 
            Client SHOULD check that the asserted Claim Value is appropriate.
            The meaning and processing of  
            <tt>acr</tt> Claim Values is out of scope for this specification.
</li>
<li>If the <tt>auth_time</tt> Claim was requested, the 
            Client SHOULD check the value 
            and request re-authentication if it determines too much time has elapsed 
            since the last user authentication.
</li>
</ol><p>
        
</p>
<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.2.5"></a><h3>2.5. 
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>UserInfo Endpoint Servers MUST require the use of a transport-layer
        security mechanism. The UserInfo Endpoint Server MUST support TLS 1.2
        <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] and/or TLS 1.0
        <a class='info' href='#RFC2246'>[RFC2246]<span> (</span><span class='info'>Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a> and MAY support
        other transport-layer mechanisms with equivalent security.
</p>
<p>NOTE: The UserInfo Endpoint response is not guaranteed to be about the
        Interactive user identified by the <tt>user_id</tt> element of the ID Token. 
        The <tt>user_id</tt> Claim in the UserInfo Endpoint response MUST exactly match the 
        <tt>user_id</tt> Claim in the ID Token, before using additional UserInfo Endpoint Claims.
</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.2.5.1"></a><h3>2.5.1. 
UserInfo Request</h3>

<p>Clients MAY send requests with the following parameters to the
          UserInfo Endpoint to obtain further information about the End-User. The
          UserInfo Endpoint is an <a class='info' href='#OAuth2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Framework,” June 2012.</span><span>)</span></a> [OAuth2.0]
          Protected Resource that complies with the <a class='info' href='#OAuth.Bearer'>OAuth 2.0 Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.</span><span>)</span></a> [OAuth.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 the HTTP Authorization
              header or a form-encoded HTTP POST body parameter.
</dd>
<dt>schema</dt>
<dd>REQUIRED. The schema in which the
              data is to be returned. The only defined value is <tt>openid</tt>.
</dd>
<dt>id</dt>
<dd>This identifier is reserved. It MUST be
              ignored by the endpoint when the <tt>openid</tt> schema is used.
</dd>
</dl></blockquote><p>
          
</p>
<p>The following is a non-normative example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG</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.2.5.2"></a><h3>2.5.2. 
UserInfo Response</h3>

<p>If the requested schema is <tt>openid</tt>,
          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>
            If a Claim is not returned, that Claim Name SHOULD be
            omitted from the JSON object representing the Claims; it
            SHOULD NOT be present with a null or empty string value.
          
</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>family_name#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>family_name#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">REQUIRED Identifier for the End-User at the Issuer.</td>
</tr>
<tr>
<td align="left">name</td>
<td align="left">string</td>
<td align="left">End-User's full name in displayable form including all name parts,
            ordered according to End-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 End-User.</td>
</tr>
<tr>
<td align="left">family_name</td>
<td align="left">string</td>
<td align="left">Surname or last name of the End-User.</td>
</tr>
<tr>
<td align="left">middle_name</td>
<td align="left">string</td>
<td align="left">Middle name of the End-User.</td>
</tr>
<tr>
<td align="left">nickname</td>
<td align="left">string</td>
<td align="left">Casual name of the End-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">preferred_username</td>
<td align="left">string</td>
<td align="left">Shorthand name that the End-User wishes to be referred to at the RP, such as
            <tt>janedoe</tt> or <tt>j.doe</tt>. 
            This value MAY be any valid JSON string including 
            special characters such as <tt>@</tt>, 
            <tt>/</tt>, or whitespace. This value MUST NOT
            be relied upon to be unique by the RP. 
            (See <a class='info' href='#claim.stability'>Section 2.5.2.2<span> (</span><span class='info'>Claim Stability and Uniqueness</span><span>)</span></a>.)</td>
</tr>
<tr>
<td align="left">profile</td>
<td align="left">string</td>
<td align="left">URL of the End-User's profile page.</td>
</tr>
<tr>
<td align="left">picture</td>
<td align="left">string</td>
<td align="left">URL of the End-User's profile picture.</td>
</tr>
<tr>
<td align="left">website</td>
<td align="left">string</td>
<td align="left">URL of the End-User's web page or blog.</td>
</tr>
<tr>
<td align="left">email</td>
<td align="left">string</td>
<td align="left">The End-User's preferred e-mail address. 
            This value MUST NOT be relied upon to be unique by 
            the RP. (See <a class='info' href='#claim.stability'>Section 2.5.2.2<span> (</span><span class='info'>Claim Stability and Uniqueness</span><span>)</span></a>.)</td>
</tr>
<tr>
<td align="left">email_verified</td>
<td align="left">boolean</td>
<td align="left">True if the End-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 End-User's gender: Values defined by this
            specification are <tt>female</tt> and
            <tt>male</tt>.  Other values MAY be used
            when neither of the defined values are applicable.</td>
</tr>
<tr>
<td align="left">birthday</td>
<td align="left">string</td>
<td align="left">The End-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> time zone
            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 End-User's locale, represented as a
            <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 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 End-User's preferred telephone number. <a class='info' href='#E.164'>E.164<span> (</span><span class='info'>International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.</span><span>)</span></a> [E.164] is RECOMMENDED as the format of this Claim. 
            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 End-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
            the members defined in <a class='info' href='#address_claim'>Section 2.5.2.1<span> (</span><span class='info'>Address Claim</span><span>)</span></a>.</td>
</tr>
<tr>
<td align="left">updated_time</td>
<td align="left">string</td>
<td align="left">Time the End-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
            a response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
 "user_id": "248289761001",
 "name": "Jane Doe",
 "given_name": "Jane",
 "family_name": "Doe",
 "preferred_username": "j.doe",
 "email": "janedoe@example.com",
 "picture": "http://example.com/janedoe/me.jpg"
}</pre></div>
<p>The UserInfo Endpoint MUST return Claims in JSON format unless a
          different format was specified during <a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client Registration 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.</span><span>)</span></a> [OpenID.Registration].
          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">JSON Web Token (JWT)</td>
</tr>
</table>
<br clear="all" />

<a name="address_claim"></a><br /><hr />
<table summary="layout" 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.5.2.1"></a><h3>2.5.2.1. 
Address Claim</h3>

<p>
              The components of a physical mailing address. 
              Implementations MAY return only a subset of the
              fields of an <tt>address</tt>, depending upon
              the information available and the End-User's privacy 
              preferences. For
              example, the <tt>country</tt> and <tt>region</tt> might be returned without returning
              more fine-grained address information.
            
</p>
<p>
              Implementations MAY return just the full address 
              as a single string in the formatted sub-field, 
              or they MAY return just the individual component 
              fields using the other sub-fields, 
              or they MAY return both. 
              If both variants are returned, 
              they SHOULD be describing the same address, 
              with the formatted address indicating how the 
              component fields SHOULD be combined.
            
</p>
<p>
              </p>
<blockquote class="text"><dl>
<dt>formatted</dt>
<dd>The full mailing address, 
                formatted for display or use with a mailing label. 
                This field MAY contain newlines. This is the 
                Primary Sub-Field for this field, 
                for the purposes of sorting and filtering.
</dd>
<dt>street_address</dt>
<dd>
                The full street address component, 
                which may include house number, street name, 
                PO BOX, and multi-line extended street 
                address information. This field MAY contain newlines.
</dd>
<dt>locality</dt>
<dd>The city or locality component.
</dd>
<dt>region</dt>
<dd>The state, province, 
                prefecture or region component.
</dd>
<dt>postal_code</dt>
<dd>The zip code or 
                postal code component.
</dd>
<dt>country</dt>
<dd>The country name component.
</dd>
</dl></blockquote><p>
            
</p>
<a name="claim.stability"></a><br /><hr />
<table summary="layout" 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.5.2.2"></a><h3>2.5.2.2. 
Claim Stability and Uniqueness</h3>

<p>The <tt>user_id</tt> claim is the only claim that a client
            can rely upon to be stable, since the <tt>user_id</tt>
            claim MUST be locally unique and never reassigned within the Issuer
            for a particular End-User, as described in <a class='info' href='#id_token'>Section 2.3<span> (</span><span class='info'>ID Token</span><span>)</span></a>.
</p>
<p>Therefore, the only guaranteed unique identifier for a given End-User is a 
            combination of the Issuer's identifier and the <tt>user_id</tt>
            claim; other fields such as <tt>preferred_username</tt>
            and <tt>email</tt> MUST NOT be used as unique identifiers 
            for a given End-User.
</p>
<p>All other claims carry no such guarantees across different issuers in terms of
            stability over time or uniqueness across users, and Issuers are permitted to
            apply local restrictions and policies. For instance, an Issuer MAY re-use a 
            given <tt>preferred_username</tt> or 
            <tt>email</tt> address claim across different
            End-Users at different points in time, and the claimed 
            <tt>preferred_username</tt> or 
            <tt>email</tt> address for a given End-User MAY change 
            over time.
</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.2.5.3"></a><h3>2.5.3. 
UserInfo Error Response</h3>

<p>When an error condition occurs, the UserInfo Endpoint returns
          an Error Response as defined in Section 3 of
          <a class='info' href='#OAuth.Bearer'>OAuth 2.0 Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.</span><span>)</span></a> [OAuth.Bearer].
</p>
<p>In addition to the error codes defined in Section 3.1 of <a class='info' href='#OAuth.Bearer'>OAuth 2.0 Bearer Tokens<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” June 2012.</span><span>)</span></a> [OAuth.Bearer], this specification defines the
          following error codes:
</p>
<p>
            </p>
<blockquote class="text"><dl>
<dt>invalid_schema</dt>
<dd>The requested schema is invalid or
              unsupported.
</dd>
</dl></blockquote><p>
          
</p>
<a name="self_issued"></a><br /><hr />
<table summary="layout" 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. 
Self Issued Identity Provider</h3>

<p>There is a special issuer "https://self-issued.me" that indicates a user is using a personal IdP that is issuing self signed id_token. 
</p>
<a name="self_issued.discovery"></a><br /><hr />
<table summary="layout" 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. 
Self Issued Identity Provider Discovery</h3>

<p>
          If the input identifier contains the domain self-issued.me, dynamic discovery is not performed. 
          The following static configuration values are used.
        
</p>
<p>
          </p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{
 "authorization_endpoint":
   "openid:",
 "issuer":
   "https://self-issued.me",
 "scopes_supported":
   ["openid", "profile", "email", "address", "phone"],
 "response_types_supported":
   ["id_token"],
 "user_id_types_supported":
   ["pairwise"],
 "id_token_algs_supported":
   ["RS256"],
 "request_object_algs_supported":
   ["RS256"]
 }
</pre></div><p>

        
</p>
<p>Note: OpenID Foundation may consider hosting a domain https://self-issued.me/ 
          which returns the above static configuration file so that the client would not 
          need any special treatment of the self issued IdP. 
        
</p>
<a name="self_issued.registration"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2. 
Client Registration to Self Issued Identity Provider</h3>

<p>
          When dealing with the Self Issued IdP, the Client is deemed to have 
          registered with the IdP and obtained following Client Registration Response.  
        
</p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>
            The <tt>redirect_uri</tt> of the Client. 
          
</dd>
<dt>expires_at</dt>
<dd>
            0.
          
</dd>
</dl></blockquote>
<p>Note: OpenID Foundation may consider hositng an endpoint 
          <tt>https://self-issued.me/registration/1.0/</tt> 
          that returns the static response as above so that the Client may not need to 
          perform any special processing for a Self Issued IdP. 
        
</p>
<a name="self_issued.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.3"></a><h3>3.3. 
Self Issued Identity Provider Request</h3>

<p>The Client sends the Authorization Request to the Authorization
           Endpoint with the following REQUIRED parameters. 
</p>
<blockquote class="text"><dl>
<dt>response_type</dt>
<dd>
            REQUIRED. <tt>id_token</tt>.
          
</dd>
<dt>client_id</dt>
<dd>
            REQUIRED. <tt>redirect_uri</tt> 
            of the client. Note that since it is same as the 
            <tt>redirect_uri</tt>, <tt>redirect_uri</tt> 
            is not required to be sent in the request. 
          
</dd>
<dt>scope</dt>
<dd>
            REQUIRED. Supported <tt>scope</tt> 
            desicribed in the previous section. It MUST include 
            <tt>openid</tt>. 
          
</dd>
</dl></blockquote>
<p>
          Other parameters MAY be sent. 
          Note that the user clames are returned in the <tt>id_token</tt>.  
        
</p>
<p>The entire URL MUST NOT exceed 2048 bytes.
</p>
<p>
            Following is a non-normative example (with line wraps for display purposes only):
          
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found
Location: openid://
?response_type=id_token
&client_id=https%3A%2F%2Fclient.example.org%2cb
&scope=openid%20profile
&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj</pre></div>
<a name="self_issued.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.4"></a><h3>3.4. 
Self Issued Identity Provider Response</h3>

<p>Self Issued Identity Provider Response will be the same as the normal implicit flow 
          response apart from the fact that the <tt>iss</tt> claim is 
          <tt>https://self-issued.me</tt> and user cliams are 
          returned in <tt>id_token</tt>. Since it is an implicit flow 
          reponse, the response parameters will be returned in fragment. 
        
</p>
<a name="self_issued.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.5"></a><h3>3.5. 
Self Issued Identity ID Token Verification</h3>

<p>To verify the validity of ID Token in the Authorization or Token Endpoint Response, the Client
        MUST do the following:
</p>
<p></p>
<ol class="text">
<li>
            The Client MUST validate that the value of the <tt>iss</tt> (issuer) Claim is <tt>https://self-isued.me</tt>.  
            If <tt>iss</tt> contains a diffrent value, 
            it MUST be validated according to 
            <a class='info' href='#id.token.verification'>ID Token Verification<span> (</span><span class='info'>ID Token Verification</span><span>)</span></a>.
          
</li>
<li>
            The Client MUST validate that the value of the 
            <tt>aud</tt> (audience) Claim is the value of the <tt>redirect_uri</tt>
             that the client sent in the authentication request. 
           
</li>
<li>
            The Client MUST verify the signature of the ID Token according to
            <a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” May 2012.</span><span>)</span></a> [JWS] using the algorithm specified in the 
            <tt>alg</tt> parameter of the JWT header,  
            using the key in the user_jwk claim.  The key is in JWK format.
          
</li>
<li>
            The <tt>alg</tt> value SHOULD be the default of 
            <tt>RS256</tt>. It may also be <tt>ES256</tt>.
          
</li>
<li>
            The Client MUST validate that the <tt>user_id</tt> value is a 
            base64url encoded binary SHA256 hash of 
            the concatination of the value of <tt>mod</tt> and 
            <tt>exp</tt> of the <tt>user_jwk</tt>.
          
</li>
<li>
            The current time MUST be less than the value of the 
            <tt>exp</tt> Claim.
          
</li>
<li>
            The <tt>iat</tt> Claim may be used to reject tokens that 
            were issued too far away from the current time, limiting the amount of
            time that nonces must be stored to prevent attacks. 
            The acceptable range is Client specific.
          
</li>
<li>
            If a nonce value was sent in the Authorization Request, 
            a <tt>nonce</tt> Claim MUST be present 
            and its value of the checked to verify that
            it is the same value as the one that was sent in the Authorization
            Request. The Client SHOULD check the <tt>nonce</tt> value for replay attacks.
            The precise method for detecting replay attacks is Client specific.
          
</li>
</ol>

<p>The following is a non-normative example of a base64url decoded 
            self issued <tt>id_token</tt>. Note that the 
            line wraps are for display purpose only:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
{
 "iss": "https://self-issued.me",
 "user_id": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
 "aud": "https://client.example.org/cb",
 "nonce": "n-0S6_WzA2Mj",
 "exp": 1311281970,
 "iat": 1311280970,
 "user_jwk": {"alg":"RSA",
        "mod": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
   4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
   tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
   QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
   SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
   w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
        "exp":"AQAB"
        }
}</pre></div>
<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.4"></a><h3>4. 
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,” May 2012.</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., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” May 2012.</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.5"></a><h3>5. 
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'>Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.
</p>
<p>Following is a non-normative example of such
        serialization:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com</pre></div>
<a name="form_serialization"></a><br /><hr />
<table summary="layout" 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. 
Form Serialization</h3>

<p>Parameters and their values are form serialized by adding the 
      parameter names and values to the entity body of the HTTP request using
      the <tt>application/x-www-form-urlencoded</tt> format
      as defined by <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>. Form
      serialization is typically used in HTTP POST requests.
</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>POST /authorize HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

scope=openid&response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb</pre></div>
<a name="stringops"></a><br /><hr />
<table summary="layout" 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. 
String Operations</h3>

<p>
        Processing some OpenID Connect messages requires comparing
        values in the messages to known values. For example, the Claim
        Names returned by the UserInfo Endpoint might be compared to
        specific Claim Names such as <tt>user_id</tt>.  Comparing Unicode strings,
        however, has significant security implications.
      
</p>
<p>
        Therefore, comparisons between JSON strings and other Unicode
        strings MUST be performed as specified below:

        </p>
<ol class="text">
<li>
            Remove any JSON applied escaping to produce an array of
            Unicode code points.
          
</li>
<li>
            <a class='info' href='#USA15'>Unicode Normalization<span> (</span><span class='info'>Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.</span><span>)</span></a> [USA15] MUST NOT
            be applied at any point to either the JSON string or to
            the string it is to be compared against.
          
</li>
<li>
            Comparisons between the two strings MUST be performed as a
            Unicode code point to code point equality comparison.
          
</li>
</ol><p>
      
</p>
<p>
        In several places, this specification uses space delimited
        lists of strings.  In all such cases, only the ASCII space
        character (0x20) MAY be used for this purpose.
      
</p>
<a name="security_considerations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8. 
Security Considerations</h3>

<p>For security considerations, refer to the
      <a class='info' href='#OpenID.Standard'>OpenID Connect Standard 1.0 Specification<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” June 2012.</span><span>)</span></a> [OpenID.Standard].
      
</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.9"></a><h3>9. 
Privacy Considerations</h3>

<p>The UserInfo response typically contains Personally Identifiable
      Information. As such, End-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 End-User so that the End-User can monitor who accessed his data.
</p>
<p>To protect the End-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.10"></a><h3>10. 
IANA Considerations</h3>

<p>This document makes no requests of IANA.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11. 
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>11.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="E.164">[E.164]</a></td>
<td class="author-text">International Telecommunication Union, “<a href="http://www.itu.int/rec/T-REC-E.164-201011-I/en">E.164: The international public telecommunication numbering plan</a>,” 2010.</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., Rescorla, E., and J. Hildebrand, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">JSON Web Token</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.Bearer">[OAuth.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">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>,” June 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth.Responses">[OAuth.Responses]</a></td>
<td class="author-text">de Medeiros, B., Scurtescu, M., and P. Tarjan, “<a href="http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">OAuth 2.0 Multiple Response Type Encoding Practices</a>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="OAuth2.0">[OAuth2.0]</a></td>
<td class="author-text">Hammer, E., Ed., Recordon, D., and D. Hardt, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2">The OAuth 2.0 Authorization Framework</a>,” June 2012.</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>,” May 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Messages">[OpenID.Messages]</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-messages-1_0.html">OpenID Connect Messages 1.0</a>,” June 2012.</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., and M. Jones, “<a href="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Connect Dynamic Client Registration 1.0</a>,” May 2012.</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>,” June 2012.</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="RFC2246">[RFC2246]</a></td>
<td class="author-text"><a href="mailto:tdierks@certicom.com">Dierks, T.</a> and <a href="mailto:callen@certicom.com">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>,” RFC 2246, January 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2246.txt">TXT</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="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,” RFC 5246, August 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="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="USA15">[USA15]</a></td>
<td class="author-text"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler, K.</a>, and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-html401-19991224">[W3C.REC-html401-19991224]</a></td>
<td class="author-text">Hors, A., Raggett, D., and I. Jacobs, “<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a>,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (<a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="zoneinfo">[zoneinfo]</a></td>
<td class="author-text">Public Domain, “<a href="http://www.twinsun.com/tz/tz-link.htm">The tz database</a>,” June 2011.</td></tr>
</table>

<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>11.2. Informative References</h3>
<table width="99%" border="0">
<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., and C. Mortimore, “<a href="http://openid.net/specs/openid-connect-basic-1_0.html">OpenID Connect Basic Client Profile 1.0</a>,” June 2012.</td></tr>
</table>

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

<p>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>Andreas Akre Solberg (andreas.solberg@uninett.no), UNINET
</p>
<p>Anthony Nadalin (tonynad@microsoft.com), Microsoft
</p>
<p>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom
</p>
<p>Breno de Medeiros (breno@gmail.com), Google
</p>
<p>Casper Biering (cb@peercraft.com), Peercraft
</p>
<p>Chuck Mortimore (cmortimore@salesforce.com), Salesforce
</p>
<p>David Recordon (dr@fb.com), Facebook
</p>
<p>Edmund Jay (ejay@mgi1.com), Illumila
</p>
<p>George Fletcher (george.fletcher@corp.aol.com), AOL
</p>
<p>Hideki Nara (hideki.nara@gmail.com), Takt Communications
</p>
<p>John Bradley (ve7jtb@ve7jtb.com), Ping Identity
</p>
<p>Johnny Bufu (jbufu@janrain.com), Janrain
</p>
<p>Justin Richer (jricher@mitre.org), Mitre
</p>
<p>Luke Shepard (lshepard@fb.com), Facebook
</p>
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd. 
</p>
<p>Nov Matake (nov@matake.jp), Independent
</p>
<p>Pamela Dingle (pdingle@pingidentity.com), Ping Identity
</p>
<p>Paul Tarjan (pt@fb.com), Facebook
</p>
<p>Roland Hedberg (roland.hedberg@adm.umu.se), Independent
</p>
<p>Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.
</p>
<p>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom
</p>
</blockquote><p>
      
</p>
<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.B"></a><h3>Appendix B. 
Notices</h3>

<p>Copyright (c) 2012 The OpenID Foundation.
</p>
<p>
        The OpenID Foundation (OIDF) grants to any Contributor, developer, 
        implementer, or other interested party a non-exclusive, royalty free, 
        worldwide copyright license to reproduce, prepare derivative works from, 
        distribute, perform and display, this Implementers Draft or 
        Final Specification solely for the purposes of (i) developing 
        specifications, and (ii) implementing Implementers Drafts and 
        Final Specifications based on such documents, provided that attribution 
        be made to the OIDF as the source of the material, but that such attribution 
        does not indicate an endorsement by the OIDF.
      
</p>
<p>
        The technology described in this specification was 
        made available from contributions from various sources, 
        including members of the OpenID Foundation and others.  
        Although the OpenID Foundation has taken steps to help ensure 
        that the technology is available for distribution, it takes 
        no position regarding the validity or scope of any intellectual 
        property or other rights that might be claimed to pertain to 
        the implementation or use of the technology described in 
        this specification or the extent to which any license under 
        such rights might or might not be available; neither does it 
        represent that it has made any independent effort to identify 
        any such rights.  The OpenID Foundation and the contributors 
        to this specification make no (and hereby expressly disclaim any) 
        warranties (express, implied, or otherwise), including implied 
        warranties of merchantability, non-infringement, fitness for 
        a particular purpose, or title, related to this specification, 
        and the entire risk as to implementing this specification is 
        assumed by the implementer.  The OpenID Intellectual 
        Property Rights policy requires contributors to offer 
        a patent promise not to assert certain patent claims against 
        other contributors and against implementers.  The OpenID Foundation invites 
        any interested party to bring to its attention any copyrights, 
        patents, patent applications, or other proprietary rights 
        that may cover technology that may be required to practice 
        this specification.
      
</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.C"></a><h3>Appendix C. 
Document History</h3>

<p>[[ To be removed from the final specification ]]
</p>
<p>-02
        </p>
<ul class="text">
<li>Added <tt>preferred_username</tt> claim
        under <tt>profile</tt> scope
</li>
<li>Added ID Token section to describe required claims
</li>
<li>Added section on claim stability
</li>
</ul>

<p>-01
        </p>
<ul class="text">
<li>Removed <tt>claims_in_id_token</tt> scope value,
          per decision on June 15, 2012 special working group call
</li>
</ul>

<p>-00
        </p>
<ul class="text">
<li>Initial version, based upon Basic Client specification version -17
</li>
<li>Renamed from Basic Client to Implicit Client, per issue #567
</li>
<li>Changed <tt>verified</tt> to
          <tt>email_verified</tt>, per issue #564
</li>
<li>Removed Check ID Endpoint and added ID token signature verification text,
          per issue #570
</li>
<li>Changed client.example.com to client.example.org, per issue #251
</li>
<li>Added claims_in_id_token scope definition to Basic and Implicit,
          per issue #594
</li>
<li>Use standards track version of JSON Web Token spec
          (draft-ietf-oauth-json-web-token)
</li>
</ul><p>
      
</p>
<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</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute, Ltd.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.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</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">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">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>
<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">Illumila</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>