[OpenID] Anti-XRI FUD

Bob Wyman bob at wyman.us
Wed Jan 3 16:49:49 UTC 2007


On 1/3/07, Dick Hardt <dick at sxip.com> wrote:
> i-names has the main issue that SXIP 1.0 had -- yet another
> central directory -- and the only reason we had that was
> because we did not see how to do it decentralized with
> DNS in the same way that OpenID works.

I can't help thinking about ASN.1 when reading this discussion... One
of the major objections to ASN.1 has always been the incorrect belief
that identifiers in ASN.1 binary formats must be assigned via a
hierarchical registry that had a single root. While we explained over
and over and over again that such "universal" identifiers where not
necessary -- anyone could define "application" identifiers that were
not universal -- those who opposed ASN.1 could never get it into their
heads that universal identifiers were an optional feature, chosen by
the protocol designer, rather than a requirement. Even today, decades
after the ASN.1 "battle" began (and long after many people think the
battle ended), I still hear people complain stupidly about the single
root for ASN.1 identifiers.

There were a number of things that people didn't like or understand
about ASN.1. They couldn't understand, for instance, why you would
want a self-describing generic data structure. Of course, today, folk
have learned the value and that's why we have XML... There were also
objections to the use of binary codes (especially from the Unix crowd
who had, a that time, an OS that couldn't even deal with 8-bit
characters). However, things would have been easier if we hadn't had
to deal with the confusion introduced by the means for assigning
universal identifiers. ASN.1's chances of acceptance would have been
just a little bit better if universal identifiers had been dropped
from the specification and moved to a secondary later specification
that simply identified one convention for assigning identifiers in a
useful way. The problem was, of course, that we *knew* that universal
identifiers were useful and thought that folk would eventually accept
them. We were wrong. Being wrong cost everyone (particularly end
users) a tremendous amount.

In standards work, there is always a tension between building the best
design and building a standard that is likely and easy to be accepted.
Standards like X.500, X.400, ASN.1 etc. are poster-child examples of
really wonderful designs that were impossible to get people to accept.
We poured vast amounts of effort into those specifications only to see
them rejected. Everyone would have been better off if the
specifications had focused more on what was likely to be accepted (the
path of least resistance) and less on what we thought made the "best"
system. We should have focused on the "best" that would be accepted,
not on the best we could design. A less functional system that ships
is vastly superior to a better system that lives only on paper and in
your dreams.

I believe that the most important, the most essential "feature" of any
new identity system is that it be accepted and deployed broadly while
providing a base for future enhancement. We have waited too long to
have a useful identity system... There are endless applications and
capabilities that we cannot provide to our users today because we
don't have a useful and broadly deployed identity system. I believe
that anything that interferes, even slightly, with the ability to get
a solid base system accepted should be discarded without hesitation --
particularly when it is likely that a particular pet feature could be
layered on top of the base in the future (as is the case with
i-names...).

It seems to me that i-names and the special rules for resolving XRIs
are bad for OpenID in that they provide a focal point for debate over
features of secondary importance and thus compromise the viability of
the base. It appears that insistence on the "nice" features of i-names
today may make it harder for us to deploy the minimum set of features
that we "must have." This is not good.

bob wyman



More information about the general mailing list