[OpenID] OpenID Extension to handle Emails Addresses?

Hallam-Baker, Phillip pbaker at verisign.com
Thu Oct 30 18:32:49 UTC 2008

The Internet has an identifier for users - it is their email address. Trying to tech users to use anything else is pointless.

As far as I am concerned, we have a hierarchy of usability interests here:

    They come first, their needs are paramount and trump all others.

Authentication consumers: 
    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. 

Identity providers:
    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. 

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. 

So we have an identifier, alice at example.com, how do we resolve it?

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.

The simplest discovery mechanism then is:

_openid.example.com   SRV 1 100 80 openid.example.com

or for fault tolerance:

_openid.example.com   SRV 1 100 80 openid1.example.com
_openid.example.com   SRV 1 100 80 openid2.example.com

or we can redirect to a third party:

_openid.example.com   PTR pip.verisignlabs.com

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.

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. 

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.

We can do this with a policy declaration:

_openid.example.com TXT "v=openid openid saml"
_openid.example.com   SRV 1 100 80 openid1.example.com
_openid.example.com   SRV 1 100 80 openid2.example.com
_saml.example.com   SRV 1 100 80 saml1.example.com
_saml.example.com   SRV 1 100 80 saml2.example.com

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.

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. 

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. 

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.

-----Original Message-----
From: specs-bounces at openid.net on behalf of David Fuelling
Sent: Thu 10/30/2008 12:20 PM
To: Martin Atkins
Cc: specs at openid.net; OpenID List
Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?
On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> David Fuelling wrote:
>> I would even entertain the notion of the OpenID extension doing DNS lookup
>> first, then EAUT, though I need to think more on the topic.  Alternatively,
>> maybe we make DNS optional.
> At this point I'll throw in my more recent post about why DNS must be
> supported and must be the primary mode, with others as fallback:
> http://www.apparently.me.uk/18285.html
Very interesting points in your blog post!!  It has me wondering the
following questions:

   1. The arguments about using DNS could apply to OpenID in general.
   However, OpenID doesn't do anything with DNS.  Why is this?  What were the
   compelling reasons to not use DNS with OpenID?  Is there an FAQ page
   somewhere about that?  I have only vague recollections on the topic.
   2. Do some of the larger email providers have an opinion on the mechanism
   used for "Discovery" in the email case?  For instance, would
   Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based
   discovery be consulted first?  Do they even care?

> However, I wouldn't necessarily object to putting the *EAUT* information
>  in the DNS rather than the OpenID information directly. The two things I
> care most about at this point are:
>  * DNS must be consulted first, for the reasons I go into in that post.
>  * In the case where an email address is the claimed_identifier, the OpenID
> request must have openid.identity set to mailto:theemailaddress, not the
> mapped HTTP identifer. (In other words, this is an extension to OpenID
> *Discovery*; the rest of the protocol is unchanged.)

What if the user actually wants their URL to be the claimed identifier?
Would you be open to that?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081030/0768fcce/attachment-0002.htm>

More information about the specs mailing list