<HTML dir=ltr><HEAD><TITLE>RE: [OpenID] OpenID Extension to handle Emails Addresses?</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6001.18148" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText45479 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Maybe because the DNS naming system is the Internet for all practical purposes.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>Think about the telephone system. What parts of the system today have remained the same for a century? Pretty much everything has changed, the telephones, the switches, the wires, even the assignment of the&nbsp;numbers themselves.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>But the basic interface of 'dial number X to talk to Y' has remained constant.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>The DNS is the equivalent infrastructure for the Internet. Everything else will change over time. We are currently changing the packet protocol from IPv4 to IPv6 and many parts of the Web are not on the Internet at all, the are URLs embedded in print media, in CD Rom and such.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>The implementation will change, you might even see new TLDs replace .com or the rise of <A href="http://www.microsoft">www.microsoft</A> or whatever. But every such change must and will be incremental. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>I am not quite sure to interpret the last paragraph. The term 'walled garden' is a loaded one. It is used to refer to the carrier model where the carrier decides where the consumer is allowed to go. I don't think that is what end users want.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>But what they might well want is a model where they get to define the fences themselves. So they can fence off their financial browser from the anonymizing Web browser they use to view folk dancing Web sites and the like.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>Its really a matter of who gets to decide where the fence goes...</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Peter Williams [mailto:pwilliams@rapattoni.com]<BR><B>Sent:</B> Thu 10/30/2008 3:09 PM<BR><B>To:</B> Martin Atkins; Hallam-Baker, Phillip<BR><B>Cc:</B> specs@openid.net; OpenID List<BR><B>Subject:</B> RE: [OpenID] OpenID Extension to handle Emails Addresses?<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Verisign wants validation of id related to dns (and dnssec).<BR><BR>Wonder why?<BR><BR>As long as an op can verify the dns assuraces and communciate them to the rp as a certificate (re)minted by itself, there is a compromise to be had here.<BR><BR>Perhaps the op adds the domain to its own walled garden dns server, does its own dnssec, and lets its consumers bind over an mpls vpn and virual routing domain to its dns service.. That would be consistent with the openid model: as the rp app chooses the dns access point, not the op.<BR><BR>-----Original Message-----<BR>From: Martin Atkins &lt;mart@degeneration.co.uk&gt;<BR>Sent: Thursday, October 30, 2008 2:51 PM<BR>To: Hallam-Baker, Phillip &lt;pbaker@verisign.com&gt;<BR>Cc: specs@openid.net &lt;specs@openid.net&gt;; OpenID List &lt;general@openid.net&gt;<BR>Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?<BR><BR><BR>Hallam-Baker, Phillip wrote:<BR>&gt;<BR>&gt; Well we already have a specification for that, it is the core<BR>&gt; architecture of the Internet: DNS. We use the DNS SRV record for service<BR>&gt; discovery. It is what it is designed for. It provides for fault<BR>&gt; tolerance, load balancing, fall over just like an email MX record.<BR>&gt;<BR><BR>Thanks for another voice in favor of DNS. I was beginning to feel like<BR>the only one on this side of the fence. :)<BR><BR>&gt; The simplest discovery mechanism then is:<BR>&gt;<BR>&gt; _openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid.example.com<BR>&gt;<BR><BR>I did consider SRV, but the "return value" from OpenID discovery is not<BR>a hostname, it's a structure like this:<BR><BR>&nbsp; * Endpoint URL<BR>&nbsp; * "Final" claimed identifier (after following redirects)<BR>&nbsp; * OP-local identifier (or "delegate" in 1.1 terminology)<BR>&nbsp; * OpenID version (either 1.1 or 2.0, currently)<BR><BR>Some of these we can infer. For example, in my DNS-based proposal I just<BR>assumed that all email-based identifiers would use OpenID 2.0, because a<BR>provider's going to have to change their implementation anyway so they<BR>might as well upgrade to 2.0 while they're at it if they don't support<BR>it already.<BR><BR>I went with a TXT record with a custom serialization, despite it being<BR>technically incorrect, both so that the information required for the<BR>above structure could be represented and also so that it can be deployed<BR>on DNS providers that only allow A, CNAME, MX and TXT records to be<BR>configured. The latter is important for the delegation case, as the main<BR>&nbsp; audience for delegation is people with vanity domains.<BR><BR>&gt;<BR>&gt; OK so now lets think about market building a bit. Lets try to embrace<BR>&gt; and extend the competition. In my view the value of OpenID is not so<BR>&gt; much the protocol as the idea of an interoperable identifier. So lets<BR>&gt; try to capture the SAML and WS-* worlds as well.<BR>&gt;<BR>&gt; We can do this with a policy declaration:<BR>&gt;<BR>&gt; _openid.example.com TXT "v=openid openid saml"<BR>&gt; _openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid1.example.com<BR>&gt; _openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid2.example.com<BR>&gt; _saml.example.com&nbsp;&nbsp; SRV 1 100 80 saml1.example.com<BR>&gt; _saml.example.com&nbsp;&nbsp; SRV 1 100 80 saml2.example.com<BR>&gt;<BR><BR>And I infer from this that you're not adverse to the idea of encoding<BR>custom formats in TXT records, so hopefully you'll appreciate my approach.<BR><BR>However, if you've got an alternative proposal that's more "DNS-pure"<BR>I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd<BR>take a very convincing argument for me to get behind anything that<BR>requires something other than A, CNAME, MX and TXT records though, for<BR>the reasons stated above.<BR><BR>(In case you haven't seen it, my current strawman proposal is here:<BR>&nbsp;&nbsp;&nbsp;&nbsp; <A href="http://www.apparently.me.uk/18285.html">http://www.apparently.me.uk/18285.html</A><BR>)<BR><BR>_______________________________________________<BR>general mailing list<BR>general@openid.net<BR><A href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</A><BR></FONT></P></DIV></BODY></HTML>