[OpenID] OpenID Extension to handle Emails Addresses?

sky at crucially.net sky at crucially.net
Thu Oct 30 19:27:27 UTC 2008


I agree with using DNS. I would however suggest using TXT as a fallback from SRV.

Sent via BlackBerry by AT&T

-----Original Message-----
From: Martin Atkins <mart at degeneration.co.uk>

Date: Thu, 30 Oct 2008 11:51:12 
To: Hallam-Baker, Phillip<pbaker at verisign.com>
Cc: <specs at openid.net>; OpenID List<general at openid.net>
Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses?


Hallam-Baker, Phillip wrote:
> 
> 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.
> 

Thanks for another voice in favor of DNS. I was beginning to feel like 
the only one on this side of the fence. :)

> The simplest discovery mechanism then is:
> 
> _openid.example.com   SRV 1 100 80 openid.example.com
> 

I did consider SRV, but the "return value" from OpenID discovery is not 
a hostname, it's a structure like this:

  * Endpoint URL
  * "Final" claimed identifier (after following redirects)
  * OP-local identifier (or "delegate" in 1.1 terminology)
  * OpenID version (either 1.1 or 2.0, currently)

Some of these we can infer. For example, in my DNS-based proposal I just 
assumed that all email-based identifiers would use OpenID 2.0, because a 
provider's going to have to change their implementation anyway so they 
might as well upgrade to 2.0 while they're at it if they don't support 
it already.

I went with a TXT record with a custom serialization, despite it being 
technically incorrect, both so that the information required for the 
above structure could be represented and also so that it can be deployed 
on DNS providers that only allow A, CNAME, MX and TXT records to be 
configured. The latter is important for the delegation case, as the main 
  audience for delegation is people with vanity domains.

> 
> 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
> 

And I infer from this that you're not adverse to the idea of encoding 
custom formats in TXT records, so hopefully you'll appreciate my approach.

However, if you've got an alternative proposal that's more "DNS-pure" 
I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd 
take a very convincing argument for me to get behind anything that 
requires something other than A, CNAME, MX and TXT records though, for 
the reasons stated above.

(In case you haven't seen it, my current strawman proposal is here:
     http://www.apparently.me.uk/18285.html
)

_______________________________________________
specs mailing list
specs at openid.net
http://openid.net/mailman/listinfo/specs


More information about the specs mailing list