<div class="gmail_quote">On Thu, Jun 4, 2009 at 2:09 PM, David Fuelling <span dir="ltr"><<a href="mailto:sappenin@gmail.com">sappenin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<ol><li><b>ALL OpenID 2.1 Identifiers MUST be Resolvable to XRD<br> </b>Any OpenID Identifier MUST be able to be resolved to an XRD (with XRD being the primary "discovery" mechanism supported by OpenID 2.1). Legacy discovery mechanisms from OpenID 1.0, 1.1, and 2.0 should still be supported, but would be restricted to URL's & XRI's (with EAUT possibly filling in the gap for email addresses).</li>
</ol></blockquote><div><br></div><div>This is a good framing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><ol><li><b>Start With Only 3 Required Identifiers as a Baseline<br>
</b>OpenID 2.1 should mandate that all OP's and RP's support URL, XRI, and Email-like identifiers (only because these are the most common form of identifier -- Peter, I personally don't see a lot of LDAP identifiers being thrown around today on business cards, e.g.).</li>
</ol></blockquote><div><br></div><div>-1. I'm for extracting XRI into its own extension. As it is, it's the more complicated and convoluted part of the OpenID spec — to the degree that Facebook decided to not even both implementing it. </div>
<div><br></div><div>This is leading to bad experiences in the wild — and now that we've seen what people are willing to implement — I think that the spec and protocol should be responsive to that. In this case, it matters more what people implement than what is in the spec.</div>
<div><br></div><div>The two baseline identifier types should be URLs and email addresses — two of the most common — if not THE most common — forms of identifiers on the web.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<ol><li><b>Allow for Future Identifier Support as Decided by the Community<br></b>An extension mechanism should be defined that allows the OIDF community to endorse (via extension specifications) new OpenID 2.1 Identifiers. The Jabber Foundation has done this sort of extensibility thing with decent success (not necessarily with Identifiers, but in general). </li>
</ol></blockquote><div>-1. While I support an extensibility model for additional identifier formats and types (i.e. XRI), I don't think that adding new identifiers should be mandated through community vote. That just doesn't make sense.</div>
<div><br></div><div>The point of extensibility is to allow for the protocol to serve increasingly divergent needs in the wild — and letting those real-world needs determine the destiny of the technology. </div><div><br></div>
<div>Indeed, having a tight, less complex core is something that we should aspire to — where CUTTING features should actually be something that we pursue with relish! Furthermore, it would inspire more community participation and involvement in the development of libraries — and lead to solving more interesting use cases — similar to how the OAuth community has been built out.</div>
<div><br></div><div>I don't need to belabor this point, but with a solid extensibility model, I think we can let market dynamics determine what needs to get baked into the core protocol over time.</div><div><br></div>
<div>Chris</div></div><br clear="all"><br>-- <br>Chris Messina<br>Open Web Advocate<br><br>Website: <a href="http://factoryjoe.com">http://factoryjoe.com</a><br>Blog: <a href="http://factoryjoe.com/blog">http://factoryjoe.com/blog</a><br>
Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><br><br>Diso Project: <a href="http://diso-project.org">http://diso-project.org</a><br>OpenID Foundation: <a href="http://openid.net">http://openid.net</a><br>
<br>This email is: [ ] bloggable [X] ask first [ ] private<br>