[OpenID] query regarding OP migration

[Peter Williams]

Why does one really need to de-register in openid - a law#1 mandatory consent policy context? The assumption is that you have several op provisioned with your attributes - and I all cases you choose which one to allow to release your data. If they are not abiding by law1, they cannot be presumed to deregister you either.

The notion that an op "controls" attributes and identity policies" is somewhat alien to openid, surely. The user controls always, in user centric id. This is hard to get used to, if you come from the predominant culture of TTPs (from pki hierachies, saml federations, telco based ecommerce, visa payments, enterpise proxies, isp mediated public access, vpns...)

-----Original Message-----
From: Nate Klingenstein <ndk at internet2.edu>
Sent: Friday, May 30, 2008 1:27 PM
To: Babu N <babun at intoto.com>
Cc: general at openid.net <general at openid.net>
Subject: Re: [OpenID] query regarding OP migration

Babu,

> When such features get included, may be we should call it as  
> "OpenProfile" ( as it contains more details than just ID :) ).

I think of identity as including all kinds of things about someone.   
The term you're probably thinking of is identifier.  The "ID" is a  
bit ambiguous as to which it refers to. :D

> Now assuming OpenID has these too in its roadmap, whats does it  
> mean to end user when he switches from one OP to another (say using  
> the delagation feature) ? He looses all the details that he has  
> been maintaining at the earlier OP. This is undesirable.

There's a second half: your details maintained at the earlier OP are  
still controlled by that OP unless you contact the RP to have them  
removed.  I don't think there's any way in the OpenID protocols to do  
deregistration.

> I believe that "digital identity" problem should have been solved  
> in this fashion:
>         1. Let there be some central digitalID server to issue a  
> digital identity, which is not attached to any URL (say I go this  
> server, register myself & ask for a digital identity "babu_n"). And  
> in this same server, I would also associate my digital identity  
> with "OP details".
>         2. I would select an OP & register with OP. Provide my  
> digital id here & associate my digital ID with "my details" (like  
> password, personal/profession details, etc etc..). It should be  
> mandated how OPs should store "my details".
>         3. I go to some OpenID enabled website & provide my id as  
> "babu_n". Here the OpenID enabled website now contacts the "central  
> digitalID server" & gets the OP details of the user (here  
> "babu_n"). After that it allows the user to get authenticated via OP.

Replace "central digitalID server" with "DNS hierarchy administered  
by ICANN" and your dream is basically today's reality.  There's just  
no trust fabric, which is something I'd like to see added as an  
optional layer for applications that care.

> It should be mandated that OPs store user details in some standard  
> format. And when user likes to migrate, the OP should let these  
> details be exported. The details exported this way may be used by  
> the user in importing at his new OP.

Data portability is certainly not part of today's dream.  I'd like to  
see it happen too, but there are all kinds of disincentives that are  
likely to hinder its rapid or complete adoption.  Here are two major  
fun problems to solve:

(1)  To whom should an OP be willing to export details, and when?
(2)  If a user is phished and the attacker migrates their OpenID to  
another OP, how do you get control of linked accounts back?

Take care,
Nate.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general