Modularizing Auth 2.0 Discovery

[Martin Atkins]

Recently there has been talk about using alternative identifiers for 
OpenID, such as email addresses and Jabber Identifiers. This has made it 
obvious that the OpenID Authentication protocol doesn't care in the 
slightest what the identifier is as long as service discovery can be 
performed on it somehow.

Currently the Authentication 2.0 specification has language in various 
places that constrains it to URIs with the schemes http, https and xri. 
For example, under "Terminology" the following definition is given for 
"Identifier":

     An Identifier is either a "http" or "https" URI, (commonly referred
     to as a "URL" within this document), or an XRI [XRI_Syntax_2.0].
     This document defines various kinds of Identifiers, designed for
     use in different contexts.

My proposal is that we make the core Auth 2.0 spec scheme-agnostic. It 
would just state that an identifier is "a URI". Later in the spec, where 
currently it enumerates a bunch of ways to do discovery, it'd just say 
"do discovery on the URI using an appropriate protocol". (or, indeed, 
words to that effect.) It would also nominate a standard XRDS service 
type URI to use during Yadis discovery.

Then we'd publish in parallel the following two ancillary specifications:
     * OpenID Discovery for HTTP and HTTPS URIs
     * OpenID Discovery for XRI URIs.

Later, the OpenID community or a third party could publish a 
specification "OpenID Discovery for Email Addresses", but I don't think 
we're really ready to go there right now.

The discovery protocols don't necessarily need to be XRDS-based, but if 
they are they would presumably reference the standard service type URI 
from the Auth spec so that future Auth versions can change this without 
needing to re-publish the discovery specs.

This has the following benefits:

   * It gives others a clear, spec-approved mechanism to bolt-on support 
for additional URI schemes.

   * It allows the Authentication specification to evolve separately 
from the various discovery specifications, which are unlikely to need to 
change very much from version-to-version.

   * It formalizes the separation between discovery and authentication, 
giving library authors a clear plug-in point if they wish to support 
modular discovery.

Presumably the OpenID Auth 2.0 spec would still retain a reference to 
the HTTP and HTTPS discovery spec purely so that it can say that RPs 
MUST support it regardless of what else they support.

-------------------------------------

All ancillary discovery specifications must, at minimum, define:

   * A pattern for recognizing and canonicalizing their own identifiers. 
(For example, the XRI one would include a provision for checking for an 
identifier which starts with a global context symbol, etc.)

   * A mechanism for returning the following information:
     - Either: (traditional identity case)
         * Canonical Claimed identifier (an i-number, for example)
         * User-supplied "Display" identifier (an i-name, for example)
         * OP endpoint URL
         * OP-local identifier (i.e. openid:Delegate as was)
     - Or: (directed identity case)
         * OP endpoint URL
         * Canonical OP identifier (for use in confirmation messages)

(And, of course, not all discovery mechanisms would necessarily support 
directed identity.)