OpenID Email Discovery

Hallam-Baker, Phillip pbaker at verisign.com
Fri Jan 4 15:31:10 UTC 2008


This thread is dipping into a proposal I recently made at the IETF bar-BOF on leveraged authentication. I also make the same set of points in my book, The dotCrime Manifesto: How to Stop Internet Crime, which is officially to be published on Monday but is actually shipping from Amazon from today.
 
 
If the user form of the identifier is peter.davis at neustar.biz I don't see where the need for regular expressions come from. It is probably convenient to map the user form of the identifier onto a machine friendly URI form but that can and should be a constant mapping, either mailto:peter.davis at neustar.biz or user:peter.davis at neustar.biz if we want to get away from the idea that these are necessarily mail addresses or urn:rfc822:neustar.biz:peter.davis if we want to make it URN-ish.
 
Using more mechanism than is necessary to solve the task is a design error in my view. That might be because of my background in formal methods where the cost of verifying mechanism is prohibitive but it is a pretty general view amongst engineers.
 
But lets consider a differential deployment case here:
 
Objective map peter.davis at neustar.biz to an authoritative authentication service. 
 
Case1: with SRV
 
DNS configuration
_openid.neustar.biz SRV x x x openid1.neustar.biz
_openid.neustar.biz SRV x x x openid2.neustar.biz
 
Web Service configuration
http://openid1.neustar.biz/[constant]peter.davis
Where [constant] is some constant specified by the protocol, possibly the null string, possibly ?id=, but cannot change according to the querry.
 
Constraints: deployer must be able to configure SRV records, deployer must be able to configure the Web server to which the query is directed to support the Web Service at the constant service address.
 
 
Case2: with NAPTR
 
DNS configuration
_openid.neustar.biz NAPTR x x x x http://openid1.neustar.biz/constant/
_openid.neustar.biz NAPTR x x x x http://openid1.neustar.biz/constant/
 
Web Service configuration
http://openid1.neustar.biz/constant/peter.davis
 
Constraints: deployer must be able to configure NAPTR records, this excludes Windows DNS, deployer must be able to configure the Web server to which the query is directed to support the Web Service but has more flexibility in the location of the service address.
 
 
I agree that SRV is somewhat more restrictive than one would like. NAPTR goes the other way. Regular Expressions are only one step away in complexity from a full Turing machine. I do not see any advantage of NAPTR over SRV for this particular application. I do not think that there are many parties likely to deploy leveraged authentication that are likely to have the ability to deploy NAPTR records on their DNS but lack the ability to create a dedicated domain name and virtual server for the authentication service.
 
Another reason I like simplicty is that it is much less likely to have unfortunate IPR encumberances. I have been burned with GIF and JPEG. I have had people sue my employer over the most ridiculous patent claims you can imagine. Even though NAPTR was originally a VeriSign proposal and we performed due dilligence in submitting it the the IETF you never know what loathesome worms are going to crawl out of the woodwork. The idea of sticking regular expressions in the DNS is a powerful one. I will use it if I have to but given the existing IPR claims in the space I would only do so if 1) I considered it absolutely necessary 2) I received an immediate and irrevocable commitment that certain parties would not assert rights to the result. 
 
SRV has been around long enough that I am as confident as I can ever be that it is not encumbered. It was first proposed a very long time ago now. It is simple enough and incremental enough on the mx record that we could almost certainly win the claim that the mechanism itself is obvious to a person of ordinary skill in the field.
 
 
There is a use case where I do think that Eran's TXT approach is relevant however: to indicate a choice of authentication service protocols. So for example, imagine that we have a site that offers OpenID, SAML, WS-* authentication services, plus lets say Kerberos thrown in. 
 
;DNS configuration advertising protocol options
_authenticaton.neustar.biz TXT "t=_authentication OpenID SAML WSAuth Kerberos"
 
;Entry for Kerberos, there is an extended policy specification
_kerberos.neustar.biz        TXT "t=_kerberos"
                                 "policy=http://policy.neustar.biz/kerberos"
_kerberos._tcp.neustar.biz   SRV 1 1 1 kerberos1.neustar.biz
_kerberos._tcp.neustar.biz   SRV 1 1 1 kerberos2.neustar.biz
 
And so on for each of the other authentication protocols supported.
 
This is where I think that the cross industry debate over leveraged identity is going to end up. We need somewhat more than SRV provides but not quite what NAPTR does. 
 
 
Now lets go back and remember that OpenID is not so much an auth protocol itself but a framework for supporting leveraged authentication. If we separate the OpenId protocol from the discovery framework the authentication protocol negotiation mechanism could then become the architecurally precise means of deploying OpenId and the ad-hoc workarround discovery mechanisms may be regarded as fixes to support legacy infrastructure, build the deployed base etc.
 
 
If we use the TXT plus SRV record approach we are able to support 100% of legacy authentication protocols and infrastructure in a manner that is compatible with 98% of the deployed DNS infrastructure or better and consistent with IETF standards. The only minor deviation here is using TXT to express the new policy records.
 
Being able to support any authentication protocol in this manner means that the proposal is potentially one that can bring together all the different efforts in the space. It adds value for SAML, Liberty, CardSpace and Higgins supporters.
 
 
________________________________

From: Peter Davis [mailto:peter.davis at neustar.biz]
Sent: Fri 04/01/2008 8:56 AM
To: Hallam-Baker, Phillip
Cc: Eran Hammer-Lahav; OpenID specs list
Subject: Re: OpenID Email Discovery



On Jan 3, 2008, at 6:03 PM, Hallam-Baker, Phillip wrote:

> NAPTR is an ietf proposed standard but there is no deployed base.

well, there certainly are deployed bases where i sit, since we have 
DNS zones in operation with well over 40M entries... most of which 
are NAPTR RR's, and many, many users of these services.

The reason i made the suggestion, however, is that the proposed 
solution (of using TXT RRs) showed examples of regx like functions 
for resolvers to post-process... which is precisely what NAPTR RRs 
were intended to provided (among other things) and that use of TXT 
RRs are being discouraged.  the SRV RR does not provide any 
facilities for regx-like answers.

=peterd




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


More information about the specs mailing list