Draft OpenID v.Next Discovery working group charter
john.bradley at wingaa.com
Fri Apr 16 16:40:51 UTC 2010
One of the reasons the DNS proposal was originally rejected by LRDD as I understand it, is that SRV alone is not sufficient to eliminate the need for a well known location. Unless we invent a new meta-data service that needs to run on a separate port from the web server.
The SRV record allows you to delegate from one domain to another but that alone is not super useful.
The more likely approach was to use NAPTR to point to a http: URI where the host-meta XRD could be retrieved.
NAPTR could also directly contain the mapping regex to turn a email address or other identifier into a URI to retrieve the desired meta-data.
It was felt that without a mechanism to sign the regex doing the template directly in DNS posed security risks.
That leaves using NAPTR to point to a host meta for each protocol. The host -meta can be signed to assure integrity.
Given that the premise of LRDD was to build of of the link infrastructure, using the link header to point to a resources meta-data needs to be supported.
Given a lack of support for NAPTR it was felt that while being theoretically better, it could not be be relied on to be universally available. That and that it didn't fit the link model they had in mind a well.
This left the well known location option as the one that people wold have the easiest time supporting.
There were other options considered as well as I recall. Most of them are listed on Eran's blog, and I think discussed on the openid list as well at the time.
Could LRDD support NAPTR, yes I think it could.
There is however a tradeoff in complexity if every time you want the meta-data for a URI you need to try three different ways.
I think there is likely a debate that needs to take place around what order openID should look for the meta-data for http: URL.
Should the person controlling the URL be allowed to override the sites mapping by adding headers to there page?
I am sympathetic to the DNS approach however unless it can completely eliminate the need for a well known location I don't think the community is likely to accept it.
We could do something entirely in DNS if DNSSEC were widely available. However I don't see that happening anytime soon.
As long as we are relying on SSL for security having a meta-data file for a DNS authority that you retrieve from a well-known location via https: is perhaps the best compromise.
I understand that will not make everyone happy.
People with other proposals should document them and submit them to the Work Group.
On 2010-04-16, at 11:06 AM, SitG Admin wrote:
>> Let's look at the complete SRV record:
>> _openid._tcp IN SRV 0 0 8080 openid.example.com.
>> We have a machine name, but what is the URL to the endpoint for logging in?
>> What is the user's OpenID URI?
> I think Phillip is proposing a discovery chain - more opportunities for other parties to step in (at their layer) and take control, more points of failure if vulnerabilities are discovered in each protocol - and to be fair, DNS is *already* such a layer. OpenID relies on it.
> specs mailing list
> specs at lists.openid.net
More information about the specs