RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Don MacAskill]

+1 for leaving our XRI and Yadis.

Claus Färber wrote:
> Josh Hoyt schrieb:
>> On 5/17/07, Dmitry Shechtman <damnian at gmail.com> wrote:
>>> There has been a simplification suggestion floating around since long ago:
>>> resolve i-names via http[s]://xri.net/.
>> -1. If XRI is to be included, it should be done the way that it's
>> intended. One possible solution that would address this problem as
>> well as the unfinished XRI specification is to split out Yadis and XRI
>> discovery out from the OpenID Authentication spec and into separate
>> documents. That way, they could wait until the XRI specs are done and
>> the OpenID spec will be shorter and easier to understand.
> 
> +1 for leaving out XRI
> 
> XRI adds too much complexity without any real benefit.
> 
> Well, i-numbers _do_ provide persistence, which is something OpenID does 
> not have. However, Relying Parties can't rely on it as most users will 
> use HTTP-based OpenID identifiers.
> If persistence is a concern (and it may be for some Relying Parties), 
> then there should be an OpenID extension for it and implementers should 
> only have to implement said extension.
> Further, XRI-based OpenID identifiers only provide persistence by giving 
> up one of the goals of OpenID: decentrality. (An OpenID extension could 
> provide persistence and yet retain decentrality by using the public keys 
> for asymmetric encryption as a persistent or semi-persistent token.)
> 
> Of course, there's no reason why <http://xri.net/=foo> could not be a 
> OpenID URI just like any other HTTP URI. But the complexity of having 
> XRI-based identifiers used with OpenID should reside with the folks who 
> run the XRI gateway (one software product), not those who implement 
> Relying Parties (several software products).
> 
> Claus
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>