Does 'User-Centric' also mean 'User-Burdened'?

Dave Kearns recently took on the topic of how user-centric and enterprise-centric identity could possibly co-exist in his articles for the Network World Identity Management Newsletter. In his first post, he discussed what the difference between the two is -  the need in the Enterprise scenario to have all identity-related transactions tied together from an audit perspective, contrasted with the need in the User-Centric (or personal) scenario to have no ability to tie together the various transactions a person can enter into. In his follow-up post, he discussed how the two, given these diametrically opposite requirements, could co-exist.

Multiple_Personas Dave postulates that the solution is based in the idea of Digital Personas. If I am reading his thesis correctly, he basically says that a person (an entity) can keep his online transactions un-linkable by using different personas (as represented by different information cards) that are kept separate and distinct at the source (namely the user and his IdP). In this way, common identifiers are avoided (not sure about that, since the most common identifier - an email address - is likely the same across most, if not all, of your personas), and so correlation reports cannot be built that harvest and mine data.

While Dave is clearly working with the constraint of what is possible today (both on a technological and legal footing), I think this solution puts too much of a burden on the end-user, since this requires the user to maintain multiple personas across the various applications he interacts with. In other words, even if the persona I want to present (PII attributes, credit cards, etc) to two different applications is exactly the same, I would need to create two different personas (in effect duplicates) if I want to make sure that there is no linkability. One can see the potential for persona explosion.

This is like saying that a user (who is extremely paranoid and wants no one building a consumer profile by looking at his purchase history) should maintain a different credit card (in effect tens or a few hundred) for every merchant he interacts with. That is comletely impractical. But just like there is no recourse today for consumers in this arena (the SSN, home address information, etc that every credit card record has enables complete linking, and results in the massive databases that telemarketers thrive and live on), it seems that there are no legal and technological solutions enabling the consumer to use the same persona while guaranteeing non-linkability. It's an interesting problem that I think needs to be addressed by the identity community, because if it isn't, linking of our online identities will happen (whether we want it or not), because the burden of maintaining multiple personas is just too much work, and user habits will prevail (just like it does in the matter of username-passwords).

Comments:

I suppose the extent of the burden on the user really depends on what PII they need to give to each system in order to accomplish their goals. In an on-line shopping scenario, you need to provide real payment credentials, and a real shipping address (or at least some kind of proxys that will get the job done), so there is limited ability for a user to easily keep that kind of transaction completely non-correlatable. On the other hand, many on-line transactions require only proving a) you're not a bot, and b) you are the same person you were last time. Systems based on Information Card technology, such as Microsoft's CardSpace, Parity Communication's Azigo and Novell's Digital Me all include the capablity to automatically generate strong site-specific login credentials from a single Information Card, as well as the ablity to easily create multiple Information Cards to support different personas. Add in a disposable email service, and it becomes very easy for a user to maintain this kind of lightweight on-line account in a completely non-correlatable way.

Posted by TCarroll on September 03, 2008 at 01:20 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

bocadmin_ww

Search

Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today