[OpenID] query regarding OP migration

Babu N babun at intoto.com
Fri May 30 17:12:11 UTC 2008


Hi Nate & Shade,

Delegation feature is good, but it helps an end user only to some extent.

Let me elaborate why I'm saying "only to some extent". Though OpenID today
is solving the need for multiple usernames across different websites, an
obvious extensions of this model is to even include other information that
is typically spread across multiple websites.. like personal details,
professional details, email ids, IM/skype id, etc etc.. This is pretty
obvious from the feature requests page hosted at
http://wiki.openid.net/WishList#Feature_requests.3F. When such features get
included, may be we should call it as "OpenProfile" ( as it contains more
details than just ID :) ).

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.

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.

Instead of a single cetral digitalID server, we may opt for multipe
digitalID servers for high availability or performance reasons (just like
the DNS servers we have today).

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.

This way, it makes it easier for a user to start with some OP & then decide
whether to continue with the same OP or switch.

Please let me know your thoughts.


Thanks,
Babu



On Fri, May 30, 2008 at 8:32 PM, Nate Klingenstein <ndk at internet2.edu>
wrote:

> Babu,
> The short answer: "yes, but."  It is possible to address this use case with
> delegation.  It's a good feature but may be too advanced for some users.
>  It's certainly not standard practice.  This Wiki article might help:
>
> http://wiki.openid.net/Delegation
>
> Remember that this needs to be part of the initial setup.  This is because
> once the RP has cached an identifier associated with an account, it's
> difficult to reconfigure that link.  That OpenID is your login.  How do you
> prove that a different OpenID is the correct new identifier?  Unless your
> old, unloved provider is willing to help, manual reconciliation is the only
> way, in many cases, and that's a really expensive and difficult process.
>
> Take care,
> Nate.
>
> On 30 May 2008, at 13:52, Babu.N wrote:
>
> Hi,
>
>
> As I understand, OpenID allows a digital identity to be created at an
>
> OP & let this be used at multiple sites. After creating the digital
>
> identify & using it some websites, suppose the doesn't like the OP
>
> for service reasons (say frequent downtime, prone to compromises
>
> etc). Does OpenID technology allow the user to migrate from this OP
>
> to another, yet retaining the same identity (remember this is already
>
> used by him in registering at some websites..) ? If not, should this
>
> not be supported going forward ?
>
>
>
> Thanks,
>
> Babu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080530/a1f1604b/attachment-0002.htm>


More information about the general mailing list