<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">David,<div><br></div><div>I think it comes down to deciding what our abstract identity model for openID is and proceeding from there.</div><div><br></div><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.</div><div><br></div><div>The two identifier types also have different approaches to identifier recycling, and portability.</div><div><br></div><div>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><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>2. Are we going to support identifier portability?</div><div>3. Are we going to decouple the display ID from the primary key?</div><div><br></div><div>John B.</div><div><br><div><div>On 7-Jun-09, at 11:13 AM, David Fuelling wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Replies inline...<br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 10:03 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>I am referring to identifier abstraction to make certain that we clearly understand the need for a primary key vs a display identifier.</div><div></div></div></blockquote><div><br>+1. This is a very valid issue. <br> <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>We ran into this with XRI and the presumption that the claimed_id is what is displayed for the user.</div> <div><br></div><div>With XMPP identifiers you may have multiple identifiers that resolve to the same XRD and hence have the same claimed_id but may want your input identifier represented in some way.</div><div><br></div><div> Perhaps we need more that one identifier at the API layer.</div><div></div></div></blockquote><div><br>+1. <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>What I am saying is that if the core spec assumes URI then there will be a built in bias as there is now.</div><div></div></div></blockquote><div><br>Wondering _how_ you would describe an OpenID Identifier if it's not a URI...would you specify string-text (with x,y, z, etc as allowed characters)? Or anything goes?<br> <br>The only reason I ask is that is seems most Identifiers (in the generic sense) are URI's with a scheme: (http://; xri://; ldap://; mailto:; uri://; etc).<br><br>Are JID's not URI'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></div><div>We need to consider how provider portability could be achieved or at-least not be precluded by core design choices.</div><div></div></div></blockquote><div><br>+1<br><br> </div></div><br></blockquote></div><br></div></body></html>