Releasing same NameID to all service providers

[Cantor, Scott]

On 3/18/15, 2:30 PM, "Alex Olson" <ako at byu.edu> wrote:

>Is there a significant vulnerability in releasing a standard persistent nameID (like a uid) that is the same to all service providers?

Vulnerability isn't the right word. It's a privacy question. Even if you don't do something like, say, support attribute queries based on the uid, you're adding a correlation handle to all the user's activity across different services.

The theory behind directional identifiers was that people would not want that to happen and that federated ID shouldn't introduce such handles over and above all the existing ones available like IP address. The practice is that this is mostly a failure, apps don't handle getting ugly, long IDs well, and everybody on the Internet treats the email address as the username for everything.

> Or, what benefits are there to using something like a StoredID to generate a NameID vs. a persistent NameID that is the same?

The main benefit is personalization without any further identity disclosure. It's best use case is library services and the like, and they do the best job at actually allowing it to work. Traditional apps like wikis and such do a really bad job with it because they assume the userid is meant to be displayed, shared, selected, etc.

-- Scott