<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [OpenID] OpenID Extension to handle Emails Addresses?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>The Internet has an identifier for users - it is their email address. Trying to tech users to use anything else is pointless.<BR>
<BR>
As far as I am concerned, we have a hierarchy of usability interests here:<BR>
<BR>
Users:<BR>
&nbsp;&nbsp;&nbsp; They come first, their needs are paramount and trump all others.<BR>
<BR>
Authentication consumers:<BR>
&nbsp;&nbsp;&nbsp; They come next, make admin as easy as possible, but not if it is going to hurt users. We can expect an auth consumer to have a properly configured DNS server or fix their server if broken.<BR>
<BR>
Identity providers:<BR>
&nbsp;&nbsp;&nbsp; This is a serious business. I don't consider it necessary to make barriers to entry any lower than they currently are for administering a mail server.<BR>
<BR>
<BR>
At the moment the URL centric spec seems to have this hierarchy stood on its head. In order to make matters easy for authentication providers the user is expected to futz with URLs. I have a dozen blogs, I have never considered them to be part of my core identity. They are attributes, not my name.<BR>
<BR>
<BR>
So we have an identifier, alice@example.com, how do we resolve it?<BR>
<BR>
Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record.<BR>
<BR>
The simplest discovery mechanism then is:<BR>
<BR>
_openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid.example.com<BR>
<BR>
<BR>
or for fault tolerance:<BR>
<BR>
_openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid1.example.com<BR>
_openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid2.example.com<BR>
<BR>
or we can redirect to a third party:<BR>
<BR>
_openid.example.com&nbsp;&nbsp; PTR pip.verisignlabs.com<BR>
<BR>
Any competent network admin can configure SRV records using any of the mainstream DNS servers that have come out in the past 8 years. Windows 2000 uses SRV as a core service.<BR>
<BR>
There is no need for users to know this is going on, the only point where the SRC is required is that the identity server has to advertise the service and the authentication consumer app has to be able to read it.<BR>
<BR>
<BR>
<BR>
OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well.<BR>
<BR>
We can do this with a policy declaration:<BR>
<BR>
_openid.example.com TXT &quot;v=openid openid saml&quot;<BR>
_openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid1.example.com<BR>
_openid.example.com&nbsp;&nbsp; SRV 1 100 80 openid2.example.com<BR>
_saml.example.com&nbsp;&nbsp; SRV 1 100 80 saml1.example.com<BR>
_saml.example.com&nbsp;&nbsp; SRV 1 100 80 saml2.example.com<BR>
<BR>
<BR>
We don't need to just stop at establishing identity either. We can use this as a means of deploying the type of exotic authentication protocols that Stefan Brands and myself have developed which allow for anonymous authorization without authentication.<BR>
<BR>
<BR>
Someone is going to do federated auth this way sooner or later. It is the obvious way to do it that is consistent with the Internet architecture.<BR>
<BR>
The only real arguable point in what I wrote is that I do not have solid data on how users will react. It is my hypothesis that they will find an email address easier than a URL. If folk want to argue that point lets test it out.<BR>
<BR>
The main obstacle to change here would be the effect on the legacy base. We would need to get the identity providers to upgrade (easy) and the web sites to upgrade (harder) and there would have to be some sort of change over period that we would need to think through.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: specs-bounces@openid.net on behalf of David Fuelling<BR>
Sent: Thu 10/30/2008 12:20 PM<BR>
To: Martin Atkins<BR>
Cc: specs@openid.net; OpenID List<BR>
Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?<BR>
<BR>
On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins &lt;mart@degeneration.co.uk&gt;wrote:<BR>
<BR>
&gt; David Fuelling wrote:<BR>
&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; I would even entertain the notion of the OpenID extension doing DNS lookup<BR>
&gt;&gt; first, then EAUT, though I need to think more on the topic.&nbsp; Alternatively,<BR>
&gt;&gt; maybe we make DNS optional.<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt; At this point I'll throw in my more recent post about why DNS must be<BR>
&gt; supported and must be the primary mode, with others as fallback:<BR>
&gt;<BR>
&gt; <A HREF="http://www.apparently.me.uk/18285.html">http://www.apparently.me.uk/18285.html</A><BR>
&gt;<BR>
&gt;<BR>
Very interesting points in your blog post!!&nbsp; It has me wondering the<BR>
following questions:<BR>
<BR>
<BR>
&nbsp;&nbsp; 1. The arguments about using DNS could apply to OpenID in general.<BR>
&nbsp;&nbsp; However, OpenID doesn't do anything with DNS.&nbsp; Why is this?&nbsp; What were the<BR>
&nbsp;&nbsp; compelling reasons to not use DNS with OpenID?&nbsp; Is there an FAQ page<BR>
&nbsp;&nbsp; somewhere about that?&nbsp; I have only vague recollections on the topic.<BR>
&nbsp;&nbsp; 2. Do some of the larger email providers have an opinion on the mechanism<BR>
&nbsp;&nbsp; used for &quot;Discovery&quot; in the email case?&nbsp; For instance, would<BR>
&nbsp;&nbsp; Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based<BR>
&nbsp;&nbsp; discovery be consulted first?&nbsp; Do they even care?<BR>
<BR>
<BR>
<BR>
&gt; However, I wouldn't necessarily object to putting the *EAUT* information<BR>
&gt;&nbsp; in the DNS rather than the OpenID information directly. The two things I<BR>
&gt; care most about at this point are:<BR>
&gt;<BR>
&gt;&nbsp; * DNS must be consulted first, for the reasons I go into in that post.<BR>
&gt;&nbsp; * In the case where an email address is the claimed_identifier, the OpenID<BR>
&gt; request must have openid.identity set to <A HREF="mailto:theemailaddress">mailto:theemailaddress</A>, not the<BR>
&gt; mapped HTTP identifer. (In other words, this is an extension to OpenID<BR>
&gt; *Discovery*; the rest of the protocol is unchanged.)<BR>
<BR>
<BR>
What if the user actually wants their URL to be the claimed identifier?<BR>
Would you be open to that?<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>