Proposal for Modularizing Auth 2.0 Discovery

[Gabe Wachob]

I'm trying to follow this while at ETEL - not all of us can keep up with
this list on a minute-by-minute basis ;-)

Here's a proposal for a modular OpenID Discovery Spec, which I'll volunteer
to help edit since I am responsible for the XRI resolution spec and the XRDS
document format.

Basically, the Discovery Spec would specify that for any identifier scheme
to work with OpenID, it MUST define a way of being constructed into an HTTP
URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there
are other ways of resolving it, then implementations MAY use those other
methods of resolution ("native resolution", if you will). In essence, this
is a requirement for HTTP gateway(s) to whatever resolution infrastructure
exists today. 

This is exactly what we do with XRIs -- http://xri{.domain*}/<xri>?<some
stuff> is the form of the HTTP URL and it gets back the XRDS you need.
Implementations can also do native XRI resolution (which is a series of HTTP
requests) - but they are not required to (there will be advantages to doing
this in the future, but implementations won't be required to do native
resolution). 

Of course, it's pretty much a null-op for HTTP URIs, except that there's a
fallback for doing HTML-based discovery. 

---

I'd also support some way of making the specs for XRDS easier to comprehend
for non-XRI developers. In particular, a profile for XRDS which says which
elements are important for the common functions of OpenID. 

	-Gabe