diff options
Diffstat (limited to 'doc/specs/openid-authentication-1_1.html')
| -rw-r--r-- | doc/specs/openid-authentication-1_1.html | 1593 |
1 files changed, 1593 insertions, 0 deletions
diff --git a/doc/specs/openid-authentication-1_1.html b/doc/specs/openid-authentication-1_1.html new file mode 100644 index 0000000..9a2708b --- /dev/null +++ b/doc/specs/openid-authentication-1_1.html @@ -0,0 +1,1593 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html lang="en"><head><title>OpenID Authentication 1.1</title> + + +<meta http-equiv="Expires" content="Tue, 13 Jun 2006 19:04:16 +0000"> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<meta name="description" content="OpenID Authentication 1.1"> +<meta name="generator" content="xml2rfc v1.30 (http://xml.resource.org/)"> +<style type="text/css"> +<!-- + body { + font-family: verdana, charcoal, helvetica, arial, sans-serif; + margin: 2em; + font-size: small ; color: #000000 ; background-color: #ffffff ; } + .title { color: #990000; font-size: x-large ; + font-weight: bold; text-align: right; + font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; + background-color: transparent; } + .filename { color: #666666; font-size: 18px; line-height: 28px; + font-weight: bold; text-align: right; + font-family: helvetica, arial, sans-serif; + background-color: transparent; } + td.rfcbug { background-color: #000000 ; width: 30px ; height: 30px ; + text-align: justify; vertical-align: middle ; padding-top: 2px ; } + td.rfcbug span.RFC { color: #666666; font-weight: bold; text-decoration: none; + background-color: #000000 ; + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-size: x-small ; } + td.rfcbug span.hotText { color: #ffffff; font-weight: normal; text-decoration: none; + text-align: center ; + font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-size: x-small ; background-color: #000000; } + /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ + div#counter{margin-top: 100px} + + a.info{ + position:relative; /*this is the key*/ + z-index:24; + text-decoration:none} + + a.info:hover{z-index:25; background-color:#990000 ; color: #ffffff ;} + + 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:2em; width:15em; + padding: 2px ; + border:1px solid #333333; + background-color:#eeeeee; color:#990000; + text-align: left ;} + + A { font-weight: bold; } + A:link { color: #990000; background-color: transparent ; } + A:visited { color: #333333; background-color: transparent ; } + A:active { color: #333333; 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; } + + span.emph { font-style: italic; } + span.strong { font-weight: bold; } + span.verb, span.vbare { font-family: "Courier New", Courier, monospace ; } + + span.vemph { font-style: italic; font-family: "Courier New", Courier, monospace ; } + span.vstrong { font-weight: bold; font-family: "Courier New", Courier, monospace ; } + span.vdeluxe { font-weight: bold; font-style: italic; font-family: "Courier New", Courier, monospace ; } + + ol.text { margin-left: 2em; margin-right: 2em; } + ul.text { margin-left: 2em; margin-right: 2em; } + li { margin-left: 3em; } + + pre { margin-left: 3em; color: #333333; background-color: transparent; + font-family: "Courier New", Courier, monospace ; font-size: small ; + text-align: left; + } + + h3 { color: #333333; font-size: medium ; + font-family: helvetica, arial, sans-serif ; + background-color: transparent; } + h4 { font-size: small; font-family: helvetica, arial, sans-serif ; } + + table.bug { width: 30px ; height: 15px ; } + td.bug { color: #ffffff ; background-color: #990000 ; + text-align: center ; width: 30px ; height: 15px ; + } + td.bug A.link2 { color: #ffffff ; font-weight: bold; + text-decoration: none; + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; + font-size: x-small ; background-color: transparent } + + td.header { color: #ffffff; font-size: x-small ; + font-family: arial, helvetica, sans-serif; vertical-align: top; + background-color: #666666 ; width: 33% ; } + td.author { font-weight: bold; margin-left: 4em; font-size: x-small ; } + td.author-text { font-size: x-small; } + table.full { vertical-align: top ; border-collapse: collapse ; + border-style: solid solid solid solid ; + border-color: black black black black ; + font-size: small ; text-align: center ; } + table.headers, table.none { vertical-align: top ; border-collapse: collapse ; + border-style: none; + font-size: small ; text-align: center ; } + table.full th { font-weight: bold ; + border-style: solid ; + border-color: black black black black ; } + table.headers th { font-weight: bold ; + border-style: none none solid none; + border-color: black black black black ; } + table.none th { font-weight: bold ; + border-style: none; } + table.full td { + border-style: solid solid solid solid ; + border-color: #333333 #333333 #333333 #333333 ; } + table.headers td, table.none td { border-style: none; } + + hr { height: 1px } +--> +</style></head><body> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<table summary="layout" border="0" cellpadding="0" cellspacing="0" width="66%"><tbody><tr><td><table summary="layout" border="0" cellpadding="2" cellspacing="1" width="100%"> +<tbody><tr><td class="header"> </td><td class="header">D. Recordon</td></tr> +<tr><td class="header"> </td><td class="header">B. Fitzpatrick</td></tr> +<tr><td class="header"> </td><td class="header">May 2006</td></tr> +</tbody></table></td></tr></tbody></table> +<div align="right"><span class="title"><br>OpenID Authentication 1.1</span></div> + +<h3>Abstract</h3> + +<p>OpenID Authenticaion provides a way to prove that an End User + owns an Identity URL. It does this without passing around their + password, email address, or anything they don't want it + to. +</p> +<p>OpenID is completely decentralized meaning that anyone + can choose to be a Consumer or Identity Provider without having + to register or be approved by any central authority. End User's + can pick which Identity Provider they wish to use and preserve + their Identity as they move between Providers. +</p> +<p>While nothing in the protocol requires JavaScript or modern + browsers, the authentication scheme plays nicely with + "AJAX"-style setups, so an End User can prove their Identity to + a Consumer without having to leave the page they are on. +</p> +<p>The OpenID Authentication specification does not provide any + mechanism to exchange profile information, though Consumers of + an Identity can learn more about an End User from any public, + semantically interesting documents linked thereunder (FOAF, RSS, + Atom, vCARD, etc.). Extensions are being built on top of the + foundation created by OpenID Authentication to provide + mechanisms to exchange profile information. +</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> +Overview<br> + <a href="#anchor4">3.1.</a> +Transforming a HTML Document Into an Identifier<br> + <a href="#delegating_authentication">3.1.1.</a> +Delegating Authentication<br> + <a href="#anchor6">3.2.</a> +Submitting a Claimed Identifier<br> + <a href="#anchor8">3.3.</a> +Consumer Site Fetches the Identifier URL<br> + <a href="#smart_vs_dumb">3.4.</a> +Smart vs Dumb Mode<br> + <a href="#anchor11">3.5.</a> +Consumer Verifies the Identifier<br> +<a href="#anchor12">4.</a> +Modes<br> + <a href="#mode_associate">4.1.</a> +associate<br> + <a href="#anchor13">4.1.1.</a> +Request Parameters<br> + <a href="#anchor14">4.1.2.</a> +Response Parameters<br> + <a href="#anchor15">4.1.3.</a> +Extra Notes<br> + <a href="#mode_checkid_immediate">4.2.</a> +checkid_immediate<br> + <a href="#anchor16">4.2.1.</a> +Request Parameters<br> + <a href="#anchor17">4.2.2.</a> +Response Parameters<br> + <a href="#anchor21">4.2.3.</a> +Extra Notes<br> + <a href="#mode_checkid_setup">4.3.</a> +checkid_setup<br> + <a href="#anchor22">4.3.1.</a> +Request Parameters<br> + <a href="#anchor23">4.3.2.</a> +Respone Parameters<br> + <a href="#anchor26">4.3.3.</a> +Extra Notes<br> + <a href="#mode_check_authentication">4.4.</a> +check_authentication<br> + <a href="#anchor27">4.4.1.</a> +Request Parameters<br> + <a href="#anchor28">4.4.2.</a> +Response Parameters<br> + <a href="#anchor29">4.4.3.</a> +Extra Notes<br> +<a href="#anchor30">5.</a> +Security Considerations<br> +<a href="#defaults">Appendix A.</a> +Default Values<br> +<a href="#pvalue">Appendix A.1.</a> +Diffie-Hellman P Value<br> +<a href="#anchor31">Appendix B.</a> +Error Responses<br> +<a href="#anchor32">Appendix C.</a> +Key-Value Format<br> +<a href="#limits">Appendix D.</a> +Limits<br> +<a href="#anchor33">Appendix E.</a> +Misc<br> +<a href="#rfc.references1">6.</a> +Normative References<br> +<a href="#rfc.authors">§</a> +Authors' Addresses<br> +</p> +<br clear="all"> + +<a name="anchor1"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.1"></a><h3>1. Requirements Notation</h3> + +<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as + described in <a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .</span><span>)</span></a>. +</p> +<a name="anchor2"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.2"></a><h3>2. Terminology</h3> + +<p> + </p> +<blockquote class="text"><dl> +<dt>End User:</dt> +<dd>The actual human user who wants to + prove their Identity to a Consumer. +</dd> +<dt>Identifier:</dt> +<dd>An Identifier is just a URL. The whole + flow of the OpenID Authentication protocol is about proving + that an End User is, owns, a URL. +</dd> +<dt>Claimed Identifier:</dt> +<dd>An Identifier that the End + User says they own, though that has not yet been verified by + the Consumer. +</dd> +<dt>Verified Identifier:</dt> +<dd>An Identifier that the + End User has proven to a Consumer that they own. +</dd> +<dt>Consumer:</dt> +<dd>A web service that wants proof that + the End User owns the Claimed Identifier. +</dd> +<dt>Identity Provider:</dt> +<dd>Also called "IdP" or + "Server". This is the OpenID Authentication server + that a Consumer contacts for cryptographic proof that the + End User owns the Claimed Identifier. + <br> + + How the End User authenticates to their Identity Provider is + outside of the scope of OpenID Authenticaiton. + +</dd> +<dt>User-Agent:</dt> +<dd>The End User's web browser. No + special plug-ins or JavaScript required. +</dd> +</dl></blockquote><p> + +</p> +<a name="anchor3"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3"></a><h3>3. Overview</h3> + +<a name="anchor4"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.1"></a><h3>3.1. Transforming a HTML Document Into an Identifier</h3> + +<p>In order for a Consumer to know the Identity Provider + authoritative for an Identifier, the End User must add markup to + the HEAD section of the HTML document located at their + URL. The host of the HTML document is NOT REQUIRED to also be + the End User's Identity Provider; the Identifier URL and + Identity Provider can be fully decoupled services. +</p> +<p>To use http://example.com/ as the End User's Identifier + http://openid.example.com as their Identity Provider, the + following tag would be added to the HEAD section of the HTML + document returned when fetching their Identifier URL. +</p> +<p><link rel="openid.server" + href="http://openid.example.com/"> +</p> +<a name="delegating_authentication"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.1.1"></a><h3>3.1.1. Delegating Authentication</h3> + +<p>If the End User's host is not capable of running an + Identity Provider, or the End User wishes to use one running + on a different host, they will need to delegate their + authentication. For example, if they want to use their + website, http://www.example.com/, as their Identifier, but + don't have the means, or desire, to run an Identity + Provider. +</p> +<p>If they have a LiveJournal account (say, user + "exampleuser"), and know that LiveJournal provides an OpenID + Identity Provider and that it'll assert that they control + the Identifier http://exampleuser.livejournal.com/ they would + be able to delegate their authentication to LiveJournal's + Identity Provider.. +</p> +<p>So, to use www.example.com as their Identifier, but have + Consumers actually verify + http://exampleuser.livejournal.com/ with the Identity + Provider located at + http://www.livejournal.com/openid/server.bml, they'd add the + following tags to the HEAD section of the HTML document + returned when fetching their Identifier URL. +</p> +<p><link rel="openid.server" + href="http://www.livejournal.com/openid/server.bml"> +</p> +<p><link rel="openid.delegate" + href="http://exampleuser.livejournal.com/"> +</p> +<p>Now, when a Consumer sees that, it'll talk to + http://www.livejournal.com/openid/server.bml and ask if + the End User is exampleuser.livejournal.com, never mentioning + www.example.com anywhere on the wire. +</p> +<p>The main advantage of this is that an End User can keep + their Identifier over many years, even as services come and + go; they'll just keep changing who they delegate to. +</p> +<a name="anchor5"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.1.2"></a><h3>3.1.2. Important Notes</h3> + +<p> + </p> +<ul class="text"> +<li>The declared openid.server URL MAY contain existing + query parameters and they MUST be properly preserved when + appending extra query parameters. For example, not adding + a second question mark if one already exists. +</li> +<li>The openid.server and openid.delegate URLs MUST + be absolute URLs. Consumers MUST NOT attempt to + resolve relative URLs. +</li> +<li>The openid.server and openid.delegate URLs MUST + NOT include entities other than &, <, >, + and ". 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="#RFC2396">[RFC2396]<span> (</span><span class="info">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .</span><span>)</span></a>. +</li> +</ul><p> + +</p> +<a name="anchor6"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.2"></a><h3>3.2. Submitting a Claimed Identifier</h3> + +<p>Continuing this example, the End User visits a Consumer + site which supports OpenID Authentication. The Consumer + presents the End User with a form field for them to enter + their Identifier URL. +</p> +<p> + +</p><p>For Example: +</p><pre> ---------------------------------- + |[logo]example.com | [Login Button] + ---------------------------------- +</pre> + + +<a name="anchor7"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.2.1"></a><h3>3.2.1. Important Notes</h3> + +<p> + </p> +<ul class="text"> +<li>It is RECOMMENDED that every Consumer 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 URL. +</li> +<li>The End User is NOT REQUIRED to prefix + their Identifier URL with "http://" or postfix it with a + trailing slash. Consumers MUST canonicalize the Identifier + URL, following redirects, and note the final URL. + The final, canonicalized URL is the End User's + Identifier. +</li> +<li>It is RECOMMENDED that the form field be named + "openid_url" so User-Agent's will auto-complete the End + User's Identifier URL in the same way the eCommerce world + tends to use conventions like "address1" and + "address2". +</li> +</ul><p> + +</p> +<a name="anchor8"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.3"></a><h3>3.3. Consumer Site Fetches the Identifier URL</h3> + +<p>Now the Consumer site fetchs the document located at the End + User's Claimed Identifier. The Consumer then parses the HEAD + section for the "openid.server" and the optional + "openid.delegate" declarations. +</p> +<a name="anchor9"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.3.1"></a><h3>3.3.1. Important Notes</h3> + +<p> + </p> +<ul class="text"> +<li>The End User could be malicious and try to make the + Consumer connect to an internal network, tarpit, etc. It + is RECOMMENDED that Consumers use a paranoid HTTP library like <a href="http://search.cpan.org/%7Ebradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm">LWPx::ParanoidAgent</a> that protects against these sorts of attacks. +</li> +<li>Consumers MUST implement support for <a class="info" href="#delegating_authentication">Delegation<span> (</span><span class="info">Delegating Authentication</span><span>)</span></a>. +</li> +</ul><p> + +</p> +<a name="smart_vs_dumb"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.4"></a><h3>3.4. Smart vs Dumb Mode</h3> + +<p>OpenID Authentication supports both a "smart mode" and + "dumb mode" to accomodate Consumers of differing + capabilities. A smart Consumer does a little more work at the + beginning to save itself work later, but requires local + caching of state information. A dumb Consumer is completely + stateless, but requires extra an HTTP request. +</p> +<a name="anchor10"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.4.1"></a><h3>3.4.1. Important Notes for Smart Mode</h3> + +<p> + </p> +<ul class="text"> +<li>It's RECOMMENDED that a Consumer first submit an + <a class="info" href="#mode_associate">associate request<span> (</span><span class="info">associate</span><span>)</span></a> + to the End User's Identity Provider and request a shared + secret if the Consumer does not already have one + cached. This shared secret SHOULD be used as the + HMAC-SHA1 key in future identity check requests until it + expires. +</li> +<li>The shared secret can be exchanged either in + plain-text or encrypted with a Diffie-Hellman-negotiated + secret. Note that if Diffie-Hellman is used, it's only + used in the associate mode. The <a class="info" href="#mode_checkid_immediate">checkid_immediate<span> (</span><span class="info">checkid_immediate</span><span>)</span></a> + and <a class="info" href="#mode_checkid_setup">checkid_setup<span> (</span><span class="info">checkid_setup</span><span>)</span></a> + modes assume the Consumer already has a shared secret, + regardless of how it got it. +</li> +</ul><p> + +</p> +<a name="anchor11"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.3.5"></a><h3>3.5. Consumer Verifies the Identifier</h3> + +<p>The Consumer now constructs a URL to the Identity + Provider's <a class="info" href="#mode_checkid_immediate">checkid_immediate<span> (</span><span class="info">checkid_immediate</span><span>)</span></a> (or + <a class="info" href="#mode_checkid_setup">checkid_setup<span> (</span><span class="info">checkid_setup</span><span>)</span></a>) URLs + and sends the User-Agent to it. +</p> +<p>By sending the User-Agent there, the End User's cookies and + whatever other login credentials are sent back to their + trusted Identity Provider. The Identity Provider does its + work, appends its response onto the supplied openid.return_to + URL, and sends the User-Agent back to the Consumer. +</p> +<a name="anchor12"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4"></a><h3>4. Modes</h3> + +<a name="mode_associate"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.1"></a><h3>4.1. associate</h3> + +<p> + </p> +<ul class="text"> +<li>Description: Establish a shared secret between Consumer + and Identity Provider. +</li> +<li>HTTP method: POST +</li> +<li>Flow: Consumer -> IdP -> Consumer +</li> +</ul><p> + +</p> +<a name="anchor13"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.1.1"></a><h3>4.1.1. Request Parameters</h3> + +<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>Value: Preferred association type +</p> +<p>Default: "HMAC-SHA1" +</p> +<p>Note: Optional; Currently only one value. +</p> +</blockquote> + +</li> +<li> + openid.session_type + +<blockquote class="text"> +<p>Value: Blank or "DH-SHA1" +</p> +<p>Default: Blank. (cleartext) +</p> +<p>Note: It is RECOMMENDED that DH-SHA1 mode is used + to encrypt the shared secret. +</p> +</blockquote> + +</li> +<li> + openid.dh_modulus + +<blockquote class="text"> +<p>Value: base64(btwoc(p)) +</p> +<p>Note: See <a class="info" href="#pvalue">Appendix A.1<span> (</span><span class="info">Diffie-Hellman P Value</span><span>)</span></a> for default p value. +</p> +</blockquote> + +</li> +<li> + openid.dh_gen + +<blockquote class="text"> +<p>Value: base64(btwoc(g)) +</p> +<p>Default: g = 2 +</p> +<p>Note: Only if using DH-SHA1 session_type. Should + be specified if openid.dh_modulus is specified. +</p> +</blockquote> + +</li> +<li> + openid.dh_consumer_public + +<blockquote class="text"> +<p>Value: base64(btwoc(g ^ x mod p)) +</p> +<p>Note: REQUIRED if using DH-SHA1 session_type. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor14"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.1.2"></a><h3>4.1.2. Response Parameters</h3> + +<p>Response format: Key-Value Pairs +</p> +<p> + </p> +<ul class="text"> +<li> + assoc_type + +<blockquote class="text"> +<p>Value: The association type for the returned handle. +</p> +<p>Note: The only current mode is HMAC-SHA1, and all + Consumers MUST support it. When caching, the + Consumer MUST map an assoc_handle to both its secret + and its assoc_type. +</p> +</blockquote> + +</li> +<li> + assoc_handle + +<blockquote class="text"> +<p>Value: The association handle to be provided in future + transactions. +</p> +<p>Note: Consumers MUST NOT reuse this association + handle after the corresponding expires_in value. +</p> +</blockquote> + +</li> +<li> + expires_in + +<blockquote class="text"> +<p>Value: The number of seconds this association + handle is good for in base10 ASCII. +</p> +</blockquote> + +</li> +<li> + session_type + +<blockquote class="text"> +<p>Value: The encryption mode that the Provider chose. MAY be + blank, absent, or "DH-SHA1". +</p> +</blockquote> + +</li> +<li> + dh_server_public + +<blockquote class="text"> +<p>Value: base64(btwoc(g ^ y mod p)) +</p> +<p>Description: The Provider's <a class="info" href="#RFC2631">Diffie-Hellman public key<span> (</span><span class="info">Rescorla, E., “Diffie-Hellman Key Agreement Method,” .</span><span>)</span></a> [RFC2631], if + using DH-SHA1. +</p> +</blockquote> + +</li> +<li> + enc_mac_key + +<blockquote class="text"> +<p>Value: base64(SHA1(btwoc(g ^ (xy) mod p)) XOR secret(assoc_handle)) +</p> +<p>Description: The encrypted shared secret, if using + DH-SHA1. +</p> +</blockquote> + +</li> +<li> + mac_key + +<blockquote class="text"> +<p>Value: base64(secret(assoc_handle)) +</p> +<p>Description: The plaintext shared secret, if not + using DH-SHA1. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor15"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.1.3"></a><h3>4.1.3. Extra Notes</h3> + +<p> + </p> +<ul class="text"> +<li>A Consumer can ask a server for DH-SHA1 encryption and + get back a plaintext secret. If this troubles you, don't + use the handle and instead use dumb mode with that + Identity Provider. + <br> +<br> + + If somebody sniffed the plaintext secret, it won't + matter, since you'll never accept queries using that + association handle. If the Identity Provider can't do + DH-SHA1, it's probably limited in some way, but using + dumb mode is still safe, if not a little slower. +</li> +<li>If the Identity Provider chooses the server private + key 1 <= y < p-1. The shared DH-SHA1 secret is + thus g ^ xy mod p = (g ^ x) ^ y mod p = (g ^ y) ^ x mod + p. For more information, read the <a href="http://search.cpan.org/%7Ebtrott/Crypt-DH-0.06/lib/Crypt/DH.pm">Crypt::DH docs.</a> +</li> +<li>The underlying mac_key MUST be the same length as the + output of H, the hash function - in this instance, 160 + bits (20 bytes) for DH-SHA1. +</li> +<li>If the Provider does not support DH-SHA1, they WILL ignore + the DH-SHA1 fields in the request and reply exactly as to a + non-DH-SHA1 request. +</li> +<li>When using DH-SHA1, the resulting key SHOULD be treated + as a binary string. +</li> +<li>Most integers are represented in big-endian signed two's + complement, Base64 encoded. In other words, btwoc is a + function that takes a bigint and returns its shortest + big-endian two's complement notation +</li> +</ul><p> + +</p> +<a name="mode_checkid_immediate"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2"></a><h3>4.2. checkid_immediate</h3> + +<p> + </p> +<ul class="text"> +<li>Description: Ask an Identity Provider if a End User owns the + Claimed Identifier, getting back an immediate "yes" or "can't say" + answer. +</li> +<li>HTTP method: GET +</li> +<li>Flow: Consumer -> User-Agent -> IdP -> User-Agent -> + Consumer +</li> +</ul><p> + +</p> +<a name="anchor16"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.1"></a><h3>4.2.1. Request Parameters</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.mode + +<blockquote class="text"> +<p>Value: "checkid_immediate" +</p> +</blockquote> + +</li> +<li> + openid.identity + +<blockquote class="text"> +<p>Value: Claimed Identifier +</p> +</blockquote> + +</li> +<li> + openid.assoc_handle + +<blockquote class="text"> +<p>Value: The assoc_handle from the associate request. +</p> +<p>Note: Optional; Consumer MUST use + check_authentication if an association handle isn't + provided or the Identity Provider feels it is invalid. +</p> +</blockquote> + +</li> +<li> + openid.return_to + +<blockquote class="text"> +<p>Value: URL where the Provider SHOULD return the + User-Agent back to. +</p> +</blockquote> + +</li> +<li> + openid.trust_root + +<blockquote class="text"> +<p>Value: URL the Provider SHALL ask the End User to trust. +</p> +<p>Default: return_to URL +</p> +<p>Optional; the URL which the End User SHALL + actually see to approve. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor17"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.2"></a><h3>4.2.2. Response Parameters</h3> + +<p>Response format: query string arguments +</p> +<a name="anchor18"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.2.1"></a><h3>4.2.2.1. Always Sent</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.mode + +<blockquote class="text"> +<p>Value: "id_res" +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor19"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.2.2"></a><h3>4.2.2.2. Sent on Failed Assertion</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.user_setup_url + +<blockquote class="text"> +<p>Value: URL to redirect User-Agent to so the End + User can do whatever's necessary to fulfill the + assertion. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor20"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.2.3"></a><h3>4.2.2.3. Sent on Positive Assertion</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.identity + +<blockquote class="text"> +<p>Value: Verified Identifier +</p> +</blockquote> + +</li> +<li> + openid.assoc_handle + +<blockquote class="text"> +<p>Value: Opaque association handle being used to + find the HMAC key for the signature. +</p> +</blockquote> + +</li> +<li> + openid.return_to + +<blockquote class="text"> +<p>Value: Verbatim copy of the return_to URL + parameter sent in the request, before the Provider + modified it. +</p> +</blockquote> + +</li> +<li> + openid.signed + +<blockquote class="text"> +<p>Value: Comma-seperated list of signed fields. +</p> +<p>Note: Fields without the "openid." prefix that + the signature covers. For example, + "mode,identity,return_to". +</p> +</blockquote> + +</li> +<li> + openid.sig + +<blockquote class="text"> +<p>Value: base64(HMAC(secret(assoc_handle), token_contents) +</p> +<p>Note: Where token_contents is a key-value + format string of all the signed keys and values in + this response. They MUST be in the same order as + listed in the openid.signed field. Consumer SHALL + recreate the token_contents string prior to + checking the signature. See <a class="info" href="#limits">Appendix D<span> (</span><span class="info">Limits</span><span>)</span></a>. +</p> +</blockquote> + +</li> +<li> + openid.invalidate_handle + +<blockquote class="text"> +<p>Value: Optional; The association handle sent in + the request if the Provider did not accept or + recognize it. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor21"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.2.3"></a><h3>4.2.3. Extra Notes</h3> + +<p> + </p> +<ul class="text"> +<li>This mode is commonly used for "AJAX"-style + setups. The more classic mode to check a Claimed + Identifier is <a class="info" href="#mode_checkid_setup">checkid_setup<span> (</span><span class="info">checkid_setup</span><span>)</span></a>. +</li> +<li>An Identity Provider SHOULD only assert URLs that it + manages/produces directly. If a End User wants to assert + other URLs outside of that Identity Provider's realm, + they MUST use <a class="info" href="#delegating_authentication">delegation<span> (</span><span class="info">Delegating Authentication</span><span>)</span></a>. +</li> +<li>The openid.return_to URL provided MAY contain an + existing query string, and the Provider MUST preserve it + when appending the response parameters. OpenID Consumer's + SHOULD add a self-signed nonce with + Consumer-local timestamp in the openid.return_to URL + parameters to prevent replay attacks. Details of that + are left up to the Consumer. + <br> +<br> + + However, because the openid.return_to URL is signed by + the Idenity Provide, a Consumer can make sure outside + parties haven't sent id_res responses with mismatching + openid.return_to URLs and signatures. +</li> +<li>If the Identity Provider didn't accept/recognize the + provided assoc_handle for whatever reason, it'll choose + its own to use, and copy the one provided back into + openid.invalidate_handle, to tell the Consumer to stop + using it. The Consumer SHOULD then send it along in a + <a class="info" href="#mode_check_authentication">check_authentication<span> (</span><span class="info">check_authentication</span><span>)</span></a> + request to verify it actually is no longer valid. +</li> +<li>If the Identifier assertion fails, the Identity + Provider provides the openid.user_setup_url for where + the End User can do whatever's necessary to fulfill the + assertion, be it login, setup permissions, etc. The + server SHOULD return a URL which doesn't imply anything + about what's needed, so the Consumer is left in the dark + about why the assertion failed. + <br> +<br> + + The Identity Provider handling SHOULD eventually return + the End User to the openid.return_to URL, acting like a + checkid_setup response, with either a "id_res" or "cancel" + mode. +</li> +<li>The openid.return_to URL MUST descend from the + openid.trust_root, or the Identity Provider SHOULD + return an error. Namely, the URL scheme and port MUST + match. The path, if present, MUST be equal to or below + the value of openid.trust_root, and the domains on both + MUST match, or, the openid.trust_root value contain a + wildcard like http://*.example.com. The wildcard SHALL + only be at the beginning. It is RECOMMENDED Identity + Provider's protect their End Users from requests for + things like http://*.com/ or http://*.co.uk/. +</li> +<li>In the response, the Identity Provider's signature + MUST cover openid.identity and openid.return_to. +</li> +</ul><p> + +</p> +<a name="mode_checkid_setup"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3"></a><h3>4.3. checkid_setup</h3> + +<p> + </p> +<ul class="text"> +<li>Description: Ask an Identity Provider if a End User owns the + Claimed Identifier, but be willing to wait for the reply. + The Consumer will pass the User-Agent to the Identity + Provider for a short period of time which will return + either a "yes" or "cancel" answer. +</li> +<li>HTTP method: GET +</li> +<li>Flow: Consumer -> User-Agent -> [IdP -> User-Agent + ->]+ Consumer +</li> +</ul><p> + +</p> +<a name="anchor22"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3.1"></a><h3>4.3.1. Request Parameters</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.mode + +<blockquote class="text"> +<p>Value: "checkid_setup" +</p> +</blockquote> + +</li> +<li> + openid.identity + +<blockquote class="text"> +<p>Value: Claimed Identifier +</p> +</blockquote> + +</li> +<li> + openid.assoc_handle + +<blockquote class="text"> +<p>Value: The assoc_handle from the associate request. +</p> +<p>Note: Optional; Consumer MUST use + check_authentication if an association handle isn't + provided or the Identity Provider feels it is invalid. +</p> +</blockquote> + +</li> +<li> + openid.return_to + +<blockquote class="text"> +<p>Value: URL where the Provider SHOULD return the + User-Agent back to. +</p> +</blockquote> + +</li> +<li> + openid.trust_root + +<blockquote class="text"> +<p>Value: URL the Provider SHALL ask the End User to trust. +</p> +<p>Default: return_to URL +</p> +<p>Optional; the URL which the End User SHALL + actually see to approve. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor23"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3.2"></a><h3>4.3.2. Respone Parameters</h3> + +<p>Response format: query string arguments +</p> +<a name="anchor24"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3.2.1"></a><h3>4.3.2.1. Always Sent</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.mode + +<blockquote class="text"> +<p>Value: "id_res" or "cancel" +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor25"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3.2.2"></a><h3>4.3.2.2. Sent on Positive Assertion</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.identity + +<blockquote class="text"> +<p>Value: Verified Identifier +</p> +</blockquote> + +</li> +<li> + openid.assoc_handle + +<blockquote class="text"> +<p>Value: Opaque association handle being used to + fine the HMAC key for the signature. +</p> +</blockquote> + +</li> +<li> + openid.return_to + +<blockquote class="text"> +<p>Value: Verbatim copy of the return_to URL + parameter sent in the request, before the Provider + modified it. +</p> +</blockquote> + +</li> +<li> + openid.signed + +<blockquote class="text"> +<p>Value: Comma-seperated list of signed fields. +</p> +<p>Note: Fields without the "openid." prefix that + the signature covers. For example, + "mode,identity,return_to". +</p> +</blockquote> + +</li> +<li> + openid.sig + +<blockquote class="text"> +<p>Value: base64(HMAC(secret(assoc_handle), token_contents) +</p> +<p>Note: Where token_contents is a key-value + format string of all the signed keys and values in + this response. They MUST be in the same order as + listed in the openid.signed field. Consumer SHALL + recreate the token_contents string prior to + checking the signature. See <a class="info" href="#limits">Appendix D<span> (</span><span class="info">Limits</span><span>)</span></a>. +</p> +</blockquote> + +</li> +<li> + openid.invalidate_handle + +<blockquote class="text"> +<p>Value: Optional; The association handle sent in + the request if the Provider did not accept or + recognize it. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor26"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.3.3"></a><h3>4.3.3. Extra Notes</h3> + +<p> + </p> +<ul class="text"> +<li>In the response, the Identity Provider's signature + MUST cover openid.identity and openid.return_to. +</li> +<li>In a lot of cases, the Consumer won't get a cancel mode; the + End User will just quit or press back within their + User-Agent. But if it is returned, the Consumer SHOULD + return to what it was doing. In the case of a cancel + mode, the rest of the response parameters will be + absent. +</li> +</ul><p> + +</p> +<a name="mode_check_authentication"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.4"></a><h3>4.4. check_authentication</h3> + +<p> + </p> +<ul class="text"> +<li>Description: Ask an Identity Provider if a message is + valid. For dumb, stateless Consumers or when verifying an + invalidate_handle response. + <br> +<br> + + <span class="strong">WARNING: Only validates signatures + with stateless association handles. Identity Providers + MUST NOT ever validate a signature for an association + handle whose secret has been shared with anybody. They + MUST differentiate its stateless vs. associated + association handles, and only offer check_authentication + service on the stateless handles.</span> + +</li> +<li>HTTP method: POST +</li> +<li>Flow: Consumer -> IdP -> Consumer +</li> +</ul><p> + +</p> +<a name="anchor27"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.4.1"></a><h3>4.4.1. Request Parameters</h3> + +<p> + </p> +<ul class="text"> +<li> + openid.mode + +<blockquote class="text"> +<p>Value: "check_authentication" +</p> +</blockquote> + +</li> +<li> + openid.assoc_handle + +<blockquote class="text"> +<p>Value: The association handle from checkid_setup + or checkid_immediate response. +</p> +</blockquote> + +</li> +<li> + openid.sig + +<blockquote class="text"> +<p>Value: The signature from the checkid_setup or + checkid_immediate request the Consumer wishes to + verify. +</p> +</blockquote> + +</li> +<li> + openid.signed + +<blockquote class="text"> +<p>Value: The list of signed fields from the checkid_setup + or checkid_immediate request the Consumer wishes to + verify the signature of. +</p> +</blockquote> + +</li> +<li> + openid.* + +<blockquote class="text"> +<p>Value: The Consumer MUST send all the openid.* response + parameters from the openid.signed list which they'd + previously gotten back from a checkid_setup or + checkid_immediate request, with their values being + exactly what were returned from the Provider. +</p> +</blockquote> + +</li> +<li> + openid.invalidate_handle + +<blockquote class="text"> +<p>Value: Optional; association handle returned via + invalidate_handle. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor28"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.4.2"></a><h3>4.4.2. Response Parameters</h3> + +<p>Response format: Key-Value Pairs +</p> +<p> + </p> +<ul class="text"> +<li> + openid.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: opaque association handle +</p> +<p>Description: If present, the Consumer SHOULD + uncache the returned association handle. +</p> +</blockquote> + +</li> +</ul><p> + +</p> +<a name="anchor29"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.4.4.3"></a><h3>4.4.3. Extra Notes</h3> + +<p> + </p> +<ul class="text"> +<li>Identity Providers MUST implement this mode for error + recovery and dumb Consumers, which can't keep state + locally, but it's RECOMMENDED that it is used as little + as possible, as it shouldn't be necessary most the + time. It's good for debugging, though, as you develop + your Consumer library. +</li> +<li>If you got an invalidate_handle response during a + checkid_setup or checkid_immediate request, that means + the Identity Provider didn't recognize the association + handle, maybe it lost it, and had to pick its own. + <br> +<br> + + This means the Consumer will have to fallback to dumb + mode, since you don't have the shared secret which the + Identity Provider is using. While doing this + check_authentication request, also send along the + invalidate_handle response from the Identity Provider + and it'll be checked to see if it actually is + missing/bogus. +</li> +<li>When verifying the signature using openid.* query + values, the openid.mode value must be changed to + "id_res". +</li> +</ul><p> + +</p> +<a name="anchor30"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.5"></a><h3>5. Security Considerations</h3> + +<p> + </p> +<ul class="text"> +<li>While the OpenID Authentication protocol often refers to + using HTTP, HTTPS can be used for additional security. It is + RECOMMENDED it is used during the <a class="info" href="#mode_associate">associate mode<span> (</span><span class="info">associate</span><span>)</span></a> and helps to + protect against man in the middle, DNS, and some phishing + attacks. +</li> +<li>Consumers SHOULD NOT use IFrames or popup's when requesting + an End User login via OpenID. +</li> +</ul><p> + +</p> +<a name="defaults"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.A"></a><h3>Appendix A. Default Values</h3> + +<a name="pvalue"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.A.1"></a><h3>Appendix A.1. Diffie-Hellman P Value</h3> + +<p> + 1551728981814736974712322577637155\ + 3991572480196691540447970779531405\ + 7629378541917580651227423698188993\ + 7278161526466314385615958256881888\ + 8995127215884267541995034125870655\ + 6549803580104870537681476726513255\ + 7470407658574792912915723345106432\ + 4509471500722962109419434978392598\ + 4760375594985848253359305585439638443 + +</p> +<a name="anchor31"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.B"></a><h3>Appendix B. Error Responses</h3> + +<p>This section pertains to protocol/run-time errors, not + authentication errors. Authentication errors are defined in + the protocol. +</p> +<p> + </p> +<ul class="text"> +<li>No error codes have been defined; just unstructured natural + language error text. +</li> +<li>If it's a GET request with bad arguments, but a valid + openid.return_to URL, the Identity Provider SHALL redirect + the User-Agent with openid.mode=error and + openid.error=Error+Text set. +</li> +<li>If it's a GET request with bad arguments, and no valid + openid.return_to URL, the Identity Provider SHALL return a + "400 Bad Request" with any content-type and error message it + wants. +</li> +<li>If it's a GET request with no arguments, the Identity + Provider SHALL show a 200 text/html error saying "This is an + OpenID server endpoint. For more information, see + http://openid.net/". +</li> +<li>If it's a POST request with bad/no arguments, the + Identity Provider SHALL return a 400 Bad Eequest with the + Key-Value response format containing a single key "error" + with the natural language text. The Identity Provider can + add any additonal keys it wishes in this case. +</li> +</ul><p> + +</p> +<a name="anchor32"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.C"></a><h3>Appendix C. Key-Value Format</h3> + +<p>Lines of: +</p> +<p> + </p> +<ul class="text"> +<li>some_key:some value +</li> +<li>There MUST NOT be a space before or after the colon. +</li> +<li>Newline characters MUST be Unix-style, just ASCII character 10 + ("\n"). +</li> +<li>Newlines MUST BE at end of each line as well as between lines. +</li> +<li>MIME type is unspecified, but text/plain is + RECOMMENDED. +</li> +<li>Character encoding MUST BE UTF-8. +</li> +</ul><p> + +</p> +<a name="limits"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.D"></a><h3>Appendix D. Limits</h3> + +<p> + </p> +<ul class="text"> +<li>Identifier URL: 255 max bytes +</li> +<li>Identity Provider URL: 2047 max bytes, after Consumer-added + URL arguments. The raw endpoint URL SHOULD be kept well + below this. +</li> +<li>return_to URL: 2047 max bytes, after Identity Provider + added URL arguments. The raw return_to URL SHOULD be kept + well below this. +</li> +<li>assoc_handle: 255 characters or less, and consist only of + ASCII characters in the range 33-126 inclusive (ie printable + non-whitespace characters). +</li> +</ul><p> + +</p> +<a name="anchor33"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<a name="rfc.section.E"></a><h3>Appendix E. Misc</h3> + +<p> + </p> +<ul class="text"> +<li>Timestamps must be in w3c format, and must be in the UTC + timezone, indicated with a "Z". For example: + 2005-05-15T17:11:51Z +</li> +</ul><p> + +</p> +<a name="rfc.references1"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<h3>6. Normative References</h3> +<table border="0" width="99%"> +<tbody><tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td> +<td class="author-text">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels.”</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2396">[RFC2396]</a></td> +<td class="author-text">Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax.”</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2631">[RFC2631]</a></td> +<td class="author-text">Rescorla, E., “Diffie-Hellman Key Agreement Method.”</td></tr> +</tbody></table> + +<a name="rfc.authors"></a><br><hr> +<table summary="layout" class="bug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="bug"><a href="#toc" class="link2"> TOC </a></td></tr></tbody></table> +<h3>Authors' Addresses</h3> +<table border="0" cellpadding="0" cellspacing="0" width="99%"> +<tbody><tr><td class="author-text"> </td> +<td class="author-text">David + Recordon</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">Brad + Fitzpatrick</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> +</tbody></table> + +</body></html>
\ No newline at end of file |