<!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, 07 Nov 2006 20:27:45 +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.32pre2 (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">December 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(S) 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="#anchor38">12.1</a>
Relying Parties<br />
<a href="#anchor39">12.2</a>
Identity Providers<br />
<a href="#extensions">13</a>
Extensions<br />
<a href="#anchor40">14</a>
Discovering OpenID Relying Parties<br />
<a href="#anchor41">15</a>
Security Considerations<br />
<a href="#anchor42">15.1</a>
Preventing Attacks<br />
<a href="#anchor44">15.2</a>
User Agents<br />
<a href="#anchor45">15.3</a>
User Interface Considerations<br />
<a href="#anchor46">Appendix A</a>
Examples<br />
<a href="#anchor47">Appendix A.1</a>
IdP-Specific Identifiers<br />
<a href="#anchor48">Appendix A.2</a>
XRDS<br />
<a href="#anchor49">Appendix A.3</a>
HTML Identifier Markup<br />
<a href="#anchor50">Appendix A.4</a>
Login Form<br />
<a href="#anchor51">Appendix A.5</a>
XRI CanonicalID<br />
<a href="#pvalue">Appendix B</a>
Diffie-Hellman Key Exchange Default Value<br />
<a href="#anchor52">Appendix C</a>
Changes from the Previous OpenID Authentication Specification<br />
<a href="#anchor53">Appendix C.1</a>
Updated Initiation and Discovery<br />
<a href="#anchor54">Appendix C.2</a>
Security improvements<br />
<a href="#anchor55">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="rfc.section.1"></a><h4><a name="anchor1">1</a>
Requirements Notation</h4>
<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="rfc.section.2"></a><h4><a name="anchor2">2</a>
Terminology</h4>
<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,
IdP-Specific 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>IdP-Specific 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="rfc.section.3"></a><h4><a name="anchor3">3</a>
Protocol Overview</h4>
<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="rfc.section.4"></a><h4><a name="formats">4</a>
Data Formats</h4>
<a name="rfc.section.4.1"></a><h4><a name="anchor4">4.1</a>
Protocol Messages</h4>
<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.
Messages MUST NOT contain multiple parameters with the same name.
</p>
<a name="rfc.section.4.1.1"></a><h4><a name="kvform">4.1.1</a>
Key-Value Form Encoding</h4>
<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="rfc.section.4.1.2"></a><h4><a name="queries">4.1.2</a>
HTTP Encoding</h4>
<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="rfc.section.4.1.3"></a><h4><a name="anchor5">4.1.3</a>
Example</h4>
<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="rfc.section.4.2"></a><h4><a name="btwoc">4.2</a>
Integer Representations</h4>
<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="rfc.section.5"></a><h4><a name="communication">5</a>
Communication Types</h4>
<a name="rfc.section.5.1"></a><h4><a name="direct_comm">5.1</a>
Direct Communication</h4>
<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="rfc.section.5.1.1"></a><h4><a name="direct_request">5.1.1</a>
Direct Request</h4>
<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="rfc.section.5.1.2"></a><h4><a name="direct_response">5.1.2</a>
Direct Response</h4>
<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="rfc.section.5.1.2.1"></a><h4><a name="anchor6">5.1.2.1</a>
Successful Responses</h4>
<p>
A server receiving a valid request MUST send a
response with an HTTP status code of 200.
</p>
<a name="rfc.section.5.1.2.2"></a><h4><a name="anchor7">5.1.2.2</a>
Error Responses</h4>
<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="rfc.section.5.2"></a><h4><a name="indirect_comm">5.2</a>
Indirect Communication</h4>
<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="rfc.section.5.2.1"></a><h4><a name="anchor8">5.2.1</a>
HTTP Redirect</h4>
<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
aid in backward compatibility.
</p>
<a name="rfc.section.5.2.2"></a><h4><a name="anchor9">5.2.2</a>
HTML FORM Redirection</h4>
<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="rfc.section.5.2.3"></a><h4><a name="anchor10">5.2.3</a>
Indirect Error Responses</h4>
<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 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. If the parameter is ommitted in the
request, it signifies that the initiating server does not
wish to for the End User to be returned to it as something
else useful will have been performed via an extension.
</p>
<a name="rfc.section.6"></a><h4><a name="generating_signatures">6</a>
Generating Signatures</h4>
<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="rfc.section.6.1"></a><h4><a name="anchor11">6.1</a>
Procedure</h4>
<p>
To generate a message signature:
</p>
<ol class="text">
<li>
Determine the appropriate list of keys to be signed
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 of key/value pairs 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 of key/value pairs to be signed 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="rfc.section.6.2"></a><h4><a name="signed_list">6.2</a>
Signed List Algorithm</h4>
<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 list of key/value pairs to be signed.
</li>
</ol><p>
</p>
<p>
The output of this algorithm is the list of key/value pairs
to be signed, and the list of keys to be 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="rfc.section.6.3"></a><h4><a name="sign_algos">6.3</a>
Signature Algorithms</h4>
<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="rfc.section.7"></a><h4><a name="anchor12">7</a>
Initiation and Discovery</h4>
<a name="rfc.section.7.1"></a><h4><a name="initiation">7.1</a>
Initiation</h4>
<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. Rich User Agents that support OpenID Authentication
may not detect a Relying Party's support if the value is not
"openid_identifier".
</p>
<a name="rfc.section.7.2"></a><h4><a name="normalization">7.2</a>
Normalization</h4>
<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://". See <a class='info' href='#http_s_identifiers'>Section 11.4.1<span> (</span><span class='info'>HTTP and HTTPS URL Identifiers</span><span>)</span></a> for more information.
</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="rfc.section.7.3"></a><h4><a name="discovery">7.3</a>
Discovery</h4>
<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="rfc.section.7.3.1"></a><h4><a name="anchor13">7.3.1</a>
Discovered Information</h4>
<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 identifier that is the subject of this
authentication request. This is the identifier upon
which discovery was performed.
</dd>
<dt>IdP-Specific Identifier:</dt>
<dd>
(optional) An identifier that allows an IdP to
identify the user of a Claimed Identifier. If no
IdP-specific identifier is present in the discovered
information, the Claimed Identifier is also the
IdP-Specific Identifier.
</dd>
<dt>Protocol Version:</dt>
<dd>
The OpenID protocol version of the discovered
Identity Provider(s). This is determined by the
<xrd:Type> tag of the IdP Identifier Element.
</dd>
</dl></blockquote><p>
</p>
<a name="rfc.section.7.3.2"></a><h4><a name="anchor14">7.3.2</a>
XRDS-Based Discovery</h4>
<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="rfc.section.7.3.2.1"></a><h4><a name="anchor15">7.3.2.1</a>
Service Elements</h4>
<a name="rfc.section.7.3.2.1.1"></a><h4><a name="anchor16">7.3.2.1.1</a>
IdP Identifier Element</h4>
<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="rfc.section.7.3.2.1.2"></a><h4><a name="anchor17">7.3.2.1.2</a>
Claimed Identifier Element</h4>
<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 IdP-Specific Identifier.
</dd>
</dl></blockquote><p>
</p>
<a name="rfc.section.7.3.2.2"></a><h4><a name="anchor18">7.3.2.2</a>
Extracting Authentication Data</h4>
<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="rfc.section.7.3.2.3"></a><h4><a name="anchor19">7.3.2.3</a>
XRI and the CanonicalID Element</h4>
<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="rfc.section.7.3.2.4"></a><h4><a name="anchor20">7.3.2.4</a>
Additional Information</h4>
<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="rfc.section.7.3.3"></a><h4><a name="html_disco">7.3.3</a>
HTML-Based Discovery</h4>
<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 IdP-Specific 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="rfc.section.8"></a><h4><a name="associations">8</a>
Establishing Associations</h4>
<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="rfc.section.8.1"></a><h4><a name="anchor21">8.1</a>
Association Session Request</h4>
<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="rfc.section.8.1.1"></a><h4><a name="anchor22">8.1.1</a>
Common Request Parameters</h4>
<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>
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="rfc.section.8.1.2"></a><h4><a name="anchor23">8.1.2</a>
Diffie-Hellman Request Parameters</h4>
<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="rfc.section.8.2"></a><h4><a name="anchor24">8.2</a>
Association Session Response</h4>
<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="rfc.section.8.2.1"></a><h4><a name="anchor25">8.2.1</a>
Common Response Parameters</h4>
<p>
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
Value: "http://openid.net/signon/2.0"
</p>
</blockquote>
</li>
<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="rfc.section.8.2.2"></a><h4><a name="anchor26">8.2.2</a>
Unencrypted Response Parameters</h4>
<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="rfc.section.8.2.3"></a><h4><a name="anchor27">8.2.3</a>
Diffie-Hellman Response Parameters</h4>
<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="rfc.section.8.2.4"></a><h4><a name="refuse_assoc">8.2.4</a>
Unsuccessful Response Parameters</h4>
<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>
ns
<blockquote class="text">
<p>
Value: "http://openid.net/signon/2.0"
</p>
</blockquote>
</li>
<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: 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="rfc.section.8.3"></a><h4><a name="assoc_types">8.3</a>
Association Types</h4>
<a name="rfc.section.8.3.1"></a><h4><a name="hmacsha1">8.3.1</a>
HMAC-SHA1</h4>
<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="rfc.section.8.3.2"></a><h4><a name="hmacsha256">8.3.2</a>
HMAC-SHA256</h4>
<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="rfc.section.8.4"></a><h4><a name="assoc_sess_types">8.4</a>
Association Session Types</h4>
<p>
OpenID Authentication defines three valid association
session types: "no-encryption", "DH-SHA1", and "DH-SHA256".
</p>
<a name="rfc.section.8.4.1"></a><h4><a name="anchor28">8.4.1</a>
No-Encryption Association Sessions</h4>
<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="rfc.section.8.4.2"></a><h4><a name="dh_sessions">8.4.2</a>
Diffie-Hellman Association Sessions</h4>
<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="rfc.section.9"></a><h4><a name="requesting_authentication">9</a>
Requesting Authentication</h4>
<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="rfc.section.9.1"></a><h4><a name="anchor29">9.1</a>
Request Parameters</h4>
<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.disco_id
<blockquote class="text">
<p>
Value: (optional) The Claimed Identifier. (The identifier on
which discovery was performed)
</p>
<p>
Note: The Claimed Identifier is the same as the
IdP-specific identifier unless it is using
delegation. If the request is not about an
identifier (for instance, an attribute exchange
request), this parameter will be absent.
</p>
</blockquote>
</li>
<li>
openid.identity
<blockquote class="text">
<p>
Value: (optional) The IdP-Specific 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: (optional) URL to which the IdP SHOULD return
the User Agent with the response indicating the
status of the request.
</p>
<p>
Note: If this value is not sent in the request it
signifies that the Relying Party does not wish to
for the End User to be returned to it as something
else useful will have been performed via an
extension.
</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>.
This value MUST be sent if openid.return_to is
ommitted.
</p>
<p>
Default: return_to URL
</p>
</blockquote>
</li>
</ul><p>
</p>
<a name="rfc.section.9.2"></a><h4><a name="realms">9.2</a>
Realms</h4>
<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. The realm SHOULD be used by IdPs to uniquely
identify Relying Parties.
</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>
When present, 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="rfc.section.9.3"></a><h4><a name="anchor30">9.3</a>
Immediate Requests</h4>
<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="rfc.section.10"></a><h4><a name="responding_to_authentication">10</a>
Responding to Authentication Requests</h4>
<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>
<p>
If the "openid.return_to" value is ommitted in the request, it
signifies that the initiating server does not wish to for the
End User to be returned to it as something else useful will
have been performed via an extension.
</p>
<a name="rfc.section.10.1"></a><h4><a name="positive_assertions">10.1</a>
Positive Assertions</h4>
<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.disco_id
<blockquote class="text">
<p>
Value: The Claimed Identifier (The identifier on
which discovery was run)
</p>
<p>
Note: The Claimed Identifier is the same as the
IdP-specific identifier if there is no delegate
specified. If neither value is present, the
assertion is not about an identifier, and will
contain other information in its payload, using
<a class='info' href='#extensions'>extensions<span> (</span><span class='info'>Extensions</span><span>)</span></a>.
</p>
</blockquote>
</li>
<li>
openid.identity
<blockquote class="text">
<p>
Value: (optional) The IdP-Specific Identifier
</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: Comma-separated list of signed fields.
</p>
<p>
Note: 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", and if present in the response,
"disco_id" and "identity". For example,
"identity,disco_id,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="rfc.section.10.2"></a><h4><a name="negative_assertions">10.2</a>
Negative Assertions</h4>
<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>
<p>
When receiving a negative assertion, Relying Parties SHOULD
construct a new authentication request using the
"checkid_setup" mode to complete the transaction. This is a
change from OpenID Authentication 1.1 and more details can
be found in <a class='info' href='#compat_mode'>Section 12<span> (</span><span class='info'>OpenID Authentication 1.1 Compatibility</span><span>)</span></a>.
</p>
<a name="rfc.section.10.2.1"></a><h4><a name="anchor31">10.2.1</a>
In Response to Immediate Requests</h4>
<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="rfc.section.10.2.2"></a><h4><a name="anchor32">10.2.2</a>
In Response to Non-Immediate Requests</h4>
<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="rfc.section.11"></a><h4><a name="verification">11</a>
Verifying Assertions</h4>
<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>
If all three of these conditions are met, the Claimed
Identifier in the response is now a Verified Identifier.
</p>
<a name="rfc.section.11.1"></a><h4><a name="anchor33">11.1</a>
Checking the Nonce</h4>
<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="rfc.section.11.2"></a><h4><a name="verifying_signatures">11.2</a>
Verifying Signatures</h4>
<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="rfc.section.11.2.1"></a><h4><a name="anchor34">11.2.1</a>
Verifying with an Association</h4>
<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="rfc.section.11.2.2"></a><h4><a name="check_auth">11.2.2</a>
Verifying Directly with the Identity Provider</h4>
<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="rfc.section.11.2.2.1"></a><h4><a name="anchor35">11.2.2.1</a>
Request Parameters</h4>
<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="rfc.section.11.2.2.2"></a><h4><a name="anchor36">11.2.2.2</a>
Response Parameters</h4>
<p>
</p>
<ul class="text">
<li>
ns
<blockquote class="text">
<p>
Value: "http://openid.net/signon/2.0"
</p>
</blockquote>
</li>
<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="rfc.section.11.3"></a><h4><a name="anchor37">11.3</a>
Verifying Discovered Information</h4>
<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 Claimed
Identifier and the information in the assertion MUST exactly
match the discovered information.
</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="rfc.section.11.4"></a><h4><a name="identifying">11.4</a>
Identifying the End User</h4>
<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 an assertion is made for a Claimed 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="rfc.section.11.4.1"></a><h4><a name="http_s_identifiers">11.4.1</a>
HTTP and HTTPS URL Identifiers</h4>
<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="rfc.section.12"></a><h4><a name="compat_mode">12</a>
OpenID Authentication 1.1 Compatibility</h4>
<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="rfc.section.12.1"></a><h4><a name="anchor38">12.1</a>
Relying Parties</h4>
<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>
Relying Parties MUST send a blank session_type parameter
in "no-encryption" association requests.
</li>
<li>
Relying Parties MUST accept a "no-encryption" association
response with a blank or missing session_type parameter,
if they choose to accept "no-encryption" sessions.
</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>
When responding with a negative assertion to a
"checkid_immediate" mode authentication request, the
"user_setup_url" paramater MUST be returned. This is 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.
</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="rfc.section.12.2"></a><h4><a name="anchor39">12.2</a>
Identity Providers</h4>
<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>
IdPs MUST accept a "no-encryption" association request
with a blank session_type parameter, if they choose to
accept "no-encryption" sessions.
</li>
<li>
IdPs MUST accept association requests with no assoc_type
parameter, and assume them to be of type HMAC-SHA1.
</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 or set to blank 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>
<li>
When responding with a negative assertion to a
"checkid_immediate" mode authentication request, the
"user_setup_url" paramater MUST be returned. This is 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.
</li>
</ul><p>
</p>
<a name="rfc.section.13"></a><h4><a name="extensions">13</a>
Extensions</h4>
<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>
<p>
Extensions MUST NOT define parameters with the same name. It
is RECOMMENDED that commas are used as value delimiters,
though recognized that other characters are better suited in
certain situations. Another approach can be appending a
numeric value to each key to differentiate between each value.
</p>
<a name="rfc.section.14"></a><h4><a name="anchor40">14</a>
Discovering OpenID Relying Parties</h4>
<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="rfc.section.15"></a><h4><a name="anchor41">15</a>
Security Considerations</h4>
<a name="rfc.section.15.1"></a><h4><a name="anchor42">15.1</a>
Preventing Attacks</h4>
<a name="rfc.section.15.1.1"></a><h4><a name="preventing_eavesdropping">15.1.1</a>
Eavesdropping Attacks</h4>
<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="rfc.section.15.1.2"></a><h4><a name="anchor43">15.1.2</a>
Man-in-the-Middle Attcks</h4>
<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. While the protocol
does not require SSL be used, its use is strongly
RECOMMENDED. Current best practicies dictate that an IdP
SHOULD use SSL, with a certificate signed by a trusted
authority, to secure its service endpoint. In addition,
SSL, with a certificate signed by a trusted authority,
SHOULD be used so that a Relying Party can fetch the
End User's URL in a secure manner. Please keep in mind
that a Relying Party MAY decide to not complete, or even
begin, a transaction if SSL is not being correctly used
at these various endpoints.
</p>
<a name="rfc.section.15.2"></a><h4><a name="anchor44">15.2</a>
User Agents</h4>
<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="rfc.section.15.3"></a><h4><a name="anchor45">15.3</a>
User Interface Considerations</h4>
<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="rfc.section.A"></a><h4><a name="anchor46">Appendix A</a>
Examples</h4>
<p>Non-normative
</p>
<a name="rfc.section.A.1"></a><h4><a name="anchor47">Appendix A.1</a>
IdP-Specific Identifiers</h4>
<p>
An End User wants to use http://www.example.com/ as their
Claimed Identifier. The End User has an account with
LiveJournal, an Identity Provider, they can use the
LiveJournal IdP Endpoint URL to do authentication for
http://www.example.com/, using their LiveJournal-issued
identifier as an IdP-Specific Identifier.
</p>
<a name="rfc.section.A.2"></a><h4><a name="anchor48">Appendix A.2</a>
XRDS</h4>
<p>
<p>
To use www.example.com as their Identifier, but have
Relying Parties actually verify
http://exampleuser.livejournal.com/ with the IdP
Endpoint URL
http://www.livejournal.com/openid/server.bml, the
following XML snippet should be present in the final XRD
element 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="rfc.section.A.3"></a><h4><a name="anchor49">Appendix A.3</a>
HTML Identifier Markup</h4>
<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="rfc.section.A.4"></a><h4><a name="anchor50">Appendix A.4</a>
Login Form</h4>
<p>
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="rfc.section.A.5"></a><h4><a name="anchor51">Appendix A.5</a>
XRI CanonicalID</h4>
<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="rfc.section.B"></a><h4><a name="pvalue">Appendix B</a>
Diffie-Hellman Key Exchange Default Value</h4>
<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="rfc.section.C"></a><h4><a name="anchor52">Appendix C</a>
Changes from the Previous OpenID Authentication Specification</h4>
<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="rfc.section.C.1"></a><h4><a name="anchor53">Appendix C.1</a>
Updated Initiation and Discovery</h4>
<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="rfc.section.C.2"></a><h4><a name="anchor54">Appendix C.2</a>
Security improvements</h4>
<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="rfc.section.C.3"></a><h4><a name="anchor55">Appendix C.3</a>
Extensions</h4>
<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>