Proposal for an XRI (i-name) profile for OpenID

[Martin Atkins]

Lukas Rosenstock wrote:
> 
> In case b) there will be no openid:delegate. The server doesn't change 
> much. The only change is that when it looks up whether the given 
> openid.identity is in is database the user identifier will begin with
> xri:  instead of http:. So why enforce one delegation if only this minor
> change  in the URI is necessary?
> 

So are you going to modify LID, and SXIP, and every other URL-based
authentication system as well? Surely it's better just to build
something new *on top* of all this stuff and then your changes apply to
everyone. As I see it, it works something like this:

* User enters XRI URI
* Relying Party resolves the XRI URI to a URL and does Yadis discovery
on it. Since Yadis uses the same format as is used for XRI resolution,
this might not even be a separate step.
* Relying Party, as normal, takes a look at the available services and
selects the most appropriate for signon.
* Relying Party does auth as normal with that protocol using the Yadis
URL or the delegation URL. It tracks the URI the user originally entered
using either a mechanism exposed by the protocol (in the case of OpenID)
or with some internal state.
* On success, Relying Party says "Hey, xri://whatever!"

This can be applied equally to both OpenID and LID (and probably also
SXIP, but I don't actually know how that operates) without modifying
either. The Relying Party can implement XRI resolution as a layer on top
of whatever other protocol it wants, much like IPv4 and IPv6 nothing
about DNS.