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