One last plea: fix problem with "delegate" terminology

Drummond Reed drummond.reed at cordance.net
Tue Oct 3 05:19:26 UTC 2006


CAVEAT: This is not a technical proposal regarding OpenID delegation or the
proposed changes Josh is discussing on another thread. Rather it is a
proposal purely in the spirit of Josh's proposed test for the OpenID AuthN
2.0 spec: "I'd like to expend more energy on making sure there are good
implementations and that the spec is consistent, complete, and readable than
on jamming in new features."

This is proposal to solve a longstanding problem about "consistent" and
"readable".

BACKGROUND: Several times in the past, I have discussed w/Josh & others the
fact how unfortunate was the original choice of the term "delegate" for
establishing an equivalence association between OpenID identifiers (i.e.,
that they identify the same controlling party). 

The reason: in the context of identifiers, the term "delegate" is already
widely established in DNS and other naming systems (see
http://en.wikipedia.org/wiki/Dns#How_the_DNS_works_in_theory) as meaning
"assigning control of a namespace to another authority that you do not
control".

Ouch. That's almost directly opposite of what OpenID means by the term.

Every time I've had this conversation with Josh et al before, we've ended
out concluding, "Man, that sucks, but it's already implemented. So we'll
just have to live with it."

However, in the two months since I last had that conversation, I've had to
explain the concept of "OpenID delegate" to a bunch more people, and I'm
telling you, STICKING WITH THIS TERMINOLOGY IS GOING TO BITE OPENID IN THE
BUTT!!

The problem is: the more OpenID grows, the more folks who are familiar with
mainstream identifier systems like DNS are going to be exposed to it, and
the more they are going to go bananas trying to figure out what OpenID means
by this term "delegate" when essentially the OpenID meaning is the exact
opposite of what everyone else in the naming world means by it.

Since I care about the success of OpenID in the long run, I believe waiting
until 3.x to fix this problem is only going to make the problem
exponentially worse.

PROPOSAL

1) Do not break backwards compatability with OpenID 1.1. Maintain support of
the openid:delegate element in 2.0. But specify that starting with 2.0 it is
being replaced by a new term and will eventually be deprecated.

2) In OpenID Authentication 2.0, define a new term to uniformly describe the
concept of equivalent OpenID identifiers, i.e., identifiers that are both
controlled by the same real-world authority (end user), and are mapped
together to give the end-user control over the identifier they present to an
RP vs. the identifier by which they authenticate to an IdP.

Suggestions:

Openid:Equivalent
Openid:Synonym
Openid:Alternate
Openid:MapTo
Openid:Canonical
Openid:IDPID

And there may be others better still. Any of the above would eliminate this
confusion and save us all a tall stack of FAQ answers. (BTW, if needed I'd
be happy to craft the spec text that explains the migration to new
terminology.)

=Drummond 




More information about the specs mailing list