Draft OpenID v.Next Discovery working group charter

Phillip Hallam-Baker hallam at gmail.com
Fri Apr 16 16:43:10 UTC 2010

The argument that security is a chain is a fallacy. Unfortunately
Brice tends to push it a lot despite being dead wrong.

A chain breaks at its weakest link, that is why serious security
schemes are not developed as chains.

So for example, the KGB requirements for handling classified
information was that it had to be protected by two separate
technologies that each provided 100% protection. So they didn't just
use encryption, they also used tempest shielding and put a radiation
source and an e/m noise generator into the enclosures. As a result
they killed more than a few cipher clerks.

If you have a standard A-record resolution mechanism you have a chain

openid.example.com A

But with an SRV record, you can specify a fault tolerant mesh:

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

The three servers should get 40%, 40% and 20% of the load
respectively. We can also specify back up servers to be tried if the
first rank servers are unavailable.

_openid.example.com SRV  1 100 80 openid1.example.com
_openid.example.com SRV  1 100 80 openid2.example.com
_openid.example.com SRV  1 50 80 openid3.example.com
_openid.example.com SRV  2 1 80 openid_last.example.com

The client should first try each of openid1, openid2, openid3 and if
none of those work try openid_last.

The DNS protocol itself has built in redundancy. DNS name holders are
REQUIRED to have at least two name servers and may in practice have an
unlimited number if they employ ANYCAST. There are at least five
providers of DNS service that offer 99.999% uptime and one that
commits to 99.9999% but has an infrastructure built out to deliver
99.999999% unless a war should intervene.

If you have redundancy on redundancy on redundancy you can meet very
high levels of uptime.

What we do once we get to the server could be handled in either of two ways:

1) Have another DNS record to give the URI stem - this is what NAPTR
was intended to do

2) Consider the openid over HTTP protocol to be a first rank protocol
in its own rank and thus eligible to control the entire URI space for
that server.

The second makes for a lot cleaner implementation and administration.

Remember that the objective of standards making is to eliminate
choices that are not useful.

If I am working in Apache or IIS (or I would guess any other major Web
server) I can easily create as many virtual servers as I like where
each server is only distinguished by the host name. URIs are a
mechanism for identifying resources on a HTTP service that is
supporting multiple resources. If we are using SRV for web service
discovery we should have precisely one resource per host name. So we
don't necessarily need an endpoint distinguisher.

Unless we want to use HTTP caching (and we probably want to make sure
we turn it off rather than want to use it), the URI field can simply
be ignored. Or we can require it to be the subject uri of the query.

My preference would be to specify the URI stem as the protocol name
and version number for the Web service since that is what we would
likely want to separate on.

So imagine that I have three boxes that I am going to configure to
support a set of six different Web Services using this discovery
mechanism. Instead of naming by boxes openid1, openid2, openid3, I
name the boxes ws1, ws2, w3 and set up the SRV records for all of my

If the client is trying to connect to the openid service and is
speaking version 3.2 on box3 it would use the following HTTP header:

Host: box3.example.com

On Fri, Apr 16, 2010 at 11:06 AM, SitG Admin
<sysadmin at shadowsinthegarden.com> 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.
> -Shade
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,

More information about the specs mailing list