[OpenID] query regarding OP migration

[Nate Klingenstein]

Babu,

> Babu> The problem with today's reality is that my "digital  
> identity" is lost if the OP shuts down his services or I would like  
> to migrate.

That's true, but some important identity information is difficult to  
separate from the OP.  For example, our universities often maintain  
whether someone is a student.  Students get access to services that  
they university has licensed.

Imagine one of our students wants to export their identity.  Now  
their new OP has to convince RP's that they are a  
student at example.edu.  Remember that student at example.edu gets you  
access to expensive, licensed stuff.  That makes it difficult and  
costly for the RP to trust any OP in the world to state  
student at example.edu.  Do we give the OP a signed blob saying  
"userid at outsourced.org, expiration, student at example.edu, quoth me"?   
I don't want to deal with attribute revocation...

I agree that, for many use cases, data portability is important and  
good.  However, if I wanted to introduce it to our real deployments  
of federated identity, I'd have to solve these difficult problems.   
We're probably talking about pretty different use cases, so you might  
not face the same problems.

Attribute aggregation and identifier portability are a more likely  
outcome for us, but they have their own challenges.  There's a lot of  
thinking to be done here.

> But in the case of DNS, the registered domain name remains forever.

Try out "whois", or check in with me on May 4, 2011. :D

> Babu> Even with today's OP-specific-digital-identities, we have  
> phishing issue. What does an user do if he is phished. After this  
> if the attacker changes the password, does the user not loose all  
> the webiste accounts at which this OP-specific-digital-identity was  
> used ?

Let me explain a little more.  Universities, being big, juicy  
targets, are often targeted by spear phishing.  An attacker poses as  
the university to try to steal user credentials.  Some hundreds of  
students and staff are usually fooled.  When they realize what  
they've done -- or, more often, after we realize what they've done  
and lock the account -- they call the help desk.

We go through re-credentialing, which requires you supply various  
personal information or identity cards to prove you're you.  Then, we  
change the user's password, force them to apologize and memorize what  
the real authentication page looks like, and clean up any messes  
created.

Now, suppose in a world of identity portability that the attacker had  
migrated the user's account to a namespace and server they control.   
What does the help desk do now?

I don't have good answers, but I appreciate the dialogue and any  
suggestions you might have,
Nate.