[OpenID] Applying the XRI synonym mechanism to OpenID/Yadis

[andy.dale at ootao.com]

I agree 100% that this is an approach that is worth exploring. Not only 
does it solve openID url synonym and portability problems it also, IMHO, 
will simplify the OpenID specs. Today there are different XRDS processing 
rules if the XRDS was derived from an i-name or from a URL I think this is 
an unnecessary complication. 


Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale
http://xri.net/=andy.dale

***************************************************************************
If you don't have an i-name yet use this link to visit one of our partners 
and buy one:

   http://www.ezibroker.net/partners.html

***************************************************************************




Martin Atkins <mart at degeneration.co.uk> 
Sent by: general-bounces at openid.net
01/18/2007 12:15 PM

To
general at openid.net
cc

Subject
[OpenID] Applying the XRI synonym mechanism to OpenID/Yadis







Hi all,

One thing I've been pondering recently is the issue of identifier 
synonyms as we've discussed on several previous occasions.

XRI already offers a solution to this, so I'm wondering if we can borrow 
from XRI's mechanism either fully or partially. The goal as I see it is 
to map an arbitrary number of "display identifiers" to a single 
canonical "key" identifier; in the XRI world the former are generally 
i-names and the latter are usually i-numbers. In OpenID land they are 
all just identifier URLs.

My understanding of the XRI mechanism is incomplete, so first allow me 
to throw out what I currently understand and hopefully Drummond or 
someone else can fill in the gaps for me or correct me as necessary:

When you resolve an XRI, you ultimately end up with an XRDS document[1]. 
Inside this document is, amongst other things, a <CanonicalID> element 
which gives the i-number that the display i-name represents. Multiple 
i-names can point at a single i-number, and these i-names are known as 
"synonyms".

When processing an OpenID login with an XRI, the endpoint is found via 
XRI resolution instead of OpenID or Yadis discovery. In addition to 
regular OpenID authentication, the RP must perform an additional step to 
verify that the nominated canonical i-number agrees that it can be 
represented by the given i-name. I'm not sure of the specifics of how 
this step is implemented beyond the fact that it must be to avoid any 
user claiming any arbitrary i-number.

So can we apply this to OpenID? Here are some initial thoughts/questions:

  * The CanonicalID element in the XRD contains a URI, so there's no 
syntactic reason why we can't throw http: or https: URIs in there 
instead of xri: ones and include it in Yadis XRD responses.

  * The main sticking point is whether we can apply the 
"synonym-checking" mechanism employed for XRI to validate OpenID 
URL-based synonyms.

  * We must consider the performance implications of adding this 
additional verification step to the login process.

  * Since OpenID URLs are volatile and re-assignable, is it safe to 
substitute them for i-numbers as used in the XRI mechanism? In 
particular, what happens if the provider of my canonical identifier goes 
away? Can I switch to a different canonical identifier without losing 
all of my accounts, or are we just re-creating the identifier assignment 
problem with a few more layers of abstraction?

  * Can I use my XRI i-number as the CanonicalID for an OpenID 
identifier? (i.e. can we inter-breed identifiers?)

  * Can I take my several existing distinct identifers, all of which 
I've previously used, and retroactively decide to make them synonyms? 
What happens to my existing accounts on various sites?

I don't claim to have all (any?) of the answers, but I do think this is 
an important topic to discuss, so, um... discuss?


-----------------

[1] You also fetch an XRDS document when performing Yadis discovery.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070118/81354f3a/attachment-0002.htm>