<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html lang="en"><head><title>Draft: OpenID Connect Basic

    Client 1.0 - draft 12</title>

<meta http-equiv="Expires" content="Mon, 19 Sep 2011 18:03:33 +0000">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<meta name="description" content="OpenID Connect Basic

    Client 1.0 - draft 12">

<meta name="generator" content="xml2rfc v1.34 (http://xml.resource.org/)">

<style type='text/css'><!--

        body {

                font-family: verdana, charcoal, helvetica, arial, sans-serif;

                font-size: small; color: #000; background-color: #FFF;

                margin: 2em;

        }

        h1, h2, h3, h4, h5, h6 {

                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;

                font-weight: bold; font-style: normal;

        }

        h1 { color: #900; background-color: transparent; text-align: right; }

        h3 { color: #333; background-color: transparent; }

        td.RFCbug {

                font-size: x-small; text-decoration: none;

                width: 30px; height: 30px; padding-top: 2px;

                text-align: justify; vertical-align: middle;

                background-color: #000;

        }

        td.RFCbug span.RFC {

                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;

                font-weight: bold; color: #666;

        }

        td.RFCbug span.hotText {

                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;

                font-weight: normal; text-align: center; color: #FFF;

        }

        table.TOCbug { width: 30px; height: 15px; }

        td.TOCbug {

                text-align: center; width: 30px; height: 15px;

                color: #FFF; background-color: #900;

        }

        td.TOCbug a {

                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;

                font-weight: bold; font-size: x-small; text-decoration: none;

                color: #FFF; background-color: transparent;

        }

        td.header {

                font-family: arial, helvetica, sans-serif; font-size: x-small;

                vertical-align: top; width: 33%;

                color: #FFF; background-color: #666;

        }

        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }

        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */

        a.info {

                /* This is the key. */

                position: relative;

                z-index: 24;

                text-decoration: none;

        }

        a.info:hover {

                z-index: 25;

                color: #FFF; background-color: #900;

        }

        a.info span { display: none; }

        a.info:hover span.info {

                /* The span will display just on :hover state. */

                display: block;

                position: absolute;

                font-size: smaller;

                top: 2em; left: -5em; width: 15em;

                padding: 2px; border: 1px solid #333;

                color: #900; background-color: #EEE;

                text-align: left;

        }

        a { font-weight: bold; }

        a:link    { color: #900; background-color: transparent; }

        a:visited { color: #633; background-color: transparent; }

        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }

        p.copyright { font-size: x-small; }

        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }

        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }

        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

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

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

        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */

        em     { font-style: italic; }

        strong { font-weight: bold; }

        dfn    { font-weight: bold; font-style: normal; }

        cite   { font-weight: normal; font-style: normal; }

        tt     { color: #036; }

        tt, pre, pre dfn, pre em, pre cite, pre span {

                font-family: "Courier New", Courier, monospace; font-size: small;

        }

        pre {

                text-align: left; padding: 4px;

                color: #000; background-color: #CCC;

        }

        pre dfn  { color: #900; }

        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }

        pre .key { color: #33C; font-weight: bold; }

        pre .id  { color: #900; }

        pre .str { color: #000; background-color: #CFF; }

        pre .val { color: #066; }

        pre .rep { color: #909; }

        pre .oth { color: #000; background-color: #FCF; }

        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */

        table.all, table.full, table.headers, table.none {

                font-size: small; text-align: center; border-width: 2px;

                vertical-align: top; border-collapse: collapse;

        }

        table.all, table.full { border-style: solid; border-color: black; }

        table.headers, table.none { border-style: none; }

        th {

                font-weight: bold; border-color: black;

                border-width: 2px 2px 3px 2px;

        }

        table.all th, table.full th { border-style: solid; }

        table.headers th { border-style: none none solid none; }

        table.none th { border-style: none; }

        table.all td {

                border-style: solid; border-color: #333;

                border-width: 1px 2px;

        }

        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }

        hr.insert {

                width: 80%; border-style: none; border-width: 0;

                color: #CCC; background-color: #CCC;

        }

--></style>

</head>

<body>

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">

<tr><td class="header">Draft</td><td class="header">N. Sakimura, Ed.</td></tr>

<tr><td class="header"> </td><td class="header">NRI</td></tr>

<tr><td class="header"> </td><td class="header">J. Bradley, Ed.</td></tr>

<tr><td class="header"> </td><td class="header">Independent</td></tr>

<tr><td class="header"> </td><td class="header">B. de Medeiros</td></tr>

<tr><td class="header"> </td><td class="header">Google</td></tr>

<tr><td class="header"> </td><td class="header">M. Jones</td></tr>

<tr><td class="header"> </td><td class="header">Microsoft</td></tr>

<tr><td class="header"> </td><td class="header">E. Jay</td></tr>

<tr><td class="header"> </td><td class="header">MGI1</td></tr>

<tr><td class="header"> </td><td class="header">C. Mortimore</td></tr>

<tr><td class="header"> </td><td class="header">Salesforce</td></tr>

<tr><td class="header"> </td><td class="header">September 6, 2011</td></tr>

</table></td></tr></table>

<h1><br />OpenID Connect Basic

    Client 1.0 - draft 12</h1>

<h3>Abstract</h3>

<p>OpenID Connect 1.0 is a simple identity layer on top of OAuth 2.0

      protocol. It allows a web site to verify the identity of the user based

      on the authentication performed by the authorization server, as well as to

      obtain basic profile information about the user in an interoperable and 

      RESTful manner.

</p>

<p>OpenID Connect Basic Client is a profile of the OpenID Connect

      Standard 1.0 Specification that is designed to be easy to read and 

      implement for Relying Parties. OpenID Providers should consult the 

      main specification. This profile omits implementation and security

      considerations for OpenID Providers.

</p><a name="toc"></a><br /><hr />

<h3>Table of Contents</h3>

<p class="toc">

<a href="#rnc">1.</a> 

Requirements Notation and Conventions<br />

<a href="#terminology">2.</a> 

Terminology<br />

<a href="#anchor1">3.</a> 

Protocol Flows<br />

    <a href="#anchor2">3.1.</a> 

OpenID Connect Scopes<br />

    <a href="#anchor3">3.2.</a> 

Implicit Flow<br />

        <a href="#rf_prep">3.2.1.</a> 

Client Prepares an Authorization Request<br />

        <a href="#implicit_req">3.2.2.</a> 

Client Sends a Request to the Authorization Server<br />

        <a href="#anchor4">3.2.3.</a> 

Authorization Server Obtains the End-User Consent/Authorization<br />

        <a href="#implicit_res">3.2.4.</a> 

Authorization Server Sends the End-User Back to the Client<br />

    <a href="#anchor5">3.3.</a> 

Check ID Endpoint<br />

        <a href="#anchor6">3.3.1.</a> 

Check ID Request<br />

        <a href="#anchor7">3.3.2.</a> 

Check ID Response<br />

        <a href="#anchor8">3.3.3.</a> 

Error Codes<br />

        <a href="#verification">3.3.4.</a> 

Verification<br />

<a href="#userinfo">4.</a> 

UserInfo Endpoint<br />

    <a href="#anchor11">4.1.</a> 

Requesting UserInfo<br />

    <a href="#id_res">4.2.</a> 

Client Receives UserInfo Response<br />

        <a href="#anchor12">4.2.1.</a> 

Error Response<br />

<a href="#disco_reg">5.</a> 

Discovery and Registration<br />

<a href="#qss">6.</a> 

Query String Serialization<br />

<a href="#security_considerations">7.</a> 

Security Considerations<br />

    <a href="#assertion_manufacture">7.1.</a> 

Assertion Manufacture/Modification<br />

    <a href="#assertion_disclosure">7.2.</a> 

Assertion Disclosure<br />

    <a href="#assertion_redirect">7.3.</a> 

Assertion Redirect<br />

    <a href="#assertion_reuse">7.4.</a> 

Assertion Reuse<br />

    <a href="#assertion_substitution">7.5.</a> 

Assertion Substitution<br />

    <a href="#auth_req_disclosure">7.6.</a> 

Authentication Request Disclosure<br />

    <a href="#authn_proc_threats">7.7.</a> 

Authentication Process Threats<br />

    <a href="#anchor13">7.8.</a> 

Implicit Flow Threats<br />

    <a href="#anchor14">7.9.</a> 

Availability<br />

<a href="#privacy_considerations">8.</a> 

Privacy Considerations<br />

<a href="#IANA">9.</a> 

IANA Considerations<br />

<a href="#rfc.references1">10.</a> 

Normative References<br />

<a href="#anchor16">Appendix A.</a> 

Acknowledgements<br />

<a href="#anchor17">Appendix B.</a> 

Document History<br />

<a href="#rfc.authors">§</a> 

Authors' Addresses<br />

</p>

<br clear="all" />

<a name="rnc"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.1"></a><h3>1. 

Requirements Notation and Conventions</h3>

<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in <a class='info' href='#RFC2119'>[RFC2119] (<span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)</a> .

</p>

<p>Throughout this document, values are quoted to indicate that they are

      to be taken literally. When using these values in protocol messages, the

      quotes MUST NOT be used as part of the value.

</p>

<a name="terminology"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.2"></a><h3>2. 

Terminology</h3>

<p>The following definitions define additional terminology used in this

      specification in addition to those defined in <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0].

</p>

<p></p>

<blockquote class="text"><dl>

<dt>Relying Party (RP)</dt>

<dd>An application requiring identity

          information from an OpenID Provider.

</dd>

<dt>OpenID Provider (OP)</dt>

<dd>A service capable of providing

          identity information to a Relying Party.

</dd>

<dt>Assertion</dt>

<dd>A set of Claims about the End-User that are

          attested to by the OpenID Provider and Resource Servers.

</dd>

<dt>Claim</dt>

<dd>A piece of information about an Entity that a

          Claims Provider asserts about that Entity.

</dd>

<dt>Claims Provider</dt>

<dd>An Authorization Server that can

          return claims about a user.

</dd>

<dt>Entity</dt>

<dd>Something that has separate and distinct

          existence and that can be identified in context.

</dd>

<dt>ID Token</dt>

<dd>A token that contains information about the

          authentication event. It is a signed token, but can be treated as

          opaque by clients that uses the Check ID Endpoint. Relying 

          Parties wanting to process the token directly should refer to the 

          OpenID Connect Standard 1.0 specification.

</dd>

<dt>Check ID Endpoint</dt>

<dd>A protected resource that, when

          presented with an ID Token by the client, returns authentication

          information about the user represented by that ID Token.

</dd>

<dt>UserInfo Endpoint</dt>

<dd>A protected resource that, when

          presented with an access token by the client, returns authorized

          information about the user represented by that access token.

</dd>

</dl></blockquote>

<a name="anchor1"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3"></a><h3>3. 

Protocol Flows</h3>

<p>Authorization requests follow two paths; the implicit flow

      and the authorization code flow. The authorization code flow is

      suitable for clients that can securely maintain a client secret between

      itself and the authorization server whereas the implicit flow is

      suitable for clients that cannot. Clients that do not support TLS MUST

      use the authorization code flow to prevent the interception of access 

      tokens.

</p>

<p>The OpenID Connect Basic Client profile only documents clients using

      the implicit flow. OpenID Providers MUST support both flows.

      Clients wanting to use the authorization code flow and OpenID Providers 

      should consult the OpenID Connect Standard 1.0 specification.

</p>

<a name="anchor2"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.1"></a><h3>3.1. 

OpenID Connect Scopes</h3>

<p>This profile describes two OpenID Connect endpoints that the client

        may request scopes for.

</p>

<p>The scopes request what information is to be made available from

        each of the endpoints for the current user. The User may decline a

        scope request by the client.

</p>

<p>To increase conversion, a site may elect to only request a subset

        of the information from the User Info endpoint.

</p>

<p>OpenID Connect uses scopes as defined in 4.2.1 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0].

</p>

<p>The Check ID Endpoint has a single scope</p>

<blockquote class="text"><dl>

<dt>openid</dt>

<dd>REQUIRED. Requests the user_id and other

            session information.

</dd>

</dl></blockquote>

<p>The User Info Endpoint scopes are:

</p>

<p></p>

<blockquote class="text"><dl>

<dt>profile</dt>

<dd>OPTIONAL requests default profile

            information.

</dd>

<dt>email</dt>

<dd>OPTIONAL requests an email address.

</dd>

<dt>address</dt>

<dd>OPTIONAL requests an address.

</dd>

</dl></blockquote>

<p>These scopes are additive if a RP wanted the default profile

        including email and address they would request:

</p>

<p>

<p>The following is a non-normative example of a Scope

            Request.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>scope=openid profile email phone</pre></div>

<a name="anchor3"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2"></a><h3>3.2. 

Implicit Flow</h3>

<p>The implicit flow consists of the following steps:

</p>

<p></p>

<ol class="text">

<li>Client Prepares an Authorization Request containing the desired

            request parameters.

</li>

<li>Client sends a request to the Authorization Server.

</li>

<li>Authorization Server Authenticates the End-User.

</li>

<li>Authorization Server Obtains the End-User

            Consent/Authorization.

</li>

<li>Authorization Server Sends the End-User back to the Client with

            an Access Token and ID Token.

</li>

</ol>

<a name="rf_prep"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.1"></a><h3>3.2.1. 

Client Prepares an Authorization Request</h3>

<p>When the user wishes to access a Protected Resource, and the

          End-User Authorization has not yet been obtained, the Client

          prepares an Authorization Request to the authorization endpoint.

</p>

The scheme used in the Authorization URL MUST be HTTPS.

</p>

<p>This profile further constrains the following request

          parameters:

</p>

<p></p>

<blockquote class="text"><dl>

<dt>response_type</dt>

<dd>It MUST include <tt>token and id_token</tt>,

              as a space separated list. This requests both an access token

              and id_token to be returned in the URL fragment of the

              response.

</dd>

</dl></blockquote>

<p>Other REQUIRED parameters in the request include the

          following:

</p>

<p></p>

<blockquote class="text"><dl>

<dt>client_id</dt>

<dd>The OAuth client identifier.

</dd>

<dt>scope</dt>

<dd>It MUST include <tt>openid</tt>

              as one of the space separated strings. Optional scope strings of

              <tt>profile</tt>, <tt>email</tt>,

and <tt>address</tt> are also supported.

</dd>

<dt>redirect_uri</dt>

<dd>A redirection URI where the response

              will be sent. This MUST be pre-registered with the provider.

</dd>

<dt>nonce</dt>

<dd>A random, unique string value used to

              mitigate the replay attack this value is returned from the Check

              ID Endpoint.

</dd>

</dl></blockquote>

<p>The request MAY contain the following optional parameters:

</p>

<p></p>

<blockquote class="text"><dl>

<dt>state</dt>

<dd>RECOMENDED. An opaque value used to maintain

              state between the request and the callback, used to protect

              against XSRF attacks.

</dd>

<dt>display</dt>

<dd>A string value used to convey desired

              display format. The value are either <tt>none</tt>,

              <tt>popup</tt>, <tt>touch</tt>,

or <tt>mobile</tt>.

</dd>

<dt>prompt</dt>

<dd>A space delimited list that can contain

              <tt>login</tt>, <tt>consent</tt>,

              and <tt>select_account</tt>. It is used to

              control the dialogue that is to be shown to the user upon the

              request.

</dd>

</dl></blockquote>

Authorization servers MUST support the use of the HTTP <tt>GET</tt> method as defined in <a class='info' href='#RFC2616'>RFC 2616 (<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.)</a> [RFC2616] and MAY support the <tt>POST</tt> method at the authorization endpoint.

</p>

<p>If using the HTTP <tt>GET</tt> method, the

          parameters are serialized using <a class='info' href='#qss'>Query String 

          Serialization<span> (</span><span class='info'>Query String Serialization</span><span>)</span></a>. If using the HTTP <tt>POST

          </tt> method, the request parameters are added to the HTTP request 

          entity-body using the 

          <tt>application/x-www-form-urlencoded</tt> format

          as defined by <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.

</p>

<p>The following is a non-normative example of an

            Authorization Request URL. Note that the line wraps within the

            values are for display purpose only:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://server.example.com/authorize?

response_type=token%20id_token

&client_id=s6BhdRkqt3

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

&scope=openid%20profile

&state=af0ifjsldkj</pre></div>

<a name="implicit_req"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.2"></a><h3>3.2.2. 

Client Sends a Request to the Authorization Server</h3>

<p>Having constructed the Authorization Request, the client sends it

          to the Authorization Endpoint. This MAY happen via HTTPS redirect, 

          hyperlinking, or any other secure means of directing the User-Agent 

          to the URL.

</p>

<p>Following is a non-normative example using HTTP redirect. Note:

          Line wraps are for display purpose only.

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found

Location: https://server.example.com/authorize?

response_type=token%20id_token

&client_id=s6BhdRkqt3

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

&state=af0ifjsldkj

</pre></div>

<a name="anchor4"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.3"></a><h3>3.2.3. 

Authorization Server Obtains the End-User Consent/Authorization</h3>

<p>The Authorization Server MUST obtain an authorization decision,

          for the requested scopes. This MAY be done by presenting the user

          with a dialogue that allows the user to recognize what he is

          consenting to and obtain his consent or by establishing approval via

          other means (for example, via previous administrative approval).

</p>

<p>The <tt>openid</tt> scope grants the RP access

          to the user identifier of the authenticated user of the session.

</p>

<p>All other scopes are optional. It is up to the OpenID Provider

          to determine if an error should be returned in the case of the user 

          declining to authorize scopes other than 

<tt>openid</tt>.

</p>

<a name="implicit_res"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.4"></a><h3>3.2.4. 

Authorization Server Sends the End-User Back to the Client</h3>

<p>Once the authorization is determined, the Authorization Server

          returns a positive or negative response.

</p>

<a name="implicit_ok"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.4.1"></a><h3>3.2.4.1. 

End-User Grants Authorization</h3>

<p>If the resource owner grants the access request, the

            authorization server issues an access token and delivers it to the

            client by adding the following parameters to the fragment

            component of the redirection URI using the 

            <tt>application/x-www-form-urlencoded</tt>

            format as defined in Section 4.2.2 of

            <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0]

</p>

<p>In the implicit flow, the entire response is returned in the

            fragment component of the redirect URL, as defined in 4.2.2 of

            <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0]

</p>

<p></p>

<blockquote class="text"><dl>

<dt>access_token</dt>

<dd>REQUIRED. The Access Token for the

                User Info Endpoint.

</dd>

<dt>token_type</dt>

<dd>REQUIRED. The value MUST be

                "bearer"

</dd>

<dt>id_token</dt>

<dd>REQUIRED. The ID Token for the

                Check ID Endpoint.

</dd>

<dt>state</dt>

<dd>REQUIRED if the <tt>state</tt>

                parameter is present in the request. It MUST be set to the

                exact value of the <tt>state</tt> parameter

                received from the client in the authorization request.

</dd>

<dt>expires_in</dt>

<dd>OPTIONAL. The expiration time in

                seconds of the access_token

</dd>

</dl></blockquote>

<p>The client can then use the Access Token to access protected

            resources at Resource Servers.

</p>

<p>The following is a non-normative example. Line wraps

              after the second line is for the display purpose

              only:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>HTTP/1.1 302 Found

Location: https://client.example.com/#

access_token=SlAV32hkKG&

token_type=bearer&

id_token=1234567.SlAV32hkKG.abcde1234&

expires_in=3600&

&state=af0ifjsldkj</pre></div>

<a name="implicit_authz_error"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.2.4.2"></a><h3>3.2.4.2. 

End-User Denies Authorization or Invalid Request</h3>

<p>If the user denies the authorization or the user authentication

            fails, the authorization server MUST return the negative 

            authorization response as defined in 4.2.2.1 of 

            <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0]. No other parameters 

            SHOULD be returned.

</p>

<a name="anchor5"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3"></a><h3>3.3. 

Check ID Endpoint</h3>

<p>The Check ID Endpoint validates the id_token and returns a

        text <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] object which contains

        information about the end user associated with the supplied

        id-token.

</p>

<p>The id_token is used to manage the signon event and user

        identifier, separately from access to the UserInfo Endpoint and other

        OAuth 2.0 protected resources that the user is granting access to. The

        id_token is audience restricted to a particular client via the audience 

        and nonce.

</p>

<p>A full explanation of how to use the id_token to perform session

        management can be found in the <a class='info' href='#OpenID.Session'>OpenID

        Connect Session Management 1.0<span> (</span><span class='info'>de Medeiros, B., “OpenID Connect Session Management 1.0,” September 2011.</span><span>)</span></a> [OpenID.Session]

</p>

<a name="anchor6"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.1"></a><h3>3.3.1. 

Check ID Request</h3>

<p>To request the information about the authentication performed on

          the user, the following listed parameters are sent to the Check ID

          Endpoint.

</p>

<p>The paramaters MAY be passed as query paramaters in a GET or as

          form encoded in a POST.

</p>

<p></p>

<blockquote class="text"><dl>

<dt>id_token</dt>

<dd>REQUIRED. The id_token obtained from

              an OpenID Connect authorization request. 

</dd>

</dl></blockquote>

<p><p>The following is a non-normative example of a request

              to the Check ID Endpoint:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>Request:

GET /op/check_id?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6

ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs

ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa

WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a

JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

Host: server.example.com

</pre></div>

<a name="anchor7"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.2"></a><h3>3.3.2. 

Check ID Response</h3>

<p>The response is a text <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] object

          using the <tt>application/json</tt> media type

          with the following parameters.

</p>

<p></p>

<blockquote class="text"><dl>

<dt>iss</dt>

<dd>REQUIRED. The unique identifier of the issuer

              of the response.

</dd>

<dt>user_id</dt>

<dd>REQUIRED. A locally unique and never

              reassigned identifier for the user, which is intended to be

              consumed by the Client. e.g. <tt>24400320</tt>

or <tt>AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4</tt>.

              It MUST NOT exceed 255 ASCII characters in length.

</dd>

<dt>aud</dt>

<dd>REQUIRED. This member identifies the audience

              that this ID Token is intended for. It is client_id of the RP.

</dd>

<dt>exp</dt>

<dd>REQUIRED. Type Integer. Identifies the

              expiration time on or after which the ID Token MUST NOT be

              accepted for processing. The processing of this parameter

              requires that the current date/time MUST be before the

              expiration date/time listed in the value. Implementers MAY

              provide for some small leeway, usually no more than a few

              minutes, to account for clock skew. The value is number of

              seconds from 1970-01-01T0:0:0Z as measured in UTC until the

              desired date/time. See <a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a> [RFC3339]

              for details regarding date/times in general and UTC in

              particular.

</dd>

<dt>iso29115</dt>

<dd>OPTIONAL. (entity authentication

              assurance): Specifies the X.eaa / <a class='info' href='#ISO29115'>ISO/IEC29115<span> (</span><span class='info'>McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 --           Information technology - Security techniques - Entity authentication           assurance framework,” .</span><span>)</span></a> [ISO29115] entity authentication

              assurance level of the authentication performed.

</dd>

<dt>nonce</dt>

<dd>REQUIRED. It MUST be set to the

              exact value of the <tt>nonce</tt> parameter

              received from the client in the authorization request.

</dd>

</dl></blockquote>

<p>The following is a non-normative example of a request to

            the Check ID Endpoint:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>Request:

GET /op/check_id?id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6

ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs

ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa

WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a

JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

Host: server.example.com

Response:

HTTP/1.1 200 OK

Content-Type: application/json

{

"iss": "http://server.example.com",

"user_id": "Jane Doe",

"aud": "http://client.example.net",

"exp":1311281970

}

</pre></div>

<a name="anchor8"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.3"></a><h3>3.3.3. 

Error Codes</h3>

<p>In addition to the error codes defined in Section 5.2 of <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0], this specification defines the

          following error codes.

</p>

<p></p>

<blockquote class="text"><dl>

<dt>invalid_id_token</dt>

<dd>The ID Token is not valid for the

              requested resource, malformed, is in an incorrect format, or

              expired.

</dd>

</dl></blockquote>

<a name="verification"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.4"></a><h3>3.3.4. 

Verification</h3>

<a name="anchor9"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.4.1"></a><h3>3.3.4.1. 

Request Verification</h3>

<p>The authorization server validates the request to ensure all

            required parameters are present and valid.

</p>

<a name="anchor10"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.3.3.4.2"></a><h3>3.3.4.2. 

Response Verification</h3>

<p>To verify the validity of the Response, the client MUST to the

            following:

</p>

<p></p>

<ol class="text">

<li>Check that the returned nonce is equal to the nonce in the

                Authorization Request.

</li>

<li>Verify that the response was intended for the recipient,

                using the <tt>aud</tt> (audience) contained

                within the response.

</li>

<li>If <tt>issued_to</tt> is present then it

                MUST contain an identifier for a trusted intermediary. If

                <tt>issued_to </tt>is unknown then the

                assertion MUST be rejected.

</li>

<li>Check that the authorization server that responded was really

                the intended authorization server through a TLS/SSL server 

                certificate check.

</li>

<li>The Check ID Endpoint has not returned an error for

                the ID Token being expired or invalid.

</li>

</ol>

<a name="userinfo"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.4"></a><h3>4. 

UserInfo Endpoint</h3>

<p>To obtain the additional attributes and tokens, the client makes a

      GET or POST request to the UserInfo Endpoint.

</p>

<p>NOTE: The UserInfo Endpoint response is not guaranteed to be about the

      Subject in the session. Therefore, it MUST NOT be used as an assertion

      about the user in the session unless the user_id matches the user_id in

      the ID Token.

</p>

<a name="anchor11"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.4.1"></a><h3>4.1. 

Requesting UserInfo</h3>

<p>Clients MAY send requests with the following parameters to the

        UserInfo Endpoint to obtain further information about the user. The

        UserInfo Endpoint is an <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0]

        protected resource that complies with the <a class='info' href='#OAuth.2.0.Bearer'>Bearer Token<span> (</span><span class='info'>Jones, M., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Protocol: Bearer Tokens,” July 2011.</span><span>)</span></a> [OAuth.2.0.Bearer] specification. As such,

        the access token SHOULD be specified via the HTTP Authorization

        header.

</p>

<p></p>

<blockquote class="text"><dl>

<dt>access_token</dt>

<dd>REQUIRED. The access_token obtained

            from an OpenID Connect authorization request. This parameter MUST

            only be sent using one method through either HTTP Authorization

            header or query string.

</dd>

<dt>schema</dt>

<dd>OPTIONAL. The schema in which the data is to

be returned. The only predefined value is <tt>openid</tt>.

            If this parameter is not included, the response may be a

            proprietary schema to support backwards compatibility. A URL MAY

            be passed to define custom schemes not specified by short names.

            Custom schema names and responses are out of scope for this

            specification.

</dd>

<dt>id</dt>

<dd>This identifier is reserved for backwards

compatibility. It MUST be ignored by the endpoint if the <tt>openid</tt> schema is used.

</dd>

</dl></blockquote>

<p>The following is a non-normative example. Line wraps are

          for display purpose only:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /userinfo HTTP/1.1

Host: server.example.com

Authorization: Bearer vF9dft4qmT

</pre></div>

<a name="id_res"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.4.2"></a><h3>4.2. 

Client Receives UserInfo Response</h3>

<p>If the requested schema is <tt>openid</tt>, the

        response MUST return a plain text <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627]

        structure that contains a set of members that are a subset of those

        defined below. Additional members (not specified below) MAY also be

        returned.

</p>

The members may be represented in multiple languages and scripts.

        To specify the languages and scripts, <a class='info' href='#RFC5646'>BCP47<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tags MUST be added to each

        member names delimited by a <tt>#</tt>, e.g.,

        <tt>familyName#ja-Kana-JP</tt> for expressing

        Family Name in Katakana in Japanese, which is commonly used to index

        and represent the phonetics of the Kanji representation of the same

represented as <tt>familyName#ja-Hani-JP</tt>.

</p><br /><hr class="insert" />

<a name="ClaimTable"></a>

<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">

<col align="left"><col align="left"><col align="left">

<tr><th align="left">Member</th><th align="left">Type</th><th align="left">Description</th></tr>

<tr>

<td align="left">user_id</td>

<td align="left">string</td>

<td align="left">Identifier for the user at the issuer.</td>

</tr>

<tr>

<td align="left">name</td>

<td align="left">string</td>

<td align="left">User's full name in displayable form including all name parts,

          ordered according to user's locale and preferences.</td>

</tr>

<tr>

<td align="left">given_name</td>

<td align="left">string</td>

<td align="left">Given name or first name of the user.</td>

</tr>

<tr>

<td align="left">family_name</td>

<td align="left">string</td>

<td align="left">Surname or last name of the user.</td>

</tr>

<tr>

<td align="left">middle_name</td>

<td align="left">string</td>

<td align="left">Middle name of the user.</td>

</tr>

<tr>

<td align="left">nickname</td>

<td align="left">string</td>

<td align="left">Casual name of the user that may or may not be the same as the

          <tt>given_name</tt>. For instance, a <tt>nickname</tt> value of <tt>Mike</tt>

          might be returned alongside a <tt>given_name</tt>

          value of <tt>Michael</tt>.</td>

</tr>

<tr>

<td align="left">profile</td>

<td align="left">string</td>

<td align="left">URL of user's profile page.</td>

</tr>

<tr>

<td align="left">picture</td>

<td align="left">string</td>

<td align="left">URL of the user's profile picture.</td>

</tr>

<tr>

<td align="left">website</td>

<td align="left">string</td>

<td align="left">URL of user's web page or blog.</td>

</tr>

<tr>

<td align="left">email</td>

<td align="left">string</td>

<td align="left">The user's preferred e-mail address.</td>

</tr>

<tr>

<td align="left">verified</td>

<td align="left">boolean</td>

<td align="left">True if the user's e-mail address has been verified; otherwise

          false.</td>

</tr>

<tr>

<td align="left">gender</td>

<td align="left">string</td>

<td align="left">The user's gender: <tt>female</tt> or <tt>male</tt>.</td>

</tr>

<tr>

<td align="left">birthday</td>

<td align="left">string</td>

<td align="left">The user's birthday, represented as a date string in MM/DD/YYYY

          format. The year MAY be <tt>0000</tt>, indicating

          that it is omitted.</td>

</tr>

<tr>

<td align="left">zoneinfo</td>

<td align="left">string</td>

<td align="left">String from zoneinfo <a class='info' href='#zoneinfo'>[zoneinfo]<span> (</span><span class='info'>Public Domain, “The tz database,” June 2011.</span><span>)</span></a> timezone

          database. For example, <tt>Europe/Paris</tt> or

          <tt>America/Los_Angeles</tt>.</td>

</tr>

<tr>

<td align="left">locale</td>

<td align="left">string</td>

<td align="left">The user's locale, represented as an <a class='info' href='#RFC5646'>RFC

          5646<span> (</span><span class='info'>Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.</span><span>)</span></a> [RFC5646] language tag. This is typically an <a class='info' href='#ISO639-1'>ISO 639-1 Alpha-2<span> (</span><span class='info'>International Organization for             Standardization, “ISO 639-1:2002. Codes for the representation of names of           languages -- Part 1: Alpha-2 code,” 2002.</span><span>)</span></a> [ISO639‑1] language code in

          lowercase and an <a class='info' href='#ISO3166-1'>ISO 3166-1 Alpha-2<span> (</span><span class='info'>International Organization for             Standardization, “ISO 3166-1:1997. Codes for the representation of names of           countries and their subdivisions -- Part 1: Country codes,” 1997.</span><span>)</span></a> [ISO3166‑1]

          country code in uppercase, separated by a dash. For example, <tt>en-US</tt> or <tt>fr-CA</tt>. As

          a compatibility note, some implementations have used an underscore

          as the separator rather than a dash, for example, <tt>en_US</tt>; Implementations MAY choose to accept

          this locale syntax as well.</td>

</tr>

<tr>

<td align="left">phone_number</td>

<td align="left">string</td>

<td align="left">The user's preferred telephone number. For example, <tt>+1 (425)

          555-1212</tt> or <tt>+56 (2) 687 2400</tt>.</td>

</tr>

<tr>

<td align="left">address</td>

<td align="left">JSON object</td>

<td align="left">The user's preferred address. The value of the <tt>address</tt> member is a <a class='info' href='#RFC4627'>JSON<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] structure containing some or all of

          these string-valued fields: <tt>formatted</tt>,

          <tt>street_address</tt>, <tt>locality</tt>,

          <tt>region</tt>, <tt>postal_code</tt>,

          and <tt>country</tt>. The <tt>street_address</tt>

          field MAY contain multiple lines if the address representation

          requires it. Implementations MAY return only a subset of the fields

          of an <tt>address</tt>, depending upon the

          information available and the user's privacy preferences. For

          example, the <tt>country</tt> and <tt>region</tt> might be returned without returning more

          fine-grained address information.</td>

</tr>

<tr>

<td align="left">updated_time</td>

<td align="left">string</td>

<td align="left">Time the user's information was last updated, represented as a

          <a class='info' href='#RFC3339'>RFC 3339<span> (</span><span class='info'>Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.</span><span>)</span></a> [RFC3339] datetime. For example, <tt>2011-01-03T23:58:42+0000</tt>.</td>

</tr>

</table>

<br clear="all" />

<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Table 1: Reserved Member Definitions </b></font><br /></td></tr></table><hr class="insert" />

<p>Following is a non-normative example of such

          response:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{

 "name": "Jane Doe"

 "given_name": "Jane",

 "family_name": "Doe",

 "email": "janedoe@example.com",

 "picture": "http://example.com/janedoe/me.jpg"

}</pre></div>

<a name="anchor12"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.4.2.1"></a><h3>4.2.1. 

Error Response</h3>

<p>When some error condition arises, the UserInfo Endpoint returns

          the Error Response. In addition to the standard <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0] errors, the UserInfo Endpoint

          may return the following errors:

</p>

<p></p>

<blockquote class="text"><dl>

<dt>unsupported_schema</dt>

<dd>The requested schema is

              unsupported.

</dd>

</dl></blockquote>

<a name="disco_reg"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.5"></a><h3>5. 

Discovery and Registration</h3>

<p>Some OpenID Connect installations can use a pre-configured set of

      OpenID Providers and/or Relying Parties. In those cases, it may not be

      necessary to support dynamic discovery of information about identities

      or services or dynamic registration of clients.

</p>

<p>However, if installations choose to support unanticipated

      interactions between Relying Parties and OpenID Providers that do not

      have pre-configured relationships, they SHOULD accomplish this by

      implementing the facilities defined in the <a class='info' href='#OpenID.Discovery'>OpenID Connect Discovery 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” September 2011.</span><span>)</span></a> [OpenID.Discovery] and <a class='info' href='#OpenID.Registration'>OpenID Connect Dynamic Client Registration

      1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Ed., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” September 2011.</span><span>)</span></a> [OpenID.Registration] specifications.

</p>

<a name="qss"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.6"></a><h3>6. 

Query String Serialization</h3>

<p>In order to serialize the parameters using the query string

      serialization, the client constructs the string by adding the

      parameters and values to the query component using the <tt>application/x-www-form-urlencoded</tt> format as

      defined by <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>.

</p>

<p>Following is a non-normative example of such

        serialization:

</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>GET /authorize?scope=openid&response_type=code

&client_id=s6BhdRkqt3

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

Host: server.example.com</pre></div>

<a name="security_considerations"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.7"></a><h3>7. 

Security Considerations</h3>

<p>In addition to the Security Considerations in <a class='info' href='#OAuth.2.0'>OAuth 2.0<span> (</span><span class='info'>Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” July 2011.</span><span>)</span></a> [OAuth.2.0], the following are the list of 

      threats and remedies that were considered for this specification.

</p>

<a name="assertion_manufacture"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>

<a name="rfc.section.7.1"></a><h3>7.1. 

Assertion Manufacture/Modification</h3>

<p>An assertion is the result of the authentication performed by the

        authorization server that was provided to the client. The assertion is 

        used to pass information about the user or the authentication process 

        from the authorization server to the client.

</p>

<p></p>

<ol class="text">

<li>To mitigate this attack, the assertion may be sent over a

            protected channel such as TLS/SSL. In order to protect the

            integrity of assertions from malicious attack, the authorization 

            server MUST be authenticated. In this specification, the assertion 

            is always sent over TLS/SSL protected channel.

</li>

</ol>