<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Pre-Draft: OpenID Authentication 2.0 - Pre-Draft 11</title>
<meta http-equiv="Expires" content="Tue, 17 Oct 2006 10:22:48 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Authentication 2.0 - Pre-Draft 11">
<meta name="generator" content="xml2rfc v1.31 (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.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
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.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.full td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
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">Pre-Draft</td><td class="header">D. Recordon</td></tr>
<tr><td class="header"> </td><td class="header">VeriSign</td></tr>
<tr><td class="header"> </td><td class="header">J. Hoyt</td></tr>
<tr><td class="header"> </td><td class="header">JanRain</td></tr>
<tr><td class="header"> </td><td class="header">D. Hardt</td></tr>
<tr><td class="header"> </td><td class="header">Sxip</td></tr>
<tr><td class="header"> </td><td class="header">B. Fitzpatrick</td></tr>
<tr><td class="header"> </td><td class="header">Six Apart</td></tr>
<tr><td class="header"> </td><td class="header">October 17, 2006</td></tr>
</table></td></tr></table>
<h1><br />OpenID Authentication 2.0 - Pre-Draft 11</h1>
<h3>Abstract</h3>
<p>
OpenID Authentication provides a way to prove that an End User
owns an Identifier. It does this without the Relying Party needing
access to password, email address, or other sensitive information.
</p>
<p>
OpenID is decentralized. No central authority must approve or
register Relying Parties or Identity Providers. An End User
can freely choose which Identity Provider to use and they can
preserve their Identifier if they switch Identity Providers.
</p>
<p>
While nothing in the protocol requires JavaScript or modern
browsers, the authentication scheme plays nicely with
"AJAX"-style setups. This means an End User can prove their
Identity to a Relying Party without having to leave the page
they are on.
</p>
<p>
As OpenID Authentication uses only standard HTTP requests and
responses, it does not require any special capabilities of the
User-Agent or other software. Extensions to User-Agent's can
simplify the End User interaction, though are not required to
utilize the protocol.
</p>
<p>
The exchange of profile information, and other features not
covered in this specification, is addressed through additional
Service Types built on top of OpenID. OpenID Authentication is
designed to provide a base framework to enable portable
user-centric digital identity in a free and decentralized manner.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
Requirements Notation<br />
<a href="#anchor2">2.</a>
Terminology<br />
<a href="#anchor3">3.</a>
Protocol Overview<br />
<a href="#formats">4.</a>
Data Formats<br />
<a href="#anchor4">4.1.</a>
Protocol Messages<br />
<a href="#btwoc">4.2.</a>
Integer Representations<br />
<a href="#communication">5.</a>
Communication Types<br />
<a href="#direct_comm">5.1.</a>
Direct Communication<br />
<a href="#indirect_comm">5.2.</a>
Indirect Communication<br />
<a href="#generating_signatures">6.</a>
Generating Signatures<br />
<a href="#anchor11">6.1.</a>
Procedure<br />
<a href="#signed_list">6.2.</a>
Signed List Algorithm<br />
<a href="#sign_algos">6.3.</a>
Signature Algorithms<br />
<a href="#anchor12">7.</a>
Initiation and Discovery<br />
<a href="#initiation">7.1.</a>
Initiation<br />
<a href="#normalization">7.2.</a>
Normalization<br />
<a href="#discovery">7.3.</a>
Discovery<br />
<a href="#associations">8.</a>
Establishing Associations<br />
<a href="#anchor21">8.1.</a>
Association Session Request<br />
<a href="#anchor24">8.2.</a>
Association Session Response<br />
<a href="#assoc_types">8.3.</a>
Association Types<br />
<a href="#assoc_sess_types">8.4.</a>
Association Session Types<br />
<a href="#requesting_authentication">9.</a>
Requesting Authentication<br />
<a href="#anchor29">9.1.</a>
Request Parameters<br />
<a href="#realms">9.2.</a>
Realms<br />
<a href="#anchor30">9.3.</a>
Immediate Requests<br />
<a href="#responding_to_authentication">10.</a>
Responding to Authentication Requests<br />
<a href="#positive_assertions">10.1.</a>
Positive Assertions<br />
<a href="#negative_assertions">10.2.</a>
Negative Assertions<br />
<a href="#verification">11.</a>
Verifying Assertions<br />
<a href="#anchor33">11.1.</a>
Checking the Nonce<br />
<a href="#verifying_signatures">11.2.</a>
Verifying Signatures<br />
<a href="#anchor37">11.3.</a>
Verifying Discovered Information<br />
<a href="#identifying">11.4.</a>
Identifying the End User<br />
<a href="#compat_mode">12.</a>
OpenID Authentication 1.1 Compatibility<br />
<a href="#anchor39">12.1.</a>
Relying Parties<br />
<a href="#anchor40">12.2.</a>
Identity Providers<br />
<a href="#extensions">13.</a>
Extensions<br />
<a href="#anchor41">14.</a>
Discovering OpenID Relying Parties<br />
<a href="#anchor42">15.</a>
Security Considerations<br />
<a href="#anchor43">15.1.</a>
Preventing Attacks<br />
<a href="#anchor45">15.2.</a>
User Agents<br />
<a href="#anchor46">15.3.</a>
User Interface Considerations<br />
<a href="#anchor47">Appendix A.</a>
Examples<br />
<a href="#anchor48">Appendix A.1.</a>
Delegation<br />
<a href="#anchor49">Appendix A.2.</a>
XRDS<br />
<a href="#anchor50">Appendix A.3.</a>
HTML Identifier Markup<br />
<a href="#anchor51">Appendix A.4.</a>
Login Form<br />
<a href="#anchor52">Appendix A.5.</a>
XRI CanonicalID<br />
<a href="#pvalue">Appendix B.</a>
Diffie-Hellman Key Exchange Default Value<br />
<a href="#anchor53">Appendix C.</a>
Changes from the Previous OpenID Authentication Specification<br />
<a href="#anchor54">Appendix C.1.</a>
Updated Initiation and Discovery<br />
<a href="#anchor55">Appendix C.2.</a>
Security improvements<br />
<a href="#anchor56">Appendix C.3.</a>
Extensions<br />
<a href="#rfc.references1">16.</a>
Normative References<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.
Requirements Notation</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, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a>.
</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.
Terminology</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Identifier:</dt>
<dd>
An Identifier is a "http" or "https" URI, which is commonly
referred to as a "URL" within this document, or <a href='http://www.oasis-open.org/committees/download.php/15376'>XRI</a>. An "Identifier" may be a Claimed Identifier,
Delegate Identifier, IdP Identifier, or Verified Identifier,
depending on context.
</dd>
<dt>End User:</dt>
<dd>
The person who wants to prove ownership of an Identifier.
</dd>
<dt>User-Agent:</dt>
<dd>
The End User's Web browser. See <a class='info' href='#RFC2616'>[RFC2616]<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,” .</span><span>)</span></a>.
</dd>
<dt>Claimed Identifier:</dt>
<dd>
An Identifier that the End User claims to own which has not yet
been verified by the Relying Party.
</dd>
<dt>Verified Identifier:</dt>
<dd>
An Identifier that the End User has proven to a Relying Party
that they own.
</dd>
<dt>Delegate Identifier:</dt>
<dd>
An alternate Identifier that can be included in the discovery
response.
</dd>
<dt>Relying Party:</dt>
<dd>
RP. A Web application that wants proof that the End User owns an
Identifier.
</dd>
<dt>Identity Provider:</dt>
<dd>
IdP. This is the OpenID Authentication server
that a Relying Party contacts for cryptographic proof that the
End User owns an Identifier.
</dd>
<dt>IdP Identifier:</dt>
<dd>
An Identifier for an Identity Provider.
</dd>
<dt>Diffie-Hellman Key Exchange:</dt>
<dd>
Diffie-Hellman Key Exchange <a class='info' href='#RFC2631'>[RFC2631]<span> (</span><span class='info'>Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a> is a
protocol that allows two parties to share a secret, while
preventing eavesdroppers from learning the secret.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Protocol Overview</h3>
<p>
</p>
<ol class="text">
<li>
The End User <a class='info' href='#initiation'>initiates
authentication<span> (</span><span class='info'>Initiation</span><span>)</span></a> by supplying an Identifier to the
Relying Party via their User Agent.
</li>
<li>
The Relying Party <a class='info' href='#discovery'>performs
discovery<span> (</span><span class='info'>Discovery</span><span>)</span></a> on the Claimed Identifier and establishes
the location of the IdP's endpoint that the End User uses
for authentication.
</li>
<li>
(optional)
The Relying Party and the IdP establish an <a class='info' href='#associations'>association<span> (</span><span class='info'>Establishing Associations</span><span>)</span></a> -- a shared secret
established using Diffie-Hellman Key Exchange. The IdP
uses an association to sign subsequent messages and the
Relying Party to verify those messages.
</li>
<li>
The Relying Party redirects the End User's User Agent to
the IdP with an OpenID <a class='info' href='#requesting_authentication'>Authentication request<span> (</span><span class='info'>Requesting Authentication</span><span>)</span></a>.
</li>
<li>
The IdP establishes whether the End User is authorized
to perform OpenID Authentication and wishes to do
so. The manner in which the End User authenticates to
their IdP is beyond the scope of this document.
</li>
<li>
The IdP redirects the End User's User Agent back to the
Relying Party with an indication either that <a class='info' href='#positive_assertions'>authentication is
approved<span> (</span><span class='info'>Positive Assertions</span><span>)</span></a> or <a class='info' href='#negative_assertions'>authentication failed<span> (</span><span class='info'>Negative Assertions</span><span>)</span></a>.
</li>
<li>
The Relying Party <a class='info' href='#verification'>verifies<span> (</span><span class='info'>Verifying Assertions</span><span>)</span></a> the information
received from the IdP.
</li>
</ol><p>
</p>
<a name="formats"></a><br /><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.
Data Formats</h3>
<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.4.1"></a><h3>4.1.
Protocol Messages</h3>
<p>
The OpenID Authentication protocol messages are
mappings of plain-text keys to plain-text values. The keys and
values are Unicode strings. When the keys and values need to
be converted to bytes, they MUST be encoded using UTF-8.
</p>
<a name="kvform"></a><br /><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.1"></a><h3>4.1.1.
Key-Value Form Encoding</h3>
<p>
A Key-Value form message is a sequence of lines. Each
line begins with a key, followed by a colon, and the value
associated with the key. The line is terminated by a
single newline (codepoint 10, "/n"). A key or value MUST NOT
contain a newline and a key also MUST NOT contain a colon.
</p>
<p>
Additional characters, including whitespace, MUST NOT be
added before or after the colon or newline. The message
MUST be encoded in UTF-8 to produce a byte string.
</p>
<p>
Key-Value Form encoding is used for signature calculation
and for <a class='info' href='#direct_response'>direct
responses<span> (</span><span class='info'>Direct Response</span><span>)</span></a> to Relying Parties.
</p>
<a name="queries"></a><br /><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.2"></a><h3>4.1.2.
HTTP Encoding</h3>
<p>
When a message is sent to an HTTP server, it MUST be encoded
using a form encoding specified in Section 17.13.4 of
<a class='info' href='#HTML401'>[HTML401]<span> (</span><span class='info'>W3C, “HTML 4.01 Specification,” .</span><span>)</span></a>. Likewise, if the "Content-Type"
header is included in the request headers, its value MUST
also be such an encoding.
</p>
<p>
All of the keys in the request message MUST be prefixed
with "openid.". This prefix prevents interference with
other parameters that are passed along with the OpenID
Authentication message. When a message is sent as a POST,
the application processing the HTTP request MUST only use
the values in the POST body and MUST ignore any GET
parameters.
</p>
<p>
This model applies to messages from the User Agent to both
the Relying Party and the IdP, as well as messages from the
Relying Party to the IdP.
</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.4.1.3"></a><h3>4.1.3.
Example</h3>
<p>
Non-normative
</p>
<p>
<p>
The following examples encode the following information:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Key | Value
--------+---------------------------
mode | error
error | This is an example message
</pre></div>
<p>
<p>
Key-Value Form encoded:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>mode:error
error:This is an example message
</pre></div>
<p>
x-www-urlencoded, as in a HTTP POST body or in a URL's
query string (<a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> section 3):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>openid.mode=error&openid.error=This%20is%20an%20example%20message</pre></div>
<a name="btwoc"></a><br /><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.
Integer Representations</h3>
<p>
Arbitrary precision integers MUST be encoded as big-endian
signed two's complement binary strings. Henceforth,
"btwoc" is a function that takes an arbitrary precision
integer and returns its shortest big-endian two's
complement representation. All integers that are used with
Diffie-Hellman are positive. This means that the left-most
bit of the two's complement representation MUST be
zero. If it is not, implementations MUST add a zero byte
at the front of the string.
</p>
<p>Non-normative example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Base 10 number | btwoc string representation
---------------+----------------------------
0 | "\x00"
127 | "\x7F"
128 | "\x00\x80"
255 | "\x00\xFF"
32768 | "\x00\x80\x00"
</pre></div>
<a name="communication"></a><br /><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.
Communication Types</h3>
<a name="direct_comm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
Direct Communication</h3>
<p>
Direct communication is initiated by a Relying Party to an
IdP endpoint URL. It is used for <a class='info' href='#associations'>establishing associations<span> (</span><span class='info'>Establishing Associations</span><span>)</span></a> and
<a class='info' href='#check_auth'>verifying authentication
assertions<span> (</span><span class='info'>Verifying Directly with the Identity Provider</span><span>)</span></a>.
</p>
<a name="direct_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.5.1.1"></a><h3>5.1.1.
Direct Request</h3>
<p>
The message MUST be encoded as a POST body, as specified
by <a class='info' href='#queries'>Section 4.1.2<span> (</span><span class='info'>HTTP Encoding</span><span>)</span></a>.
</p>
<a name="direct_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.5.1.2"></a><h3>5.1.2.
Direct Response</h3>
<p>
The body of a response to a <a class='info' href='#direct_request'>Direct Request<span> (</span><span class='info'>Direct Request</span><span>)</span></a> consists of
an HTTP Response body in <a class='info' href='#kvform'>Key-Value
Form<span> (</span><span class='info'>Key-Value Form Encoding</span><span>)</span></a>. The content-type of the response SHOULD be
"text/plain".
</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.5.1.2.1"></a><h3>5.1.2.1.
Successful Responses</h3>
<p>
A server receiving a properly formed request MUST send a
response with an HTTP status code of 200.
</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.5.1.2.2"></a><h3>5.1.2.2.
Error Responses</h3>
<p>
If a request is malformed or contains invalid arguments,
the server MUST send a response with a status code of
400. The response body MUST be a Key-Value Form <a class='info' href='#kvform'>Section 4.1.1<span> (</span><span class='info'>Key-Value Form Encoding</span><span>)</span></a> message with the following fields:
</p>
<p>
</p>
<ul class="text">
<li>
error
<blockquote class="text">
<p>
Value: Unstructured text error message.
</p>
</blockquote>
</li>
<li>
contact
<blockquote class="text">
<p>
Value: (optional) Contact address for the
administrator of the sever. The contact address
may take any form, as it is intended to be
displayed to a person.
</p>
</blockquote>
</li>
<li>
reference
<blockquote class="text">
<p>
Value: (optional) A reference identifier, such
as a support ticket number or a URL to a news
blog, etc.
</p>
</blockquote>
</li>
</ul><p>
The IdP MAY add additional fields to this response.
</p>
<a name="indirect_comm"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
Indirect Communication</h3>
<p>
In indirect communication, messages are passed through the
User-Agent. This can be initiated by either the Relying
Party or the IdP. Indirect communication is used for <a class='info' href='#requesting_authentication'>authentication
requests<span> (</span><span class='info'>Requesting Authentication</span><span>)</span></a> and <a class='info' href='#responding_to_authentication'>authentication
responses<span> (</span><span class='info'>Responding to Authentication Requests</span><span>)</span></a>.
</p>
<p>
There are two methods for indirect communication: HTTP
redirects and HTML form submission.
Both form submission and redirection require that the sender
know a recipient URL and that the recipient URL expect
indirect messages, as specified in <a class='info' href='#queries'>Section 4.1.2<span> (</span><span class='info'>HTTP Encoding</span><span>)</span></a>. The initiator of the communication chooses which method
of indirect communication is appropriate.
</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.5.2.1"></a><h3>5.2.1.
HTTP Redirect</h3>
<p>
Data can be transferred by issuing a 302, 303, or 307 HTTP
Redirect to the End User's User-Agent. The redirect URL is
the URL of the receiver with the OpenID Authentication
message appended to the query string, as specified in <a class='info' href='#queries'>Section 4.1.2<span> (</span><span class='info'>HTTP Encoding</span><span>)</span></a>.
</p>
<p>This method is deprecated as of OpenID Authentication
version 2.0 though is still required for implementation to
aide in backward compatibility.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2.
HTML FORM Redirection</h3>
<p>
A mapping of keys to values can be transferred by
returning an HTML page to the User-Agent that contains an
HTML form element. Form submission MAY be automated
using JavaScript.
</p>
<p>
The <form> element's "action" attribute value MUST
be the URL of the receiving Web site. Each Key-Value pair
MUST be included in the form as an <input>
element. The key MUST be encoded as the "name" attribute
and the value as the "value" attribute, such that the User
Agent will generate a message as specified in
<a class='info' href='#queries'>Section 4.1.2<span> (</span><span class='info'>HTTP Encoding</span><span>)</span></a> when the form is submitted. The
form MUST include a submit button.
</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.5.2.3"></a><h3>5.2.3.
Indirect Error Responses</h3>
<p>
In the case of a malformed request or one that contains
invalid arguments, the server MUST redirect the User Agent
to the "openid.return_to" URL value if the value is a
valid URL.
</p>
<p>
</p>
<ul class="text">
<li>
openid.mode
<blockquote class="text">
<p>
Value: "error"
</p>
</blockquote>
</li>
<li>
openid.error
<blockquote class="text">
<p>
Value: Unstructured text error message.
</p>
</blockquote>
</li>
<li>
openid.contact
<blockquote class="text">
<p>
Value: (optional) Contact address for the
administrator of the sever. The contact address
may take any form, as it is intended to be
displayed to a person.
</p>
</blockquote>
</li>
<li>
openid.reference
<blockquote class="text">
<p>
Value: (optional) A reference identifier, such
as a support ticket number or a URL to a news
blog, etc.
</p>
</blockquote>
</li>
</ul><p>
The server MAY add additional keys to this response.
</p>
<p>
If the "openid.return_to" value is missing or not a valid
URL, the server SHOULD return a response to the End User
indicating the error and that it is unable to return the
End User to the initiating server.
</p>
<a name="generating_signatures"></a><br /><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.
Generating Signatures</h3>
<p>
The most common usage of an association is as a Message
Authentication Code (MAC) key used to sign OpenID
Authentication messages.
</p>
<p>
When generating MAC keys, the recommendations in <a class='info' href='#RFC1750'>[RFC1750]<span> (</span><span class='info'>Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .</span><span>)</span></a> SHOULD be followed.
</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.6.1"></a><h3>6.1.
Procedure</h3>
<p>
To generate a message signature:
</p>
<ol class="text">
<li>
Determine the appropriate signature list and signature
algorithm from the <a class='info' href='#associations'>association type<span> (</span><span class='info'>Establishing Associations</span><span>)</span></a>.
</li>
<li>
Generate the list to be signed using the correct <a class='info' href='#signed_list'>list algorithm<span> (</span><span class='info'>Signed List Algorithm</span><span>)</span></a>.
</li>
<li>
Convert the list to an octet string by encoding
with <a class='info' href='#kvform'>Key-Value Form
Encoding<span> (</span><span class='info'>Key-Value Form Encoding</span><span>)</span></a>.
</li>
<li>
Apply the correct <a class='info' href='#sign_algos'>signature
algorithm<span> (</span><span class='info'>Signature Algorithms</span><span>)</span></a> to the octet string.
</li>
</ol><p>
</p>
<a name="signed_list"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
Signed List Algorithm</h3>
<p>
The input to the Signed List Algorithm are the message
to be signed, and the list of message keys that are to be
signed with the "openid." prefix removed.
</p>
<p>
To compute the list of key/value pairs to be signed:
</p>
<ol class="text">
<li>
Iterate through the list of keys to be signed in
the order they appear in the input to the algorithm.
For each key, find the value in the message whose key is
equal to the signed list key prefixed with "openid."
</li>
<li>
Append the signed list key and the associated value to
the message to be signed.
</li>
</ol><p>
</p>
<p>
The output of this algorithm is the message to be
signed, and the list of keys that were signed. A message
signed using this algorithm MUST append the list of signed
fields to the message.
</p>
<p>
As the algorithm strips the "openid." prefix from message
keys while looking for a match, it MUST only sign elements
that have keys beginning with "openid." This is to prevent
attacks where the Relying Party is malicious and tries to
have the IdP sign arbitrary data.
</p>
<a name="sign_algos"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.3"></a><h3>6.3.
Signature Algorithms</h3>
<p>
OpenID Authentication supports two signature algorithms:
</p>
<ul class="text">
<li>HMAC-SHA1(<a class='info' href='#RFC2104'>[RFC2104]<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> and <a class='info' href='#RFC3174'>[RFC3174]<span> (</span><span class='info'>Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” .</span><span>)</span></a>)
</li>
<li>HMAC-SHA256 (<a class='info' href='#RFC2104'>[RFC2104]<span> (</span><span class='info'>Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .</span><span>)</span></a> and <a class='info' href='#FIPS180-2'>[FIPS180‑2]<span> (</span><span class='info'>U.S. Department of Commerce and National Institute of Standards and Technology, “Secure Hash Signature Standard,” .</span><span>)</span></a>
</li>
</ul><p>
The use of HMAC-SHA256 is RECOMENDED though at the time
of writing this document, library support seems lacking.
</p><table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Algorithm</th><th align="left">Key Length</th></tr>
<tr>
<td align="left">HMAC-SHA1</td>
<td align="left">160 bits</td>
</tr>
<tr>
<td align="left">HMAC-SHA256</td>
<td align="left">256 bits</td>
</tr>
</table>
<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.7"></a><h3>7.
Initiation and Discovery</h3>
<a name="initiation"></a><br /><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.
Initiation</h3>
<p>
To initiate OpenID Authentication, the Relying Party SHOULD
present the End User with a form that has a field for
entering an Identifier.
</p>
<p>
It is RECOMMENDED that every Relying Party place the <a href='http://openid.net/login-bg.gif'>OpenID logo</a>
at the beginning of the form field where the End User enters
their Identifier. This aides in End User recognition that
they can use their OpenID Identifier at the specific Relying
Party.
</p>
<p>
The form field's "name" attribute SHOULD have the value
"openid_identifier" as to allow User Agents to automatically
prefill the End User's Identifier when visiting a Relying
Party.
</p>
<a name="normalization"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.
Normalization</h3>
<p>
The End User's input MUST be normalized into an
Identifier. If the End User supplies input that does not
include a scheme (http, https, or xri), then the application
needs to determine if the input is an XRI or a URL missing
the scheme.
</p>
<p>
To do so, the Relying Party SHOULD examine the first
character of the input. If it is an XRI Global Context
Symbol ("=", "@", "+", "$", or "!" see <a class='info' href='#XRI Syntax 2.0'>Section 2.2.1.2 of<span> (</span><span class='info'>Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .</span><span>)</span></a> [XRI Syntax 2.0]), then the input
SHOULD be treated as an XRI. If it is not, then the input
SHOULD be treated as an http URL, and prefixed with the
string "http://".
</p>
<p>
URL identifiers MUST be further normalized by following
redirects when retrieving their content and finally applying
the rules in Section 6 of <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> to the
final destination URL. This final URL should be noted by the
Relying Party as the Claimed Identifier and used during
future requests.
</p>
<a name="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.7.3"></a><h3>7.3.
Discovery</h3>
<p>
Discovery is the process where the Relying Party uses the
Identifier to look up ("discover") the necessary information
for initiating requires. OpenID Authentication has three
paths through which to do discovery:
</p>
<p>
</p>
<ol class="text">
<li>
If the identifier is an XRI, <a href='http://www.oasis-open.org/committees/download.php/17293'>XRI resolution</a> will yield an XRDS document
that contains the necessary information.
</li>
<li>
If it is a URL, the <a class='info' href='#Yadis'>Yadis
protocol<span> (</span><span class='info'>Miller, J., “Yadis Specification 1.0,” .</span><span>)</span></a> [Yadis] is first attempted. If it succeeds, the
result is again an XRDS document.
</li>
<li>
If the Yadis protocol fails, the URL is retrieved and
<a class='info' href='#html_disco'>HTML-based discovery<span> (</span><span class='info'>HTML-Based Discovery</span><span>)</span></a> is
attempted.
</li>
</ol><p>
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.1"></a><h3>7.3.1.
Discovered Information</h3>
<p>
Upon successful completion of discovery, the Relying
Party will have the following information:
</p>
<blockquote class="text"><dl>
<dt>IdP Endpoint URL:</dt>
<dd>
The URL that accepts authentication requests. This
MUST be an absolute URL.
</dd>
<dt>Claimed Identifier:</dt>
<dd>
(optional) The normalized Identifier upon which
discovery was performed. The Claimed Identifier is
present unless the End User entered an IdP Identifier
during initiation.
</dd>
<dt>Delegate Identifier:</dt>
<dd>
(optional)
The Identifier that the Relying Party SHOULD perform
authentication using. Upon successful authentication,
the Relying Party SHOULD recognize the End User using
the Claimed Identifier. The Delegate Identifier can
only be present when the End User enters a Claimed
Identifier.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2"></a><h3>7.3.2.
XRDS-Based Discovery</h3>
<p>
If XRI or Yadis discovery was used, the result will be an
XRDS Document. This is a XML document with entries for
services that are related to the Identifier.
It is defined in <a href='REFERENCE XRDS
DOCUMENT'>REFERENCE XRDS DOCUMENT</a>
</p>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.1"></a><h3>7.3.2.1.
Service Elements</h3>
<a name="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.1.1"></a><h3>7.3.2.1.1.
IdP Identifier Element</h3>
<p>
An IdP Identifier Element is a <xrd:Service>
element with the following information:
</p>
<blockquote class="text"><dl>
<dt></dt>
<dd>An <xrd:Type> tag whose text content is
"http://openid.net/server/2.0".
</dd>
<dt></dt>
<dd>An <xrd:URI> tag whose text content is the
IdP Endpoint URL
</dd>
</dl></blockquote><p>
</p>
<a name="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.1.2"></a><h3>7.3.2.1.2.
Claimed Identifier Element</h3>
<p>
A Claimed Identifier Element is an
<xrd:Service> element with the following
information:
</p>
<blockquote class="text"><dl>
<dt></dt>
<dd>An <xrd:Type> tag whose text content is
"http://openid.net/signon/2.0".
</dd>
<dt></dt>
<dd>An <xrd:URI> tag whose text content is the
IdP Endpoint URL.
</dd>
<dt></dt>
<dd>An <openid:Delegate> tag (optional) whose text
content is the Delegate Identifier.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.2"></a><h3>7.3.2.2.
Extracting Authentication Data</h3>
<p>
Once the Relying Party has obtained an XRDS document, it
MUST first search the document (following the rules
described in <a href='REFERENCE XRDS DOCUMENT'>the XRDS
specification</a>) for an IdP Identifier. If none is
found, the RP will search for a Claimed Identifier Element.
</p>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.3"></a><h3>7.3.2.3.
XRI and the CanonicalID Element</h3>
<p>
When the identifier is an XRI, the <xrd:XRD>
element that contains the OpenID Authentication
<xrd:Service> element will also contain a
<CanonicalID> element. The content of this element
MUST be preserved for use after a successful
authentication request, see <a class='info' href='#identifying'>Section 11.4<span> (</span><span class='info'>Identifying the End User</span><span>)</span></a>.
</p>
<p>
The Relying Party MUST confirm that the provider of
the XRD that contains the <CanonicalID> element
is authoritative for that canonical ID. The provider
is identified by the contents of the
<ProviderID> element that is a child of the
<XRD> element. If the provider is not
authoritative for the canonical ID, the Relying Party
MUST resolve the canonical ID to confirm the OpenID
Service Endpoint information that was discovered. The
information discovered when resolving the canonical ID
MUST match the information discovered when resolving
the user-supplied identifier.
</p>
<p>
When using XRI resolution, the canonical ID MUST be
used as the Claimed Identifier. For an XRI to be a
valid identifier, both the <ProviderID> and
<CanonicalID> MUST be present in the discovered
XRDS document.
</p>
<p>
When using URL-based identifiers, the CanonicalID
element SHOULD be ignored if present.
</p>
<a name="anchor20"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.2.4"></a><h3>7.3.2.4.
Additional Information</h3>
<p>
The "openid" namespace is
"http://openid.net/signon/2.0". The "xrd" namespace is
"xri://$xrd*($v*2.0)".
</p>
<p>
For compatibility with deployed code, it is RECOMMENDED
that a Relying Party also accept
"http://openid.net/signon/1.0" or
"http://openid.net/signon/1.1" for the value of
<xrd:Type>. When one of these values is used, the
Relying Party MUST use <a class='info' href='#compat_mode'>OpenID
Authentication 1.1 Compatibility<span> (</span><span class='info'>OpenID Authentication 1.1 Compatibility</span><span>)</span></a>.
</p>
<p>
If an OpenID IdP supports extensions (<a class='info' href='#extensions'>Section 13<span> (</span><span class='info'>Extensions</span><span>)</span></a>), the extensions SHOULD be listed
as additional <xrd:Type> child elements of the
<xrd:Service> element.
</p>
<a name="html_disco"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7.3.3"></a><h3>7.3.3.
HTML-Based Discovery</h3>
<p>
OpenID Authentication 1.1 HTML-based discovery MUST be
supported by Relying Parties. If a Relying Party locates
an IdP using HTML-based discovery, it MUST use <a class='info' href='#compat_mode'>OpenID Authentication 1.1
Compatibility<span> (</span><span class='info'>OpenID Authentication 1.1 Compatibility</span><span>)</span></a> when communicating with that IdP.
</p>
<p>
To use HTML-based discovery, an HTML document MUST be
available at the URL of the Claimed Identifier. In the
HEAD section of the document:
</p>
<blockquote class="text">
<p>
A <LINK> tag MUST be included with attributes
"rel" set to "openid.server", and "href" set to an IdP
Endpoint URL
</p>
<p>
A <LINK> tag MAY be included with attributes
"rel" set to "openid.delegate" and "href" set to the
End User's Delegate Identifier
</p>
</blockquote><p>
</p>
<p> The host of the HTML document MAY be different from the
End User's IdP's host.
</p>
<p>
The "openid.server" and "openid.delegate" URLs MUST NOT
include entities other than "&amp;", "&lt;",
"&gt;", and "&quot;". Other characters that would
not be valid in the HTML document or that cannot be
represented in the document's character encoding MUST be
escaped using the %xx mechanism as described in <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a>.
</p>
<a name="associations"></a><br /><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.
Establishing Associations</h3>
<p>
An "association" is a shared secret between the IdP and
Relying Party. Once established, it is used to verify
subsequent protocol messages.
</p>
<p>
It is RECOMMENDED that a Relying Party form associations if it
is possible for it to do so. If a Relying Party is incapable
of creating or storing associations, <a class='info' href='#verifying_signatures'>Section 11.2<span> (</span><span class='info'>Verifying Signatures</span><span>)</span></a> provides an alternate
verification mechanism referred to as Stateless Mode.
</p>
<a name="anchor21"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.1"></a><h3>8.1.
Association Session Request</h3>
<p>
An association session is initiated by a <a class='info' href='#direct_comm'>direct request<span> (</span><span class='info'>Direct Communication</span><span>)</span></a> from a Relying
Party to an IdP Endpoint URL with the "openid.mode" key
having the value of "associate".
</p>
<a name="anchor22"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.1.1"></a><h3>8.1.1.
Common Request Parameters</h3>
<p>
These parameters are common to all association requests:
</p>
<p>
</p>
<ul class="text">
<li>openid.mode
<blockquote class="text">
<p> Value: "associate"
</p>
</blockquote>
</li>
<li>openid.assoc_type
<blockquote class="text">
<p> The preferred association type. The association
type defines the algorithm to be used to sign
subsequent messages.
</p>
<p> Value: A valid association type from <a class='info' href='#assoc_types'>Section 8.3<span> (</span><span class='info'>Association Types</span><span>)</span></a>
</p>
<p> Default: "HMAC-SHA1".
</p>
</blockquote>
</li>
<li>openid.session_type
<blockquote class="text">
<p> The preferred association session type. This
defines the method used to encrypt the association's
MAC key in transit.
</p>
<p> Value: A valid association session type from
<a class='info' href='#assoc_sess_types'>Section 8.4<span> (</span><span class='info'>Association Session Types</span><span>)</span></a>.
</p>
<p>Default: "no-encryption"
</p>
<p>Note: Unless using transport layer encryption, it
is NOT RECOMMENDED to use "no-encryption" on a
public network, see <a class='info' href='#preventing_eavesdropping'>Section 15.1.1<span> (</span><span class='info'>Eavesdropping Attacks</span><span>)</span></a>.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.1.2"></a><h3>8.1.2.
Diffie-Hellman Request Parameters</h3>
<p>
The following parameters are common to requests whose
requested association type is "DH-SHA1" or "DH-SHA256":
</p>
<p>
</p>
<ul class="text">
<li>
openid.dh_modulus
<blockquote class="text">
<p>Value: base64(btwoc(p))
</p>
<p>Default: See <a class='info' href='#pvalue'>Appendix B<span> (</span><span class='info'>Diffie-Hellman Key Exchange Default Value</span><span>)</span></a>
</p>
</blockquote>
</li>
<li>
openid.dh_gen
<blockquote class="text">
<p>Value: base64(btwoc(g))
</p>
<p>Default: g = 2
</p>
</blockquote>
</li>
<li>
openid.dh_consumer_public
<blockquote class="text">
<p>Value: base64(btwoc(g ^ xa mod p))
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
See <a class='info' href='#dh_sessions'>Section 8.4.2<span> (</span><span class='info'>Diffie-Hellman Association Sessions</span><span>)</span></a> for more information on
these parameters.
</p>
<p>
NOTE: the 'btwoc' function is defined in <a class='info' href='#btwoc'>Section 4.2<span> (</span><span class='info'>Integer Representations</span><span>)</span></a>.
</p>
<a name="anchor24"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2"></a><h3>8.2.
Association Session Response</h3>
<p>
An association session response is a direct response from the
IdP to the Relying Party in <a class='info' href='#kvform'>Key-Value
Form<span> (</span><span class='info'>Key-Value Form Encoding</span><span>)</span></a>.
</p>
<a name="anchor25"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2.1"></a><h3>8.2.1.
Common Response Parameters</h3>
<p>
</p>
<ul class="text">
<li>
session_type
<blockquote class="text">
<p>
The session type for this association. If the IdP
is unwilling or unable to support this association
type, it MUST return an unsuccessful response.
</p>
</blockquote>
</li>
<li>
assoc_handle
<blockquote class="text">
<p>The association handle is used as a key to refer
to this association in subsequent messages.
</p>
<p>Value: A string 255 characters or less in length.
It MUST consist only of ASCII characters in the
range 33-126 inclusive (printable non-whitespace
characters).
</p>
</blockquote>
</li>
<li>
assoc_type
<blockquote class="text">
<p>The value of the "openid.assoc_type" parameter
from the request. If the IdP is unwilling or
unable to support this association type, it MUST
return an unsuccessful response.
</p>
</blockquote>
</li>
<li>
expires_in
<blockquote class="text">
<p> The lifetime, in seconds, of this association.
The Relying Party MUST NOT use the association
after this time has expired.
</p>
<p>Value: An integer, represented in base 10 ASCII.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor26"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2.2"></a><h3>8.2.2.
Unencrypted Response Parameters</h3>
<p>
</p>
<ul class="text">
<li>
mac_key
<blockquote class="text">
<p> The MAC key (shared secret) for this
association, <a class='info' href='#RFC3548'>Base 64<span> (</span><span class='info'>Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” .</span><span>)</span></a> [RFC3548]
encoded.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor27"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2.3"></a><h3>8.2.3.
Diffie-Hellman Response Parameters</h3>
<p>
</p>
<ul class="text">
<li>
dh_server_public
<blockquote class="text">
<p>
Value: base64(btwoc(g ^ xb mod p))
</p>
<p>
Description: The IdP's Diffie-Hellman public key.
</p>
</blockquote>
</li>
<li>
enc_mac_key
<blockquote class="text">
<p>
Value: base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)
</p>
<p>
Description: The MAC key (shared secret),
encrypted with the secret Diffie-Hellman value. H
is either "SHA1" or "SHA256" depending on the
session type.
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
NOTE: The 'btwoc' function is defined in <a class='info' href='#btwoc'>Section 4.2<span> (</span><span class='info'>Integer Representations</span><span>)</span></a>
</p>
<a name="refuse_assoc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.2.4"></a><h3>8.2.4.
Unsuccessful Response Parameters</h3>
<p>
If the IdP does not support an association session type or
association type, it MUST respond with a message
indicating that the association request failed. If there
is another association session type or association type
that is supported, the IdP MAY include that information in
the response.
</p>
<p>
</p>
<ul class="text">
<li>
error
<blockquote class="text">
<p>
Value: (optional) A human-readable message
indicating why the association request failed.
</p>
</blockquote>
</li>
<li>
error_code
<blockquote class="text">
<p>
Value: "unsupported-type"
</p>
</blockquote>
</li>
<li>
session_type
<blockquote class="text">
<p>
Value: (optional) A valid association session type
from <a class='info' href='#assoc_sess_types'>Section 8.4<span> (</span><span class='info'>Association Session Types</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>
assoc_type
<blockquote class="text">
<p>
Value: (optional) An association type supported by
the IdP from <a class='info' href='#assoc_types'>Section 8.3<span> (</span><span class='info'>Association Types</span><span>)</span></a>.
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
Upon receipt of an "unsupported-type" response, the
Relying Party MAY make another request with the specified
association session type and association type. If no
association is established, the Relying Party MAY continue
the authentication process in stateless mode.
</p>
<a name="assoc_types"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.3"></a><h3>8.3.
Association Types</h3>
<a name="hmacsha1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.3.1"></a><h3>8.3.1.
HMAC-SHA1</h3>
<p>
An association of type "HMAC-SHA1" uses the <a class='info' href='#sign_algos'>HMAC-SHA1<span> (</span><span class='info'>Signature Algorithms</span><span>)</span></a> signature algorithm
in combination with the <a class='info' href='#signed_list'>Signed
List<span> (</span><span class='info'>Signed List Algorithm</span><span>)</span></a> algorithm.
</p>
<a name="hmacsha256"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.3.2"></a><h3>8.3.2.
HMAC-SHA256</h3>
<p>
An association of type "HMAC-256" uses the <a class='info' href='#sign_algos'>HMAC-SHA256<span> (</span><span class='info'>Signature Algorithms</span><span>)</span></a> signature
algorithm in combination with the <a class='info' href='#signed_list'>Signed List<span> (</span><span class='info'>Signed List Algorithm</span><span>)</span></a> algorithm.
</p>
<a name="assoc_sess_types"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.4"></a><h3>8.4.
Association Session Types</h3>
<p>
OpenID Authentication defines three valid association
session types: "no-encryption", "DH-SHA1", and "DH-SHA256".
</p>
<a name="anchor28"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.4.1"></a><h3>8.4.1.
No-Encryption Association Sessions</h3>
<p>
In a "no-encryption" association session, the IdP sends
the association MAC key in plain-text to the Relying Party.
This makes it possible for an eavesdropper to intercept
the key, and forge messages to this Relying Party.
Therefore, no-encryption association sessions SHOULD NOT
be used unless the messages are using transport-level
encryption. See <a class='info' href='#preventing_eavesdropping'>Section 15.1.1<span> (</span><span class='info'>Eavesdropping Attacks</span><span>)</span></a>
for more information.
</p>
<p>
The MAC key sent by the IdP MUST be the length specified
for this association in <a class='info' href='#sign_algos'>Section 6.3<span> (</span><span class='info'>Signature Algorithms</span><span>)</span></a>.
</p>
<a name="dh_sessions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8.4.2"></a><h3>8.4.2.
Diffie-Hellman Association Sessions</h3>
<p>
The "DH-SHA1" and DH-SHA256" association types use
Diffie-Hellman Key Exchange to securely transmit the
shared secret.
</p>
<p>
The MAC key MUST be the same length as the output of H,
the hash function - 160 bits (20 bytes) for DH-SHA1 or 256
bits (32 bytes) for DH-SHA256, as well as the output of
the signature algorithm of this association.
</p>
<p>
The Relying Party specifies a modulus, p, and a generator,
g. The Relying Party chooses a random private key xa and
Identity Provider chooses a random private key xb, both in
the range [1 .. p-1]. The shared secret used to encrypt
the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb
mod p = (g ^ xb) ^ xa mod p. For more information, see
<a class='info' href='#RFC2631'>[RFC2631]<span> (</span><span class='info'>Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a>. For information on the
selection of random values, see <a class='info' href='#RFC1750'>[RFC1750]<span> (</span><span class='info'>Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .</span><span>)</span></a>.
</p>
<a name="requesting_authentication"></a><br /><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.
Requesting Authentication</h3>
<p>
Once the Relying Party has successfully performed discovery
and (optionally) created an association with the discovered
IdP Endpoint URL, it can send an authentication request to the
IdP to obtain an assertion. An authentication request is an
<a class='info' href='#indirect_comm'>indirect request<span> (</span><span class='info'>Indirect Communication</span><span>)</span></a>.
</p>
<a name="anchor29"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1.
Request Parameters</h3>
<p>
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
Value: "http://openid.net/signon/2.0"
</p>
<p>
This value MUST be present for the request to be a
valid OpenID Authentication 2.0 request.
</p>
<p>
Note: If an IdP receives an authentication request
with this parameter missing or with a lower version
number, it SHOULD still respond to the request. If
it does respond it MUST use <a class='info' href='#compat_mode'>OpenID Authentication 1.1
Compatibility<span> (</span><span class='info'>OpenID Authentication 1.1 Compatibility</span><span>)</span></a> when communicating with that
Relying Party.
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>
Value: "checkid_immediate" or "checkid_setup"
</p>
<p>
Note: If the Relying Party wishes the End User to be
able to interact with the IdP, "checkid_setup"
should be used. An example of a situation where
interaction between the End User and the IdP is not
desired is when the authentication request is
happening asynchronously in JavaScript.
</p>
</blockquote>
</li>
<li>
openid.identity
<blockquote class="text">
<p>
Value: (optional) Delegate Identifier when
available, otherwise the Claimed Identifier
</p>
<p>
Note: If this is set to the special value
"http://openid.net/identifier_select/2.0" then the
IdP MAY choose an Identifier that belongs to the End
User.
</p>
</blockquote>
</li>
<li>
openid.assoc_handle
<blockquote class="text">
<p>
Value: (optional) A handle for an association
between the Relying Party and the IdP that should be
used to sign the response.
</p>
<p>
Note: If no association handle is sent, the
transaction will take place in stateless mode.
</p>
</blockquote>
</li>
<li>
openid.return_to
<blockquote class="text">
<p>
Value: URL to which the IdP SHOULD return the User
Agent with the response indicating the status of the
request.
</p>
</blockquote>
</li>
<li>
openid.realm
<blockquote class="text">
<p>
Value: (optional) URL pattern the IdP SHOULD ask the
End User to trust. See <a class='info' href='#realms'>Section 9.2<span> (</span><span class='info'>Realms</span><span>)</span></a>.
</p>
<p>
Default: return_to URL
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="realms"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.2"></a><h3>9.2.
Realms</h3>
<p>
A "realm" is a pattern that represents the part of
URL-space for which an OpenID Authentication request is
valid. A realm is designed to give the End User an
indication of the scope of the authentication request. IdPs
SHOULD present the realm when requesting the End User's
approval for an authentication request. IdPs MAY use the
realm to allow the End User to automate approval of
authentication requests.
</p>
<p>
A realm pattern is a URL, with the following changes:
</p>
<ul class="text">
<li>
A realm MUST NOT contain a URI fragment
</li>
<li>
A realm MAY contain a wild-card at the beginning of
the URL authority section. A wild-card consists of the
characters "*." prepended to the DNS name in the
authority section of the URL.
</li>
</ul><p>
</p>
<p>
A URL matches a realm if:
</p>
<ul class="text">
<li>
The URL scheme (<a class='info' href='#RFC3986'>RFC 3986, section
3.1<span> (</span><span class='info'>Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a> [RFC3986]) and port of the URL are identical to
those in the realm.
</li>
<li>
The URL's path is equal to or a sub-directory of the
realm's path.
</li>
<li>
Either:
<ol class="text">
<li>
The realm's domain contains the wild-card
characters "*.", and the trailing part of the URL's
domain is identical to the part of the realm
following the "*." wildcard, or
</li>
<li>
The URL's domain is identical to the realm's
domain
</li>
</ol>
</li>
</ul><p>
The "openid.return_to" URL MUST match the
"openid.realm", or the IdP MUST return an error.
</p>
<p>
It is RECOMMENDED that IdP's protect their End Users from
requests with overly-general realms, like http://*.com/
or http://*.co.uk/. Determining if a realm is overly-general
is at the discretion of the IdP.
</p>
<a name="anchor30"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.3"></a><h3>9.3.
Immediate Requests</h3>
<p>
When requesting authentication, the Relying Party MAY
request that the IdP not interact with the End User. In
this case the IdP MUST respond immediately with either an
assertion that authentication is successful, or a response
indicating that the request cannot be completed without
further user interaction. This is accomplished by an
authentication request with "openid.mode" set to
"checkid_immediate".
</p>
<a name="responding_to_authentication"></a><br /><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.
Responding to Authentication Requests</h3>
<p>
When an authentication request comes from the User-Agent via
<a class='info' href='#indirect_comm'>indirect communication<span> (</span><span class='info'>Indirect Communication</span><span>)</span></a>,
the IdP SHOULD identify the User-Agent, and determine whether
the End User wishes to complete the authentication. If the
End User can be identified and wishes to complete the
authentication, the IdP should send a <a class='info' href='#positive_assertions'>positive assertion<span> (</span><span class='info'>Positive Assertions</span><span>)</span></a> to the
Relying Party.
</p>
<p>
Methods of identifying the End User and getting approval to
finish authentication are beyond the scope of this
specification.
</p>
<p>
If no Identifier was specified in the request and there are
Identifiers in the control of the End User, the IdP SHOULD
allow the End User to choose which Identifier to use. If an
Identifier was specified, the IdP SHOULD only issue assertions
about the specified Identifier.
</p>
<p>
If the Relying Party supplied an association handle with the
authentication request, the IdP SHOULD attempt to look up an
association based on that handle. If the association is
missing or expired, the IdP SHOULD send the
"openid.invalidate_handle" parameter as part of the response
with the value of the request's "openid.assoc_handle"
parameter, and SHOULD proceed as if no association handle was
specified.
</p>
<p>
If no association handle is specified, the IdP SHOULD create a
private association for signing the response. The IdP MUST
store this association and MUST respond to later requests to
check the signature of the response in <a class='info' href='#verifying_signatures'>stateless mode<span> (</span><span class='info'>Verifying Signatures</span><span>)</span></a>.
</p>
<a name="positive_assertions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.1"></a><h3>10.1.
Positive Assertions</h3>
<p>
Positive assertions are <a class='info' href='#indirect_comm'>indirect responses<span> (</span><span class='info'>Indirect Communication</span><span>)</span></a> with the following fields:
</p>
<p>
</p>
<ul class="text">
<li>
openid.ns
<blockquote class="text">
<p>
Value: "http://openid.net/signon/2.0"
</p>
<p>
Note: This defines the interpretation of the OpenID
Authentication arguments without a namespace. To be
an OpenID Authentication 2.0 response, the given
value must be present.
</p>
</blockquote>
</li>
<li>
openid.mode
<blockquote class="text">
<p>Value: "id_res"
</p>
</blockquote>
</li>
<li>
openid.identity
<blockquote class="text">
<p>
Value: (optional) The Identifier about which the IdP
is making a positive authentication assertion.
</p>
<p>
Note: The Identifier MAY be omitted if an extension
is in use that makes the response meaningful without
it.
</p>
</blockquote>
</li>
<li>
openid.return_to
<blockquote class="text">
<p>
Value: Verbatim copy of the return_to URL parameter
sent in the request.
</p>
<p>
Note: Because the "openid.return_to" URL is signed
by the IdP, a Relying Party can make sure outside
parties haven't sent responses with query parameters
that were not included in the "openid.return_to"
URL.
</p>
</blockquote>
</li>
<li>
openid.response_nonce
<blockquote class="text">
<p>
Value: A string that MUST be unique to this
particular successful authentication response. The
nonce MUST start with the current time on the
server, and MAY have additional characters appended
to the end as necessary to make each response
unique. The date and time MUST be formatted as
specified in section 5.6 of <a class='info' href='#RFC3339'>[RFC3339]<span> (</span><span class='info'>Newman, C. and G. Klyne, “Date and Time on the Internet: Timestamps,” .</span><span>)</span></a>, with the following restrictions: </p>
<ul class="text">
<li> All times must be in the UTC
timezone, indicated with a "Z".
</li>
<li> No
fractional seconds are allowed
</li>
</ul> For
example: 2005-05-15T17:11:51ZUNIQUE
</blockquote>
</li>
<li>
openid.invalidate_handle
<blockquote class="text">
<p>
Value: (optional) If the Relying Party sent an
invalid association handle with the request, it
SHOULD be included here. If it is present, this
field MUST be signed.
</p>
</blockquote>
</li>
<li>
openid.assoc_handle
<blockquote class="text">
<p>
Value: The handle for the association that was used
to sign this assertion.
</p>
</blockquote>
</li>
<li>
openid.signed
<blockquote class="text">
<p>
Value: (optional) Comma-separated list of signed
fields.
</p>
<p>
Note: If the association used to sign this response
used the <a class='info' href='#signed_list'>Signed
List<span> (</span><span class='info'>Signed List Algorithm</span><span>)</span></a> algorithm, this MUST be present. If it
is present, this entry consists of the fields
without the "openid." prefix that the signature
covers. This list MUST contain at least "return_to"
and "response_nonce". Additionally, if the IdP is
making an assertion about an Identifier, the
"identity" field MUST be present. For example,
"identity,return_to,response_nonce".
</p>
</blockquote>
</li>
<li>
openid.sig
<blockquote class="text">
<p>
Value: Base 64 encoded signature calculated as
specified in <a class='info' href='#generating_signatures'>Section 6<span> (</span><span class='info'>Generating Signatures</span><span>)</span></a>.
</p>
<p>
Note: Successful authentication messages from the
IdP to the Relying Party MUST be signed.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="negative_assertions"></a><br /><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.2"></a><h3>10.2.
Negative Assertions</h3>
<p>
If the IdP is unable to identify the End User or the End
User does not or cannot approve the authentication request,
the IdP SHOULD send a negative assertion to the Relying
Party as an <a class='info' href='#indirect_comm'>indirect
response<span> (</span><span class='info'>Indirect Communication</span><span>)</span></a>.
</p>
<a name="anchor31"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.2.1"></a><h3>10.2.1.
In Response to Immediate Requests</h3>
<p>
If the request was an immediate request, there is no chance
for the End User to interact with pages on the IdP to provide
identifying credentials or approval of a request.
A negative assertion of an immediate request takes the
following form:
</p>
<ul class="text">
<li>
openid.mode
<blockquote class="text">
<p>Value: "id_res"
</p>
</blockquote>
</li>
<li>
openid.user_setup_url
<blockquote class="text">
<p>
Value: A URL that the End User may visit to complete the
request. The Relying Party may redirect the End User to
this URL, or provide the End User with a link that points
to this URL. The request is no longer immediate.
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="anchor32"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10.2.2"></a><h3>10.2.2.
In Response to Non-Immediate Requests</h3>
<p>
Since the IdP may display pages to the End User and
request credentials from the End User, a negative response to a
request that is not immediate is definitive. It takes the
following form:
</p>
<ul class="text">
<li>
openid.mode
<blockquote class="text">
<p>Value: "cancel"
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
In a lot of cases, the Relying Party won't get a cancel
mode response; the End User will just quit or press back
within their User-Agent. But if it is returned, the
Relying Party SHOULD return to what it was doing.
</p>
<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.11"></a><h3>11.
Verifying Assertions</h3>
<p>
When the Relying Party receives a positive assertion, it MUST
verify the following before accepting the assertion:
</p>
<ul class="text">
<li>
An assertion has not yet been accepted from this
IdP with the same value for "openid.response_nonce"
</li>
<li>
The signature on the assertion is valid
</li>
<li>
Discovered information from the Identifier matches the
information in the assertion.
</li>
</ul><p>
</p>
<a name="anchor33"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.
Checking the Nonce</h3>
<p>
To prevent replay attacks, the agent checking the signature
SHOULD keep track of the nonce values included in positive
assertions and never accept the same value more than once
for the same IdP Endpoint URL. When using
"check_authentication", the IdP is responsible for
preventing replay attacks. When the Relying Party checks the
signature on an assertion, it is responsible for preventing
replay attacks.
</p>
<p>
The time-stamp may be used to reject responses that are too
far away from the current time, limiting the amount of time
that nonces must be stored to prevent attacks. The
acceptable range is implementation dependent. A larger range
requires storing more nonces for a longer time. A shorter
range increases the chance that clock-skew and transaction
time will cause a spurious rejection.
</p>
<a name="verifying_signatures"></a><br /><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.2"></a><h3>11.2.
Verifying Signatures</h3>
<p>
If the Relying Party has stored an association with the
association handle specified in the assertion, it MUST check
the signature on the assertion itself. If it does not have
an association stored, it MUST <a class='info' href='#check_auth'>request that the IdP verify the
signature<span> (</span><span class='info'>Verifying Directly with the Identity Provider</span><span>)</span></a> via Stateless mode.
</p>
<a name="anchor34"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.2.1"></a><h3>11.2.1.
Verifying with an Association</h3>
<p>
The Relying Party follows the same procedure that the
IdP followed in <a class='info' href='#generating_signatures'>generating the signature<span> (</span><span class='info'>Generating Signatures</span><span>)</span></a>, and then compares the
signature in the response to the signature it
generated. If the signatures do not match, the assertion
is invalid.
</p>
<p>
If an authentication request included an association
handle for an association between the IdP and the Relying
party, and the IdP no longer wishes to use that handle
(because it has expired or the secret has been
compromised, for instance), the IdP will send a response
that must be verified directly with the IdP, as specified
in <a class='info' href='#check_auth'>Section 11.2.2<span> (</span><span class='info'>Verifying Directly with the Identity Provider</span><span>)</span></a>. In that instance, the IdP
will include the field "openid.invalidate_handle" set to
the association handle that the Relying Party included
with the original request.
</p>
<a name="check_auth"></a><br /><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.2.2"></a><h3>11.2.2.
Verifying Directly with the Identity Provider</h3>
<p>
To verify a signature directly with the IdP, the Relying
Party sends a <a class='info' href='#direct_request'>direct
request<span> (</span><span class='info'>Direct Request</span><span>)</span></a> to the IdP. This is known as Stateless
mode.
</p>
<a name="anchor35"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.2.2.1"></a><h3>11.2.2.1.
Request Parameters</h3>
<p>
</p>
<ul class="text">
<li>
openid.mode
<blockquote class="text">
<p>Value: "check_authentication"
</p>
</blockquote>
</li>
<li>
Exact copies of all fields from the authentication
response, except for "openid.mode".
</li>
</ul><p>
</p>
<a name="anchor36"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.2.2.2"></a><h3>11.2.2.2.
Response Parameters</h3>
<p>
</p>
<ul class="text">
<li>
mode
<blockquote class="text">
<p>Value: "id_res"
</p>
</blockquote>
</li>
<li>
is_valid
<blockquote class="text">
<p>Value: "true" or "false"
</p>
<p>Description: Boolean; whether the signature is
valid.
</p>
</blockquote>
</li>
<li>
invalidate_handle
<blockquote class="text">
<p>
Value: (optional) An association handle
</p>
<p>
Description: The association handle sent in
the request, if the server confirms that it is
invalid.
</p>
</blockquote>
</li>
</ul><p>
</p>
<p>
An IdP MUST NOT verify signatures for associations that
have shared MAC keys. If an IdP did verify signatures
for associations with shared MAC keys, it would be
possible for parties other than the IdP to create valid
assertions that seemed to come from the IdP.
</p>
<p>
The IdP SHOULD only return "is_valid" once for each
authentication request. An authentication request may be
identified by its "openid.response_nonce" value.
</p>
<p>
If the IdP verifies responds with "is_valid" set to
"true", and "invalidate_handle" is present, the Relying
Party SHOULD NOT send further authentication requests
with that handle. "invalidate_handle" will only be
present when the original authentication request to the
IdP included an association that the IdP deemed
invalid. This implies that it will only be present in
this response if it was also present in the <a class='info' href='#positive_assertions'>"id_res"
response<span> (</span><span class='info'>Positive Assertions</span><span>)</span></a>. Including "invalidate_handle" in the
direct verification is necessary to prevent an attacker
from invalidating an association at will by adding it to
an authentication response.
</p>
<a name="anchor37"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.3"></a><h3>11.3.
Verifying Discovered Information</h3>
<p>
The Relying Party MUST have performed <a class='info' href='#discovery'>discovery<span> (</span><span class='info'>Discovery</span><span>)</span></a> on the Identifier that
will be used and the information in the assertion MUST
match the discovered information.
</p>
<p>
Specifically, one of the following MUST be true:
</p>
<ol class="text">
<li>
The Identifier in the assertion points to the IdP
making the assertion.
</li>
<li>
The Claimed Identifier specifies the Identifier in the
assertion as a delegate, and the Delegate Identifier
points to the IdP making the assertion.
</li>
</ol><p>
</p>
<p>
Note: The Relying Party must be able to look up the
Claimed Identifier in order to perform the second test.
Relying Parties unable to store information might append
the Claimed Identifier to the "openid.return_to" parameter
in the request.
</p>
<p>
If the Claimed Identifier was not present in the request
("openid.identity" was
"http://openid.net/identifier_select/2.0"), the Relying
Party MUST perform discovery on the Identifier in the
response to make sure that the IdP is authorized to make
assertions about the Identifier.
</p>
<a name="identifying"></a><br /><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.4"></a><h3>11.4.
Identifying the End User</h3>
<p>
A successful authentication response provides the Relying
Party with a Verified Identifier, which MAY be used as a
user-visible Identifier. Identifiers in OpenID MUST be
URIs. If the Identifier is a URL, its scheme MUST be
"http" or "https". Except in the case that the Verified
Identifier is an XRI, the Relying Party SHOULD use the
Verified Identifier as a key for local storage of
information about the End User. If the Verified Identifier
is an XRI, the discovered "CanonicalID" field from the XRDS
document SHOULD be used as a key for local storage of
information about the End User.
</p>
<p>
If a request is using delegation, the Verified Identifier is
the Identifier on which discovery was performed, and not the
Identifier that is contained in the assertion. If an
assertion is made for an Identifier on which discovery has
not been performed, the Relying Party MUST perform discovery on
that Identifier and compare the discovered information to
that in the assertion.
</p>
<a name="anchor38"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11.4.1"></a><h3>11.4.1.
HTTP and HTTPS URL Identifiers</h3>
<p>
Relying Parties MUST differentiate between URL Identifiers
that have different schemes. When user input is processed
into a URL, it is processed into a HTTP URL. If the same
End User controls the same URL, differing only by scheme,
and it is desired that the Identifier be the HTTPS URL, it
is RECOMMENDED that a redirect be issued from the HTTP URL
to the HTTPS URL. Because the HTTP and HTTPS URLs are not
equivalent and the Identifier that is used is the URL
after following redirects, there is no reduction in
security when using this scheme. If an attacker could gain
control of the HTTP URL, it would have no effect on the
HTTPS URL, since the HTTP URL is not ever used as an
Identifier.
</p>
<a name="compat_mode"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.
OpenID Authentication 1.1 Compatibility</h3>
<p>
OpenID Authentication 2.0 attempts to retain maximum
compatibility with earlier versions of the OpenID
Authentication specification, but this is not universally
possible. This section lists the behavioral changes required
of an OpenID Authentication 2.0 IdP or Relying Party when
communicating with an earlier-protocol peer.
</p>
<p>
OpenID Authentication 2.0 implementations SHOULD support
OpenID Authentication 1.1 compatibility, unlesss security
considerations make it undesirable.
</p>
<p>
All messages in OpenID Authentication 1.1 omit the "openid.ns"
parameter, which is an easy way for an RP to determine if the
message is from an OpenID Authentication 1.x endpoint. OpenID
Authentication 1.1 only supports HMAC-SHA1 associations.
</p>
<a name="anchor39"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12.1"></a><h3>12.1.
Relying Parties</h3>
<p>
</p>
<ul class="text">
<li>
Relying Parties MUST implement <a class='info' href='#html_disco'>HTML-Based Discovery<span> (</span><span class='info'>HTML-Based Discovery</span><span>)</span></a>.
</li>
<li>
In <a class='info' href='#requesting_authentication'>authentication
requests<span> (</span><span class='info'>Requesting Authentication</span><span>)</span></a>, the "openid.identity" parameter MUST NOT
be the special value
"http://openid.net/identifier_select/2.0", because OpenID
Authentication 1.1 does not support IdP-driven identifier
selection.
</li>
<li>
The "openid.realm" parameter in authentication requests
was known as "openid.trust_root". The syntax and meaning
are identical.
</li>
<li>
The Relying Party MUST accept an <a class='info' href='#positive_assertions'>authentication
response<span> (</span><span class='info'>Positive Assertions</span><span>)</span></a> that is missing the
"openid.response_nonce" parameter. It SHOULD however
implement an out-of-band method for preventing replay
attacks.
</li>
</ul><p>
</p>
<a name="anchor40"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.12.2"></a><h3>12.2.
Identity Providers</h3>
<p>
</p>
<ul class="text">
<li>
"openid.identity" MUST be sent in a <a class='info' href='#positive_assertions'>positive authentication
assertion<span> (</span><span class='info'>Positive Assertions</span><span>)</span></a>.
</li>
<li>
<a class='info' href='#refuse_assoc'>Unsuccessful association
responses<span> (</span><span class='info'>Unsuccessful Response Parameters</span><span>)</span></a> MUST NOT be sent, since they are not
part of the OpenID Authentication 1.1 protocol.
</li>
<li>
IdPs MAY choose to return a successful "no-encryption"
response to any association request.
</li>
<li>
Omit the "session_type" parameter when making
"no-encryption" responses to association requests.
</li>
<li>
The "openid.realm" parameter in authentication requests
was known as "openid.trust_root". The syntax and meaning
are identical.
</li>
</ul><p>
</p>
<a name="extensions"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.
Extensions</h3>
<p>
An Extension to OpenID Authentication is a protocol that rides
on top of the authentication request and response. Extensions are
useful for providing extra information about an authentication
request or response as well as providing extra information
about the subject of the authentication response.
</p>
<p>
OpenID extensions are identified by a URI. The URI MAY be used
as the value of an <xrd:Type> element of an OpenID
<xrd:Service> element in an XRDS document associated
with a Claimed Identifier. It is also used to associate
key-value pairs in messages with the extension.
</p>
<p>
To associate keys and values in a message with an extension,
the key MUST be associated with the Type URI. To associate
keys with a Type URI, establish an alias by adding a key
prefixed with "openid.ns." and ending with the alias text
whose value is the Type URI. Once an alias has been
established, all pairs in the message whose keys start with
"openid." followed by the alias text, followed by a period or
the end of the key are associated with that extension.
</p>
<p>
A namespace alias MUST NOT contain a period, MUST NOT be the
name of a field in a message defined in this specification,
and MUST NOT be the same as another namespace alias in the
same message. A namespace MUST NOT be assigned more than one
alias in the same message. If a message is a response to
another message, the response MAY use a different alias to
refer to the same namespace.
</p>
<p>Non-normative example:
</p>
<p>An extension's type URI is
"<http://example.com/ext/1.0>".
</p>
<blockquote class="text">
<p>openid.ns.x=http://example.com/ext/1.0
</p>
<p>openid.x=example
</p>
<p>openid.x.foo=bar
</p>
<p>openid.xx=notx
</p>
</blockquote><p>
In this example, the keys openid.x and openid.x.foo are
associated with the extension; the openid.xx key is not.
</p>
<a name="anchor41"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.14"></a><h3>14.
Discovering OpenID Relying Parties</h3>
<p>
Relying Parties are RECOMMENDED to use the Yadis protocol to
publish their return_to URL. This allows for automated
discovery of OpenID Relying Parties.
</p>
<p>
The Relying Party's XRDS document's <xrd:Service> entry
should have the return_to URL as the content of the
<xrd:URI> tag and should have
http://openid.net/return_to/2.0 as the content of the
<xrd:Type> tag.
</p>
<p>For example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://openid.net/return_to/2.0</Type>
<URI>http://consumer.example.com/return</URI>
</Service>
</pre></div>
<a name="anchor42"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15"></a><h3>15.
Security Considerations</h3>
<a name="anchor43"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15.1"></a><h3>15.1.
Preventing Attacks</h3>
<a name="preventing_eavesdropping"></a><br /><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.15.1.1"></a><h3>15.1.1.
Eavesdropping Attacks</h3>
<p>
There are two places in this protocol that are
vulnerable to eavesdropping attacks. An eavesdropper could
intercept an unencrypted association session and recover
the shared secret, allowing an attacker to masquerade as
the IdP to that relying party. An eavesdropper could also
intercept a successful authentication assertion and re-use
it, if the nonce is not checked.
</p>
<p>
Both of these attacks can be prevented by using SSL for
these connections. The association session can also use
Diffie-Hellman Key Exchange instead of "no-encryption" to
protect from eavesdropping. If the nonce is checked in
message verification, the positive authentication
assertion cannot be re-used.
</p>
<a name="anchor44"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15.1.2"></a><h3>15.1.2.
Man-in-the-Middle Attcks</h3>
<p>
Associations prevent tampering of signed fields by a man
in the middle, except during discovery, association
sessions and stateless mode. Altering signed fields
without the shared secret requires breaking the
MAC. Currently, no tractable attack is known on the MACs
used in this protocol. The quality of the protection
provided by the MAC depends on the randomness of the
shared MAC key, so it is important that an unguessable
value be used.
</p>
<p>
If DNS resolution or the transport layer is compromised,
signatures on messages are not adequate, since the
attacker can impersonate the IdP and issue its own
associations, or its own decisions in stateless mode. If
an attacker can tamper with the discovery process, he can
specify any IdP, and so does not have to impersonate the
IdP.
</p>
<p>
Using SSL with certificates signed by a trusted authority
prevents these kinds of attacks by verifying the results
of the DNS look-up against the certificate. Once the
validity of the certificate has been established,
tampering is not possible. Impersonating an SSL server
requires forging or stealing a certificate, which is
significantly harder than the network attacks.
</p>
<p>
In order to get protection from SSL, SSL must be used for
all parts of the interaction, including interaction with
the End User through the User Agent.
</p>
<a name="anchor45"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15.2"></a><h3>15.2.
User Agents</h3>
<p>
Since this protocol is intended to be used interactively,
User Agents will primarily be common Web browsers. Web
browsers or their hosts may be infected with spyware or
other malware, which limits the strength of the
authentication assertion, since untrusted software makes it
impossible to know whether the authentication decision has
been made with the End User's approval. With this said, many
web applications and protocols today rely on the security of
the Web browser and their hosts.
</p>
<p>
Cross-site-scripting attacks against IdPs may be used to the
same effect. For the best security, IdPs should not depend
on scripting so that User Agents without scripting enabled
can make authentication decisions.
</p>
<a name="anchor46"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.15.3"></a><h3>15.3.
User Interface Considerations</h3>
<p>
The Relying Party SHOULD redirect the End User to the IdP
Endpoint URL in a top-level browser window with all controls
visible. This allows better protection for the End User
against IdP look-alike sites (phishing).
</p>
<a name="anchor47"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Examples</h3>
<p>Non-normative
</p>
<a name="anchor48"></a><br /><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.1"></a><h3>Appendix A.1.
Delegation</h3>
<p>
For example, an End User wants to use
http://www.example.com/ as their Identifier, but
http://www.example.com/ doesn't have the means, or desire,
to run an IdP. LiveJournal is an Identity
Provider, so if the End User has a LiveJournal OpenID
Identifier, they can delegate their authentication to
LiveJournal.
</p>
<a name="anchor49"></a><br /><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.2"></a><h3>Appendix A.2.
XRDS</h3>
<p>
<p>
To use www.example.com as their Identifier, but have
Relying Parties actually verify
http://exampleuser.livejournal.com/ with the Identity
Provider located at
http://www.livejournal.com/openid/server.bml, the
following XML snippet should be present in the final XRD
in the XRDS file:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://openid.net/signon/2.0</Type>
<URI>http://www.livejournal.com/openid/server.bml</URI>
<Delegate xmlns="http://openid.net/signon/2.0">
http://exampleuser.livejournal.com/
</Delegate>
</Service>
</pre></div>
<a name="anchor50"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A.3"></a><h3>Appendix A.3.
HTML Identifier Markup</h3>
<p>
To use www.example.com as their Identifier, but have
Relying Parties actually verify
http://exampleuser.livejournal.com/ with the Identity
Provider located at
http://www.livejournal.com/openid/server.bml, the
following markup should be present in the <head>
of the HTML document located by the identifier URL:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
<link rel="openid.server"
href="http://www.livejournal.com/openid/server.bml"/>
<link rel="openid.delegate"
href="http://exampleuser.livejournal.com/"/>
</pre></div>
<a name="anchor51"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A.4"></a><h3>Appendix A.4.
Login Form</h3>
<p>
Continuing this example, the End User visits a Relying Party site
which supports OpenID Authentication. The Relying Party presents
the End User with a form field for them to enter their
Identifier or their IdP's identifier.
</p>
<p>
<p>For example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
----------------------------------
|[logo]example.com | [Login Button]
----------------------------------
</pre></div>
<a name="anchor52"></a><br /><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.5"></a><h3>Appendix A.5.
XRI CanonicalID</h3>
<p>
For example, if =example and =exmpl both yield an XRD
document with the CanonicalID xri://(example)!1234 then
those identifiers should be treated as equivalent. For
applications with user accounts, those identifiers should
both be attached to the same account.
</p>
<a name="pvalue"></a><br /><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.
Diffie-Hellman Key Exchange Default Value</h3>
<p>
This is a confirmed-prime number, used as the default
modulus for Diffie-Hellman Key Exchange. In hexadecimal:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E
F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557
7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382
6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB
</pre></div>
<a name="anchor53"></a><br /><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.
Changes from the Previous OpenID Authentication Specification</h3>
<p>
This specification is based on the original specification for
OpenID Authentication as written by Brad Fitzpatrick. That
specification did not have a version number, but was called
OpenID 1.0, and then OpenID 1.1 when it was revised. The
protocol outlined in this specification is intended to be
backwards-compatible with the revised OpenID protocol. The
most significant changes to the specification are outlined in
this section.
</p>
<a name="anchor54"></a><br /><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.1"></a><h3>Appendix C.1.
Updated Initiation and Discovery</h3>
<p>
</p>
<ul class="text">
<li>
Supports IdP-driven identifier selection. This new
variation of the protocol flow is initiated by entering
an Identifier for an IdP instead of an Identifier for an
End User, and allows the IdP to assist the End User in
selecting an Identifier.
</li>
<li>
Supports the use of XRIs as Identifiers. XRIs may be
used as Identifiers for both End Users and IdPs.
</li>
<li>
When URLs are used as Identifiers, they are normalized
according to RFC 3986, for better compatibility with
existing Web infrastructure.
</li>
<li>
Uses the Yadis protocol for discovery. This allows for
using multiple IdPs for a single Identifier, for
load-balancing and fallback in the case of IdP
failure. Additionally, it allows for discovery of
supported extensions.
</li>
</ul><p>
</p>
<a name="anchor55"></a><br /><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.2"></a><h3>Appendix C.2.
Security improvements</h3>
<p>
A nonce is now part of the protocol for built-in protection
against replay attacks.
</p>
<p>
A new association type, HMAC-SHA256, and a new association
session type, DH-SHA256, allow for stronger signatures on
authentication assertions.
</p>
<a name="anchor56"></a><br /><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.3"></a><h3>Appendix C.3.
Extensions</h3>
<p>
Extensions are a new mechanism to support data exchange and
other Relying Party-IdP communication along with the
authentication exchange. Extensions allow for the exchange
of arbitrary attributes, as well as for protocol extensions,
such as the inclusion of additional information about the
Relying Party in the authentication request.
</p>
<p>
Because extensions can transfer arbitrary data, the
Identifier is now optional in the response.
</p>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>16. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FIPS180-2">[FIPS180-2]</a></td>
<td class="author-text">U.S. Department of Commerce and National Institute of Standards
and Technology, “<a href="http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf">Secure Hash Signature Standard</a>,” FIPS 180-2.<p>
Defines Secure Hash Algorithm 256 (SHA256)
</p>
</td></tr>
<tr><td class="author-text" valign="top"><a name="HTML401">[HTML401]</a></td>
<td class="author-text">W3C, “<a href="http://www.w3.org/TR/html401">HTML 4.01 Specification</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1750">[RFC1750]</a></td>
<td class="author-text">Eastlake, D., Crocker, S., and J. Schiller, “<a href="ftp://ftp.isi.edu/in-notes/rfc3986.txt">Randomness Recommendations for Security</a>,” RFC 3986.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2104">[RFC2104]</a></td>
<td class="author-text">Krawczyk, H., Bellare, M., and R. Canetti, “<a href="ftp://ftp.isi.edu/in-notes/rfc2104.txt">HMAC: Keyed-Hashing for Message Authentication</a>,” RFC 2104.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, B., “<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC 2119.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="ftp://ftp.isi.edu/in-notes/rfc2616.txt">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC 2616.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2631">[RFC2631]</a></td>
<td class="author-text">Rescorla, E., “<a href="ftp://ftp.isi.edu/in-notes/rfc2631.txt">Diffie-Hellman Key Agreement Method</a>,” RFC 2631.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3174">[RFC3174]</a></td>
<td class="author-text">Eastlake, D. and P. Jones, “<a href="ftp://ftp.isi.edu/in-notes/rfc3174.txt">US Secure Hash Algorithm 1 (SHA1)</a>,” RFC 3174.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text">Newman, C. and G. Klyne, “<a href="ftp://ftp.isi.edu/in-notes/rfc3174.txt">Date and Time on the Internet: Timestamps</a>,” RFC 3174.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3548">[RFC3548]</a></td>
<td class="author-text">Josefsson, S., “<a href="ftp://ftp.isi.edu/in-notes/rfc3548.txt">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 3548.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text">Berners-Lee, T., “<a href="ftp://ftp.isi.edu/in-notes/rfc3986.txt">Uniform Resource Identifiers (URI): Generic Syntax</a>,” RFC 3986.</td></tr>
<tr><td class="author-text" valign="top"><a name="XRI Syntax 2.0">[XRI Syntax 2.0]</a></td>
<td class="author-text">Reed, D. and D. McAlpin, “<a href="http://www.oasis-open.org/committees/download.php/15376#_Toc117301848">Extensible Resource Identifier (XRI) Syntax V2.0</a>” (<a href="http://www.oasis-open.org/committees/download.php/15376">HTML</a>, <a href="http://www.oasis-open.org/committees/download.php/15377">PDF</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="Yadis">[Yadis]</a></td>
<td class="author-text">Miller, J., “<a href="http://yadis.org/papers/yadis-v1.0.pdf">Yadis Specification 1.0</a>.”</td></tr>
</table>
<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">David Recordon</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">VeriSign, Inc.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">487 E Middlefield Road</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Mountain View, CA 94109</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:drecordon@verisign.com">drecordon@verisign.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Josh Hoyt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">JanRain, Inc.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">5331 SW Macadam Avenue</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Suite #375</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Portland, OR 97239</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:josh@janrain.com">josh@janrain.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Dick Hardt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Sxip Identity Corporation</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">798 Beatty Street</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Vancouver, BC V6B 2M1</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Canada</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:dick@sxip.com">dick@sxip.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Brad Fitzpatrick</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Six Apart, Ltd.</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">548 4th Street</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">San Francisco, CA 94107</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:brad@danga.com">brad@danga.com</a></td></tr>
</table>
</body></html>