Modularizing Auth 2.0 Discovery

[Drummond Reed]

I've always been supportive of breaking out OpenID Discovery into a separate
spec. I wouldn't break it out into separate specs, however, because
discovery for any OpenID identifier has have much more in common than they
have different. For example, they all need to explain the relationship of
the identifier being resolve to an XRDS document and the metadata needed to
access other OpenID services.

So I'm make the OpenID Discovery spec "modular" rather than breaking it out
into separate specs.

It also very nicely fits the OpenID layer model, i.e., one specification
(one might argue the foundational spec) for OpenID Discovery -- the layer
that maps an OpenID identifier to the metadata needed to access an OpenID
service -- followed by a specification for OpenID Authentication, and then
other specs from there.

In fact, I'm excited enough about this approach that I'll volunteer to be
one of the editors for OpenID Discovery. I can specifically handle
coordination between the OpenID Discovery spec and the XRDS definitions in
the XRI Resolution spec at OASIS.

=Drummond 

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Recordon, David
Sent: Wednesday, February 28, 2007 11:26 AM
To: Martin Atkins; specs at openid.net
Subject: RE: Modularizing Auth 2.0 Discovery

+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
_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs