The Identity Corner

User-centric identity: boon or worst nightmare to privacy?

Two weeks ago I presented at the 7th Annual Privacy and Security Workshop in Toronto, which was well-attended by representatives from industry, government, and academia. Most of the presentations are now available for online download. In my own presentation, I discussed whether user-centric identity will turn out to be a boon to information privacy or its worst nightmare. Following are my key points.

To protect privacy it is NOT enough for the data subject to be the “choke point” for identity flows about him or her. At its worst (for privacy), user-centrism does nothing for the data subject but (a) greatly extend the reach of cross-domain sharing of identity data about him or her, and (b) result in a common cross-domain user identifier (handle) with each user-centric data transfer. Once previously unlinked “accounts” are “federated” (i.e., linked), the data subject is powerless: from here on, organizations can freely exchange user data directly between themselves. In this scenario, the data subject is in essence contributing to “super-federation.” To analyze how well a user-centric identity solution protects information privacy, one must consider at least the following questions:

  • Can the data subject consent to or withhold the release of identity data? (on a case-by-case basis, informed, non-coerced, …)
  • Can the data subject see the actual identity data that is flowing? (Or is it encrypted for the SP?)
  • Can the data subject hide the identity of the RP from the IdP?
  • Can the data subject hide the RP’s request from the IdP?
  • Can the data subject locally store and manage long-lived identity credentials? (If not, then all the data subject’s actions – and therefore accounts – can be traced and linked via trivial timing analysis.)
  • Can the data subject selectively disclose attribute data on identity credentials? (If not, the data subject cannot reveal the minimum information required for long-lived identity credentials.)
  • Can the data subject avoid correlation handles across IdPs and SPs? (If not, then data subjects are unknowingly linking up – “federating” – all of their account relations with each and every disclosure.)

Without a resounding “yes” to at least the three last questions in this list, a society-wide roll-out of user-centric identity will without any doubt be devastating to privacy.


November 17, 2006 - Posted by | General


  1. Interesting. I had some of the same conclusions. Check out…

    Comment by Phil | November 23, 2006

  2. It is not necessarily true that the IdP will issue the same persistent identifier to multiple different RPs, so it does not follow that those RPs can conspire amongst each other (eg: “link” or “federate”) behind a users back.

    I would go as far as to say that if an IdP *did* issue identical persistent identifiers, then it is by definition NOT user-centric.

    Comment by Chris Drake | April 4, 2007

  3. Correct, but my claim is that that RPs in concert with the IdP can do any linking and tracing they want, regardless of whether or not the IdP issues different identifiers. In many applications, the RPs and the IdP are part of the the same entity and/or may share an interest in jointly mining the data to profile user activities across RPs. If you are willing to trust that the IdP will not be involved when RPs compare notes, sure, no privacy problem; in general, any privacy problem can be trivially solved by appointing an “trusted” party (that is trusted with not providing essential information needed to breach privacy). The interesting thing is that there is no need for this.

    Imagine, furthermore, a scenario where RPs must extract digitally signed transcripts from their interactions with users, and that these must be submitted to the IdP (or an auditor). That would give the IdP on its own the ability to trace and link all visits of each user across all RPs – which may be highly problematic for RPs, as it could constitute competitive intelligence. At the same time, the IdP may have a legimate need for these “audit trails”.

    In sum, why adopt an identity framework that embeds unnecessary powers in IdPs that can be avoided (i.e, ensuring they can be given to the IdP on a case by case basis by RPs and/or Users, as needed)?

    Comment by Stefan | April 4, 2007

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: