openid.delegate explained.

Brad Fitzpatrick brad at
Tue Oct 3 11:58:59 PDT 2006

I don't care what openid.delegate is renamed to.  But I feel strongly
it has to survive ... I think it's one of the most important things to
OpenID, just not well understood.

Let me walk through how it works....

  * User Brad currently uses as his IdP

  * Brad doesn't want his LJ to be his canonical identifier because

      a) he has a better one, under his control (""),
         he's just too lazy or incapable of running an IdP there.

      b) he doesn't trust that LJ will stay around forever, or it
         might become evil, stop supporting OpenID, or maybe
         he might want to switch to a better IdP in the future.

  * So Brad gives RPs his "" identifier.

  * RPs discover that's IdP is, but knows jack shit about ... and
    perhaps Brad doesn't trust LJ to know about ...
    or fears LJ might charge more to use that feature.  etc.

In summary, the most important thing is I can change my $4/year
identifier's IdP every day without informing anybody or making deals with
thought I was "" still think I'm ... it's just a
different IdP asserting that.

Not to mention I can still avoid running my own IdP, adding to the
bootstrappability of all this ... because I imagine a lot of people will
want vanity-plate identifiers (well, never as cool as =BradFitz !) and
getting those early dorks in is important too, but not as important as
disconnecting an IdP from an identifier.  If a given identifier can only
be asserted by one IdP, we have lock-in, and people either don't change
IdPs, or change and break their identifiers.

So openid.delegate is like cellphone number portability.

I urge everybody not to accidentally break this while renaming it.

- Brad

More information about the specs mailing list