This page lists some best practices for Relying Parties. This may one day become a quality review document for assessing the completeness of relying party implementations. For now, it's just a work in progress.

Please continue this list in a similar vein. Individual items here can be discussed on an appropriate mailing list, or on the wiki discussion page if you like that sort of thing.

This document is roughly divided up into several "compliance levels". Most RPs should at the very least comply with the first, and should aim to comply with as many as possible. Note: We'll have to come up with some better names for these levels.

Many of these requirements are for sites that create some sense of an "account" when users log in. If your site just uses one-shot authentication and retains no persistant data against a particular identifier, you automatically pass these requirements.

Basic

Site allows user to authenticate using an OpenID identifier

This one's pretty obvious. If you can't do this, you aren't an OpenID RP!

Site allows creation of new user account by simply signing in using an OpenID identifier

Assuming your site allows unrestricted account creation, to create a new user account, a user should simply be able to find an OpenID sign-in box and sign in. If your site doesn't already have a local account for the user, it should create one if necessary, asking the user for any information that was not provided using ether SReg or AX at authentication time.

One Site Account per OpenID, unless the site enables manual account selection

An RP site should never create two accounts that are attached to the same OpenID, unless the site has the ability to allow the user to select which account to use once OpenID Authentication is successful.

Site unambiguously indicates authenticated users

Some sites allow both authenticated and unauthenticated users. If unauthenticated users are allowed to give a URL as part of their attribution, it should be made clear which URLs are authenticated (for example, by OpenID) and which are not.

Rationale: If the two are not distinct, anonymous users can "pose" as authenticated OpenID users.

Treat extensions as optional, not mandatory

If your site makes use of an extension to the authentication process, for example the Simple Registration Extension, handle the situation gracefully if the provider does not support the extension. In the Simple Registration case, for example, you could present a form for the user to enter the required information manually, or compute some sensible defaults.

Rationale: Not all providers will support all extensions, and extension-related error messages create an inconsistent and undesirable user experience.

Clearly inform the user if their OpenID will be published

Publishing a user's OpenID allows third parties to correlate their accounts from multiple sites. Users should be aware of this, and if appropriate should be able to opt-in or out of having their OpenID publically displayed.

Would Be Nice

OpenID-authenticated users have full access to all provided services

Many sites accept both OpenID authentication and traditional local username/password pairs. Differentiate the two only by authentication mechanism, and provide equivalent functionality to each.

Note: There is no reason why OpenID users can't be asked to agree to terms of service, pass CAPTCHAS, etc whenever an identifier is used with the site for the first time. Therefore OpenID users can be just as "trusty" as local users.

Rationale: On a site where OpenID users are treated as second class citizens, people are less likely to use OpenID for authentication.

Allow users to upgrade from a local username/password account to an OpenID account

Many sites have a legacy of traditional local username/password authentication. Allow existing users either to switch to using OpenID completely or to associate both an OpenID Identifier and a password with their account.

Rationale: Users shouldn't have to throw their old accounts away to use OpenID.

Allow users to change the OpenID Identifier associated with their account

Allow a user to, while logged in, authenticate as a second identifier and replace the existing identifier association with the new identifier.

Rationale: Allows users to change their identifier without losing their accounts.

Brilliant

Provide Lost Identifier functionality to switch to a new identifier without access to the old one

Provide a mechanism to switch an account to use a new identifier without access to the old identifier(s) associated with the account. This can take a similar form to the traditional "Forgot your password?" email verification dance, assuming that you have the user's email address on file.

Rationale: Users will sometimes lose the ability to use their identifiers, such as when their provider ceases to offer service to them. This functionality allows users to recover from this situation without losing their data.

Provide the ability to merge accounts

Allow two previously-distinct accounts to be merged into one account, either by some application-defined merging algorithm or just by throwing one of the accounts away.

This is particually appliable to sites that allow multiple identifiers (whether they be OpenID or old-fashioned usernames/passwords) to be associated with an account.

Rationale: Users may log in with a separate OpenID identifier before they realise that a site allows a legacy account to be upgraded, or before they realise that several identifiers can be associated with one account. This allows them to recover from this situation by uniting the distinct identifiers into one account.

Many-to-one relationship between Identity URLs and user accounts

For RPs that create some form of user account in response to an initial OpenID login, allow the user to attach additional URLs to that account that are considered to be the same user.

Rationale: Allows users to more easily migrate from one identifier to another, and to allow the user to show that multiple identifiers are "the same user".

Don't require users to choose locally-unique usernames

Use the OpenID identifier as the primary identifier for a user. Do not require a user to choose a second identifier that is unique only within your site.

Rationale: Users already have a globally-applicable identifier. Having to also create a local identifier is an annoying and confusing extra step, and is likely to result in an undesirable username in particularly cluttered namespaces.

Allow, but do not require, users to attach a handle or name to their identity

Allow users to enter some kind of friendly name (their full name, or some kind of nickname) to go along with their unique identifier, and display the friendly name alongside the identifier. These friendly names need not be unique because they are accompanied by a verified OpenID identifier. For example, a forum post:

This applies both to sites that create "user accounts", such as forums, and those that are one-shot, such as weblog comments. The difference is that in the latter case you may invite the user to specify his name each time rather than storing it as a global setting for that identity.

Implementors may wish to generate a suitable default displayname in cases where one is not specified in order to avoid inconsistency between these two cases. For example, a site could use simple heuristics to turn the identifier "http://frank.example.com/" into "frank [example.com]".

Sites must be sure to present the unique OpenID identifier in an unambiguous manner; no two distinct OpenID identifiers must result in the same displayed identifier. In situations where displaying full URIs is inconvenient, the identifier URI could be given as the target of a link with an appropriate shorthand as its caption. [TODO: Perhaps define a rel="..." keyword for OpenID identifiers, so that interested software can grovel for them?]

Rationale: Humans prefer names to URLs when talking about people. Most of the time, name collisions aren't a problem. In situations where they do become a problem, the identity URL is available to provide disambiguation. This should be optional because not everyone wants to share their name, and not all users are humans.

Store primary OpenID in a cookie and check_immediate at next session

Set a cookie including the user's OpenID when they have had a successful login. If they come back after their login has been expired, use an immediate request to authenticate them. If authentication fails, clear the cookie. Otherwise, log them in.