On Fri, May 28, 2010 at 02:13:04PM -0400, George Fletcher wrote: > If it's possible to discover the new identifier from the old one, then > RPs can just go through their DB and do the mapping out-of-band (meaning > the user doesn't have to be present). This can easy migration efforts > from a deployment perspective.
I would *love* to see that. We offer OpenID RP for login largely because we offer relatively few authentication-required features, so our general users (unlike, say, Facebook users) rarely need to log in. OpenID allows our customers to use their existing accounts at OpenID OPs instead of creating new accounts whose passwords they're sure to forget. It would not be at all unusual for one of our customers to go a year between logins. So I don't want a migration protocol that relies on the OP running both 2.0 code and Connect code, and can only migrate during a login event -- surely at some point OPs will choose to shut down their 2.0 services, and any of our customers who haven't migrated to new identifiers by that time will have orphaned, unusable OpenID 2.0 accounts. The strawman proposal from Allen & John requires OPs to run 2.0-compatible discovery services in order to migrate to Connect identifiers, and that part makes me nervous. Our users don't see themselves as logging in as https://www.google.com/accounts/o8/biglonguglyreallylongstring and won't (shouldn't!) understand that their Connect identifier is different. They see themselves as logging in with their regular Google accounts, and I don't want that perception to change if/when we switch the backend crypto stuff to Connect. Once their OP shuts down 2.0 discovery and only sends Connect info, our users would wonder why we forgot who they were -- and we wouldn't have any idea that we'd seen any one of them before if they hadn't logged in recently. :-( -Peter _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
