how different is OpenID from SXIP?

[Dag Arneson]

I personally like how I can choose to use my own url for OpenID.  This 
means that if I own a URL I can use it to identify me even as the 
services I use change.  Although I can use dag.myopenid.com, which is 
not bad at all to type in in the first place, I can also use my personal 
domain rorek.org, which points to the same OpenID server.  Many places I 
go on the internet and post things I am happy to say, "This is really, 
me, the one and only Dag Rorek Arneson". And if for some reason I want 
to change my IDP, or add a fallback IDP, all I have to do is change the 
magic at my URL.

If I want a new persona, I register a new account on myopenid site, say 
gad.myopenid.com, and presto.  Save that the new account name is the 
reverse of my name, there's nothing that links the two personas.

With the SXIP way of doing things, I depend on my homesite for 
everything, and I am suddenly an entirely different person if I choose 
to use a new homesite.  In exchange, I can wait until I get to my 
homesite to decide if I want to be dag or gad on this RP, instead of 
simply entering the address for the appropriate persona when I am 
prompted on the RP.  Since most everyone who does openid login uses 
"openid_url" as the name of the field, I should have auto completion for 
the field and so I don't have to type in the whole thing every time.

> Well, now the user has uniquely identified themselves with one of a  
> small number of URLs that they can remember to type in. Are we really  
> that much further along then passwords?

Yes, this is precisely the goal.  We have a secure way of positively 
linking a browser session with a persona specified by a URL.  Provided 
that their account on their openid server is secure, nobody else can 
successfully assert that they own the URL, and thus they are the same 
person that logged in with that URL before.

> [1] also, if the email is pushed to the RP instead of being pulled,  the 
> Homesite can generate a unique email just for that RP, so that  the RP 
> does not have a triangulating identifier, and also the user  can kill 
> the unique email if it is abused

It's not necessary to push to gain this benefit.  In fact, claims like 
this were the source of my confusion regarding the definition of push. 
It is sufficient for the user to be able to change the data that is 
being sent in response to the request by the RP.