+1, I'm fully in support of this and actually have been wanting to do so for quite a number of weeks now!
--David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Wednesday, February 28, 2007 10:44 AM To: specs@openid.net Subject: Modularizing Auth 2.0 Discovery 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.) _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs