<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>RE: Identifier portability: the fundamental issue</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>We must have different understandings of the term sacred then.<BR>
<BR>
My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted.<BR>
<BR>
<BR>
<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
-----Original Message-----<BR>
From: Drummond Reed [<A HREF="mailto:drummond.reed@cordance.net">mailto:drummond.reed@cordance.net</A>]<BR>
Sent: Friday, October 13, 2006 12:58 PM Pacific Standard Time<BR>
To: specs@openid.net<BR>
Subject: Identifier portability: the fundamental issue<BR>
<BR>
Yesterday we established consensus that with OpenID, identifier portability<BR>
is sacred.<BR>
<BR>
Today I'd like to establish consensus on the following "postulate":<BR>
<BR>
"To achieve identifier portability in OpenID, it MUST be possible for the RP<BR>
and the IdP to identify the user using two different identifiers: an<BR>
identifier by which the RP knows the user (the portable identifier), and an<BR>
identifier by which the IdP knows the user (the IdP-specific identifier)."<BR>
<BR>
I would submit that if this postulate is true, then OpenID Authentication<BR>
2.0 requires two identifier parameters because if the protocol only allows<BR>
sending one, then:<BR>
<BR>
1) If the RP sends the IdP-specific identifier, the RP must keep state to<BR>
maintain mapping to the portable identifier (bad), and<BR>
<BR>
2) If the RP sends the portable identifier, an IdP is forced to do a<BR>
resolution a second time after the RP has already done resolution (bad).<BR>
<BR>
OTOH, if the postulate is false, then a case can be made for OpenID<BR>
Authentication 2.0 having just one identifier parameter.<BR>
<BR>
PROOF<BR>
<BR>
CASE 1: the protocol supports only IdP-specific identifiers and no portable<BR>
identifiers.<BR>
<BR>
RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1.<BR>
<BR>
CASE 2: the protocol supports only portable identifiers and no IdP-specific<BR>
identifiers.<BR>
<BR>
RESULT: IdP is forced to know and store all portable identifiers for a user,<BR>
including identifiers for which the IdP is not authoritative, and users<BR>
would be forced to register all their portable identifiers with their IdP,<BR>
and to update these registrations every time the user adds or deletes a<BR>
portable identifier. Highly undesirable if not impossible.<BR>
<BR>
*********<BR>
<BR>
Please post if you do not agree with this postulate.<BR>
<BR>
=Drummond<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
specs mailing list<BR>
specs@openid.net<BR>
<A HREF="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>