Identifier portability: the fundamental issue

Josh Hoyt josh at janrain.com
Sat Oct 14 08:50:38 UTC 2006


On 10/13/06, Chris Drake <christopher at pobox.com> wrote:
> DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable
> DR> identifiers.
>
> DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1.
>
> Please explain?  If I've got an OpenID URL (eg: my vanity domain), I
> can "transfer" this via DNS (or just update my OpenID <LINK>).  If
> I've got an i-name, I can transfer this too.  Where's the "lock in" ?

This is true assuming that IdPs have uniform support for registering
an identifier that it did not issue. OpenID 1 addressed this in its
architecture. In OpenID 1, the identifier does not even have to be
registered with the IdP. The proposed changes alter this arrangement.
In the 2-identifier proposal, the IdP does not need to support
registering identifiers, but it can be aware that a third-party
identifier is being used. In the one-identifier proposal, the IdP is
solely responsible for being aware of the arrangement.

I do not think the success of the protocol rides on this decision, but
I think it's important to understand, and understand the implications
of the choice that is made. In many ways, the spirit of OpenID has
been to empower the user above all. OpenID 1's delegation is
consistent with that.

> I do not believe the RP needs to know the IdP-specific identifier ever
> (worse: I think it should never be allowed to know it, or even be
> allowed to see it!).

Why not?

> Yes - we need 2 identifiers - but from the point
> of view of the specs - the OpenID protocol really only needs to deal
> with one.

See above.

> There seem to be a lot of people on this list who want to hate and
> loathe the IdP, and grant all power to the RP.  I do not understand
> this reasoning:  our users will select the IdP they trust and like,
> then they will be using a multitude of possibly hostile RPs
> thereafter: the reverse is simply not true.

Where is power being granted to the RP? It has pretty much none. It
*does* have responsibility, but only as much as is necessary to make
the protocol work.

> Can we not adopt my earlier suggestion: just ensure OpenID can permit
> IdP-initiated logins.  This permits every scenario of portability (and
> privacy) that everyone wants, without us having to continue to debate
> it ?

Huh? How is IdP-initiated login related to privacy or portability?

Josh



More information about the specs mailing list