<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><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><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>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>