Identifier portability: the fundamental issue

Fri Oct 13 20:56:40 UTC 2006

On Fri, 13 Oct 2006, Granqvist, Hans wrote:

> > "To achieve identifier portability in OpenID, it MUST be
> > possible for the RP and the IdP to identify the user using
> > two different identifiers: an identifier by which the RP
> > knows the user (the portable identifier), and an identifier
> > by which the IdP knows the user (the IdP-specific identifier)."
>
> There is no reason why the idp MUST require to know both
> identifiers for identifier portability to be possible in
> the system.

Existence proof:  OpenID 1.1 does identifier portability without two
identifiers in the spec.

And despite all the "but it can't be stateless without two!" noise, it
actually can:  you put the portable identifier in the return_to URL and
verify it again when you get the signature back from the IdP.  That is,
verify the mapping from portable -> IdP-specific still holds.  Because you
can't just trust the 1 (or 2) values you get back from the IdP, otherwise
the IdP (which could be malicious) could be fucking with you, asserting a
portable identifier which it's not actually permitted to do, according to
the portable identifer's YADIS/<head>/etc.

So with 1 or 2, you still need to verify, but that verification doesn't
have to be painful:  you can cache it.  "But that's state!  omg!"  Okay,
so don't cache it and re-check it.  But OpenID's been all about the
state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.

Counter-argument:  but OpenID 1.1 does have two parameters:  one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not "openid.", but something else...
the Perl library uses "oic." or something).  So then it's harder to
document the correct behavior to people ("RPs should verify the mapping
when you get a signature!") because the parameter names aren't consistent
between RP clients.

So whether it's in the spec formally or not, I don't really care.  But the
spec MUST contain details on the precautions a RP should take.

- Brad