<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Inline<div><br><div><div>On 7-Jun-09, at 4:01 PM, David Fuelling wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">John,<br><br>I'm wondering if XRD might take care of some of the issues you outlined....see my replies inline.<br><br>Thanks!<br><br>On Sun, Jun 7, 2009 at 6:54 PM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div>The conflict between URLs and XRI has more to do with having multiple names that resolve to a single claimed_id where with URLs there is a one to one relationship. I believe it was that impedance mismatch more than library complexity that prevented people from seeing any advantage to XRI. The two identifier types also have different approaches to identifier recycling, and portability. We need a single model and then fit the identifiers to it rather than trying to adapt the core to the identifiers in a piecemeal fashion.</div> <div></div></div></blockquote><div><br>Do you think using XRD might overcome this issue with respect to URL's? For example, XRD defines a canonical-id, and allows for "many" aliases. It would appear that a person could have a single, "canonical-url", and then have multiple other vanity urls. When XRD Discovery is performed on the vanity URL, the XRD document that is returned could list the canonical URL as the "canonical URL" in the document. It would seem to be a way to simulate many-to-many using URL's. <br> </div></div></blockquote><div><br></div>It might if the core spec supports the notion. It doesn't really at the moment. </div><div><br></div><div>The spec currently takes the CID from the XRDS (will be Subject in XRD) and sends that in openid.claimed_id and openid.identity. </div><div>This removes the ability for the OP to know what the user input at the RP.</div><div><br></div><div>The OP authenticates the CID and returns a iNumber in the assertion rather than the users iName for XRI.</div><div><br></div><div>In the email case the user would input there email or XMPP address and the discovery process would as a result of discovery send the XRD subject to the OP for authentication.</div><div><br></div><div>The RP gets back an assertion with some URL as the identifier that it then publishes as the users openID in posts etc.</div><div><br></div><div>The core openID protocol is tied to the notion that the openID is a URL that retrieves a resource that describes the user (Blog) and that that URL + a generational fragment is the primary key for the RP.</div><div><br></div><div>That the RP can remove the fragment and have a display ID for the user that makes some sense.</div><div><br></div><div>That broke down for XRI, as it may for email and other ID types.</div><div><br></div><div>Yes I think XRD is a big part of the answer, however the information needs to find its way to the consuming applications.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div><br></div><div>The first questions we need to answer:</div><div>1. Are we going to support many to one relationships, or enforce a one to one relationship?</div> </div></blockquote><div><br>See above.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style=""><div></div><div>2. Are we going to support identifier portability?</div> </div></blockquote><div><br>In the context of URL's, what does it look like to support identifier portability? <br><br>At first I immediately thought of a vanity domain, which I could easily "port" to a different OP. However, I assume you're talking about the idea where I have an "identity" at google, using a google domain, and then I want to move this identity over to Facebook. (?). With XRI (and i-numbers) this might be trivial -- I just keep the same i-number...but in a URL-world, this isn't really possible today. <br> <br>However, with XRD it might be enabled by simply having Google forward any XRD requests for my google-id over to Facebook, so anybody requesting my "<a href="http://david.google.com">david.google.com</a>" XRD get it, and notice that the canonical id is now "<a href="http://david.facebook.com">david.facebook.com</a>". I'm not sure what the ramifications of a changing "canonical-id" are (sort of seems like an oxy-moron) but it seems like it could work to have the canonical-id be multi-dimensional -- i.e., it might change over time. <br> <br>Of course, Google/Facebook would have to play along with this type of thing, and not recycle my identifier once I "move on". <br></div></div></blockquote><div><br></div>XRI was designed for portability from the beginning, it will be harder to achieve with other identifier types. </div><div><br></div><div>Though I can see the value in a service that hosts XRD and provides a stable XRD subject over time. A user could then point vendor provided ID's at that XRD and that XRD could in turn point to any number of services at any number of providers.</div><div><br></div><div>Using XRD's to publish public keys as Andrew Arnott mentioned a couple of days a go is also a possibility that could allow a RP to recognize multiple XRD as belonging to the same entity. </div><div><br></div><div>I don't think we should throw up our hands and say it is impossible.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style=""><div></div><div>3. Are we going to decouple the display ID from the primary key?</div><div><br></div></div></blockquote></div><br>Does this need to be specified in the core spec? First of all, there's one arguement to be made that OP's and RP's should have this authority (to display whatever they want for you). However, there's a couter-arguement that says the user should determine what should be displayed. <br> <br></blockquote><div>What I am referring to by display identifier is the normalized input identifier the user input or some other identifier that provably belongs to the user, without requiring that to be the claimed_id/primary key for the RP. I think this needs to be part of the core. </div><div><br></div><blockquote type="cite">Regardless of which side one takes in this arguement, I think this should simply be specified as part of AX. It's really not part of a core authentication protocol. Instead, "displayName" is really an attribute that I'd like to define, potentially even on a case-by-case basis.<br> <br></blockquote>A user nicname or other ID that is not provably globally unique for the user should be part of AX.</div><div><br></div><div>John B.</div><div><br></div><br></div></body></html>