RFC: Final outstanding issues with the OpenID 2.0 Authenticationspecification

[Claus Färber]

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