TOC 
 D. Recordon
 B. Fitzpatrick
 May 2006

OpenID Authentication 1.1

Abstract

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.

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.

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.

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.



Table of Contents

1.  Requirements Notation
2.  Terminology
3.  Overview
    3.1.  Transforming a HTML Document Into an Identifier
        3.1.1.  Delegating Authentication
    3.2.  Submitting a Claimed Identifier
    3.3.  Consumer Site Fetches the Identifier URL
    3.4.  Smart vs Dumb Mode
    3.5.  Consumer Verifies the Identifier
4.  Modes
    4.1.  associate
        4.1.1.  Request Parameters
        4.1.2.  Response Parameters
        4.1.3.  Extra Notes
    4.2.  checkid_immediate
        4.2.1.  Request Parameters
        4.2.2.  Response Parameters
        4.2.3.  Extra Notes
    4.3.  checkid_setup
        4.3.1.  Request Parameters
        4.3.2.  Respone Parameters
        4.3.3.  Extra Notes
    4.4.  check_authentication
        4.4.1.  Request Parameters
        4.4.2.  Response Parameters
        4.4.3.  Extra Notes
5.  Security Considerations
Appendix A.  Default Values
Appendix A.1.  Diffie-Hellman P Value
Appendix B.  Error Responses
Appendix C.  Key-Value Format
Appendix D.  Limits
Appendix E.  Misc
6.  Normative References
§  Authors' Addresses




 TOC 

1. Requirements Notation

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 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .).



 TOC 

2. Terminology

End User:
The actual human user who wants to prove their Identity to a Consumer.
Identifier:
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.
Claimed Identifier:
An Identifier that the End User says they own, though that has not yet been verified by the Consumer.
Verified Identifier:
An Identifier that the End User has proven to a Consumer that they own.
Consumer:
A web service that wants proof that the End User owns the Claimed Identifier.
Identity Provider:
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.
How the End User authenticates to their Identity Provider is outside of the scope of OpenID Authenticaiton.
User-Agent:
The End User's web browser. No special plug-ins or JavaScript required.



 TOC 

3. Overview



 TOC 

3.1. Transforming a HTML Document Into an Identifier

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.

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.

<link rel="openid.server" href="http://openid.example.com/">



 TOC 

3.1.1. Delegating Authentication

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.

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..

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.

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">

<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">

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.

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.



 TOC 

3.1.2. Important Notes



 TOC 

3.2. Submitting a Claimed Identifier

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.

For Example:

	      ----------------------------------
	      |[logo]example.com               | [Login Button]
	      ----------------------------------


 TOC 

3.2.1. Important Notes



 TOC 

3.3. Consumer Site Fetches the Identifier URL

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.



 TOC 

3.3.1. Important Notes



 TOC 

3.4. Smart vs Dumb Mode

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.



 TOC 

3.4.1. Important Notes for Smart Mode



 TOC 

3.5. Consumer Verifies the Identifier

The Consumer now constructs a URL to the Identity Provider's checkid_immediate (checkid_immediate) (or checkid_setup (checkid_setup)) URLs and sends the User-Agent to it.

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.



 TOC 

4. Modes



 TOC 

4.1. associate



 TOC 

4.1.1. Request Parameters



 TOC 

4.1.2. Response Parameters

Response format: Key-Value Pairs



 TOC 

4.1.3. Extra Notes



 TOC 

4.2. checkid_immediate



 TOC 

4.2.1. Request Parameters



 TOC 

4.2.2. Response Parameters

Response format: query string arguments



 TOC 

4.2.2.1. Always Sent



 TOC 

4.2.2.2. Sent on Failed Assertion



 TOC 

4.2.2.3. Sent on Positive Assertion



 TOC 

4.2.3. Extra Notes



 TOC 

4.3. checkid_setup



 TOC 

4.3.1. Request Parameters



 TOC 

4.3.2. Respone Parameters

Response format: query string arguments



 TOC 

4.3.2.1. Always Sent



 TOC 

4.3.2.2. Sent on Positive Assertion



 TOC 

4.3.3. Extra Notes



 TOC 

4.4. check_authentication



 TOC 

4.4.1. Request Parameters



 TOC 

4.4.2. Response Parameters

Response format: Key-Value Pairs



 TOC 

4.4.3. Extra Notes



 TOC 

5. Security Considerations



 TOC 

Appendix A. Default Values



 TOC 

Appendix A.1. Diffie-Hellman P Value

1551728981814736974712322577637155\ 3991572480196691540447970779531405\ 7629378541917580651227423698188993\ 7278161526466314385615958256881888\ 8995127215884267541995034125870655\ 6549803580104870537681476726513255\ 7470407658574792912915723345106432\ 4509471500722962109419434978392598\ 4760375594985848253359305585439638443



 TOC 

Appendix B. Error Responses

This section pertains to protocol/run-time errors, not authentication errors. Authentication errors are defined in the protocol.



 TOC 

Appendix C. Key-Value Format

Lines of:



 TOC 

Appendix D. Limits



 TOC 

Appendix E. Misc



 TOC 

6. Normative References

[RFC2119] Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels.”
[RFC2396] Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax.”
[RFC2631] Rescorla, E., “Diffie-Hellman Key Agreement Method.”


 TOC 

Authors' Addresses

  David Recordon
Email:  drecordon@verisign.com
  
  Brad Fitzpatrick
Email:  brad@danga.com