Chris, I totally agree that: a) OpenID Authentication 2.0 should support yours scenario of IdP-initiated login, and b) that this enables a whole range of privacy solutions, many of which can be supported by IdP innovation.
If IdP-initiated login were the only use case, then only one identifier would be needed. It's the use cases for RP-initiated login that argue for having a second identifier parameter in the protocol. =Drummond -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Friday, October 13, 2006 9:19 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Hi Drummond, 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" ? 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!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. 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 ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> ********* DR> Please post if you do not agree with this postulate. DR> =Drummond DR> _______________________________________________ DR> specs mailing list DR> specs@openid.net DR> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs