Modularizing Auth 2.0 Discovery

Recordon, David drecordon at verisign.com
Wed Feb 28 19:26:05 UTC 2007


+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: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On
Behalf Of Martin Atkins
Sent: Wednesday, February 28, 2007 10:44 AM
To: specs at 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 at openid.net
http://openid.net/mailman/listinfo/specs



More information about the specs mailing list