lesscode.org


Many Lives — Just One You  

By Bill Burcham under First they ignore you.., Web as platform on 15. April 2006

You lead many lives. You’re a spouse and a parent. A soccer coach and a scout leader. A volunteer and an activist. You are an employee and an entrepreneur. Why do the systems you use not understand this? It’s like somebody out there just doesn’t care.

If you’re like me, and I know I am, you’ve got about a hundred accounts to keep track of on various systems — systems on the Internet, systems running in various corporate data-centers accessible only via VPN. You’ve got a slew of credentials to manage and no ability to leverage all that information at once. You spend your day duplicating and copying information between these systems, like some sort of freaking acolyte — serving The System — when The System should be serving you.

Meanwhile a million Web 2.0 startups are blooming. All DIY’ing for attention-equals-users-equals-dollars. Many of those startups are trying to tap both the consumer market and the corporate one too. It ain’t easy though since consumer buzz or even adoption does not always lead to access to fat corporate accounts.

What would it mean to you if you could use your favorite set of Web Apps all day and never have to log in twice regardless of which life you were leading moment-by-moment? How much more effective would you be if for each application, all your information in that application was available at once instead of walled off in separate accounts?

What would it mean to a Web Application provider if it was able to paint that picture for you? Would you be more loyal to that brand? Would you induce your employer, your client, your scout troop to use/purchase that brand?

I think there is a way and if you’ll lend me a few more minutes of your precious attention I’ll spin it out.

Imagine

The prevailing identity model in information systems arose around the enterprise system deployment model. In an enterprise system deployment, substantially all of the users of the system are employees of the enterprise. The enterprise itself is not represented at all in the model since each system serves only one enterprise.

This identity model has been carried forward to Internet-based applications. Just about all Internet-based applications offer accounts. An account represents a contract between the service provider and an individual. As such, most Internet-based applications are modeled like one big enterprise. Web Applications that offer corporate contracts offer separate identity systems for each corporate entity. At the end of the day, each of these identity systems — the “consumer” space ones and the “corporate” ones are separate.

Now let’s imagine a future where all applications are Internet-based. It’s easy if you try. Further, lets imagine that the market for some key Web Applications has settled down and consolidated a bit. So instead of a hundred wiki providers maybe there are three very popular ones. Kind of the way things were five years ago on the desktop with Word/Excel/Powerpoint/Outlook but this time, Internet-based.

Now let’s take a look at a knowledge worker, “Jessica” using say a wiki service, “WikiGood”. In the morning Jessica spends a few minutes in WikiGood writing out her plans for the day and reviewing progress against yesterday’s. Jessica has consulting engagements with two clients, “BigBoxCorp” and “NowYouSeeIt” but she’s in luck — both of her clients have standardized on the WikiGood service and use it heavily for day-to-day operations. As the day progresses she will interact with both of these corporate wikis as well.

In the first usage instance, Jessica is working on her own behalf, and wishes to keep the content private. What happens when she decides to do some work for BigBoxCorp? Well she logs out of WikiGood and logs back in with the identity assigned to her by BigBoxCorp. No problem. Other than the fact that she has two sets of credentials for WikiGood, oh snap, hang on — three sets of credentials because she’ll also be doing work for NowYouSeeIt.

There is a proliferation of accounts and credentials, but that’s not the worst of it. The deeper problem is that each WikiGood account is an island — even though all of the accounts are Jessica’s. Her preferences, her usage history, in short, everything associated with her in the system is divided, walled off, in three separate spaces. When Jessica is logged in under her NowYouSeeIt account and issues a search for instance, she will not find results for any of her personal wiki pages since the system knows her only (at the moment) as jessica@nowyouseeit. What if WikiGood is using Google AdWords to present Jessica with targeted advertisement? Is she a different Jessica when she’s logged in to her personal account than she is when she is logged in to her BigBoxCorp account? Google would like to think not.

Relate this scenario (personal account, and two corporate accounts) to other applications you use every day like email, contact list, calendaring, meeting scheduling, blogging, idea management, note taking, project management, personal task list, IM, VOIP, search. As these applications learn more about you, and you invest more time creating information in each application it rapidly becomes unacceptable to switch systems or even to switch accounts on the same system.

People increasingly expect and need the systems they use to learn more about them and to provide enhanced service based on that knowledge. Systems architected ignorant of the multiplicity of lives people lead force people to waste time repeating themselves (to systems) and copying information (between systems). More generally users of these systems fail to realize the full potential benefit of the knowledge they have shared. This is not a new problem, but it is certainly seems like a more pronounced missed opportunity in the age of Internet-based applications.

The situation is problematic. Users of systems would like to minimize the proliferation of credentials they must carry. Also they would benefit greatly from the ability to connect their accounts in a single system in such a way that they have visibility across all their content at once, and in such a way that they wouldn’t have to spend time re-entering profile, preference and other information into each account. Corporations seek these same benefits for their workers because it makes the workers, and hence the corporation, more efficient. On the other hand, corporations still have a desire to limit access to information (e.g. to employees only), and to monitor employees activities (shudder) if not for pure evil purposes, for regulatory ones.

But what of the service provider’s interests? WikiGood would like to continue to offer free or cheap service to individuals and premium service to corporations. The logic goes something like “we’ll attract consumers and that will lead to corporate customers”. But from the foregoing it should be clear that WikiGood is missing the opportunity to activate those very consumer-users, by failing to provide a vision for Jessica that looks substantially better than the walled-off nightmare. Users have little incentive to induce employers to switch to gmail for instance, if that would lead to each user having two gmail accounts instead of one. That situation is not appreciably better than the situation where the user has a gmail account and a corporate Exchange account. Contacts are still separate. Searches still fail to find results across accounts. The tags created for one account are completely separate (and return separate results) from the tags created in another account.

Many Lives — Just One You

The key missed opportunity is for WikiGood to acknowledge that users often act as agents for other legal entities. I’m using agency in the legal sense here. First from the American Heritage Dictionary:

One empowered to act for or represent another: an author’s agent; an insurance agent.

And now from the Agency (law) entry in Wikipedia:

The Agent’s primary fiduciary duty is to be loyal to the Principal. This involves duties:

  • not to accept any new obligations that are inconsistent with the duties owed to the Principal. Agents can represent the interests of more than one Principal, conflicting or potentially conflicting, only on the basis of full and timely disclosure or where the different agencies are based on a limited form of authority to prevent a situation where the Agent’s loyalty to any one of the Principals is compromised. For this purpose, express clauses in the agreement signed by each Principal with the Agent may identify specific types or categories of activities that will not breach the duty of loyalty and so long as these exceptions are not unreasonable, they will bind the Principals.
  • not to make a private profit or unjustly enrich himself from the agency relationship.

In return, the Principal must make a full disclosure of all information relevant to the transactions that the Agent is authorized to negotiate and pay the Agent either the commission or fee as agreed, or a reasonable fee if none was agreed.

If WikiGood introduced the concept of agency into its system, it would enable Jessica to have a consistent identity over time as she worked in her own interest, or in the interest BigBoxCorp or NowYouSeeIt, yet retain full visibility across all her content.

The core concept, is that within each application, a person has the ability to act as an “agent of” some identifiable “interest” or “principal” — think “employer” or “customer” or “client”. But the person retains her identity — the system always knows the person’s identity. There is one set of authentication credentials. Knowledge expressed to the system by the person is retained by the system and associated with that person — regardless of which “principal” they represent moment-to-moment.

In this way, principals can have (purchase) rights in the system, and those principals can assign their agents limited rights in the system too. The user switches between agencies as she operates. She expresses this switch through the user interface. If you’ve used a mail client that lets you select from multiple “from” addresses when sending mail you have the basic idea, only you’d make a “working for” selection each time you changed tasks. Perhaps you could “work for” more than one principal at a time — why not?

Instead of requiring the user to do this switching, perhaps smart systems could infer agency on-the-go based on time of day or content or physical location of the user. These smart systems could prominently display their guess and the user could change it if it was wrong.

In this way, no “closed system” like VPN is required to protect a principal’s interests. The principal contracts with various service providers the terms under which its agents can act. Principals then assign rights to their agents. But principals create no identities — they just assign rights/trust levels to identities. In this way one identity can serve many principals. There may be a notion of the “public domain” principal, so an individual has the ability to do work for the “public domain” or in the public domain.

What it Would Mean

The Agency-Aware Identity Model gives rise to a new business model where consumer accounts and consumer loyalty can be parlayed into corporate accounts. Each consumer-customer of a Web Service will now be highly motivated to induce each of the principals on whose behalf they work, to also become (corporate) customers of that same Web Service. Corporations (principals) would retain the important security and control capabilities they have today with their enterprise identity model: a) the right to assign and revoke privileges/trust to individuals (agents), b) the right to protect (privacy) information produced by their agents c) the right to eaves drop and monitor the activities of their agents for e.g. regulatory compliance, sexual harassment violations, EEOC etc. An individual, by agreeing to operate on behalf of an agency (for a period of time, or for a particular task) is potentially forfeiting some privacy or future access rights to her work product.

So what do you think? What would it be like to use WikiGood or your-favorite-web-app-here and never have to log out regardless of which client/principal you were working for moment by moment? How much more effective would you be if for each application, all your information in that application category was available at once? Would you be able to remember to click the drop down list of agencies as you switched between tasks during the day? Would you want that switching integrated with your web SSO system like OpenID? Do you believe that by adopting an Agency-Aware Identity Model, WikiGood could effectively turn its non-corporate customers into a rabid enterprise sales force? I do.

11 Responses to “Many Lives — Just One You”

  1. Mark Allerton:

    What you are describing here is not really any different from the concept of “group membership” in enterprise identity models. The false assumption you are making is that existing applications that deal with multiple organizations require separate walled-off identity systems - and this is absolutely not the case. Any enterprise identity model has to be able to deal with separate departments within companies with content that is not by default accessible across those boundaries, but with people who might be part of both groups. Also, the idea of “switching agency” is (mostly) not required - you’re forgetting that the content in WikiGood is divided by owner, so if I am working with existing content, my rights are known because they are inherited via the content and group hierarchy*. The only time I might need to assert on whose behalf I am working is when I create completely new “objects”.

    (* slightly specific to Business Objects, but I am intimately familiar with that one :-) )

    The tricky part (which I was hoping you were planning to talk about) is how we make this work across different applications hosted by different companies, like WikiGood, WikiBad and WikiIndifferent with one signon (like OpenID.)

    comment at 15. April 2006

  2. Alastair:

    I, for one, support our new Agency-Aware identity overlords.

    The trick is to ensure that the data associated with each principal is clearly identified, and that sounds mostly like a usability problem. You’d probably want the system to warn if you were leaking data from one agency to another (eg replying to a work email with your home address), for example.

    Also, the association of an individual to many agencies is highly private information. In an extreme example, I may not want anyone to know that I am both an agent for Exxon as well as an environmental activist. In other words the system should allow conflicts-of-interest and I think you alluded to this in the article above (”perhaps you could work for more than one principal at a time”).

    I think I disagree with Mark’s comments above - what you are proposing is for individuals to be (largely) in control of their identities. This is not the case with enterprise identity models.

    comment at 15. April 2006

  3. Pat Benetar's Secret Lover:

    Why not have an application that acts as a storehouse of user data and as a server allowing outside applications (through web services) to access that data? The user could run the storehouse/server on their home pc, or have a trusted entity host it for them. The different external web applications could be authorized to access whatever data the user grants them, then offer up their view of the data and allow the user to manipulate it (think calendaring, todo lists, contact management, wishlists, etc).

    I do not like giving my personal information to web applications. I agree that a web application provides a great “universal” way of accessing/managing data, but I am more interested in what they can do with my data than in them having my data.

    comment at 15. April 2006

  4. Mark Allerton:

    Alistair: Bill might be proposing for individuals to be in control of their identities. I support that goal and I agree that something like OpenID is really required for that. However, what Bill is describing over and above simple federated identity is no different to classic “group membership” and does not require a fancy new concept like “agency” to make it work.

    PS: the entity that gets to say whether an individual is working on behalf of someone else is not that individual - it’s the “someone else”. That will not change however much I want to control my identity.

    comment at 16. April 2006

  5. Bill Burcham:

    Like Mark Allerton, I see how a set of enterprises, each having groups, forms a hierarchy, and how that hierarchy can be modeled by a permissions system supporting general-purpose hierarchy, and how a person can have permissions from more than one hierarchy. I believe however, that there is more going on in real world agency.

    Turn aside from WikiGood for a moment. Let’s think about Skype. Jessica has a (personal) Skype account that she’s funded with real dollars to make PSTN calls in/out. Imagine that as part of her responsibilities at NowYouSeeIt she spends lots of time on the phone, so NowYouSeeIt provides her with a Skype account. Two accounts, funded by two principals, with two very different usage volumes. There is a difference in quality and quantity of service between these two roles that Jessica assumes.

    The Skype example feels very different to me than mere access control. While we could argue that the “funding account” is just another “object” that can be access controlled, I think that’s an oversimplification. In the WikiGood example it was pretty easy to argue that all we needed to do was limit access to shared objects based on group membership. But in the Skype example it feels like we’d have to replicate many of the structures associated with each user — and link those structures under a single identity.

    Also think of the “monitoring” stuff that corporations want/need to do. Again in the Skype example think of the familiar “this call may be monitored for customer service”. Jessica wouldn’t accept that for her personal calls — but NowYouSeeIt may demand it for calls made on their behalf.

    comment at 16. April 2006

  6. Mark Allerton:

    Bill: the Skype problem is more complex, but I think enterprise ID models suggest a solution to the QoS part at least - as well as rights, quotas can be aggregated through the group hierarchy. The rules are obviously more complex than the simple grant/deny/inherit needed for rights - does the quota “sum”, or is it the maximum or the minimum of inherited values? Are more complex rules needed?

    That said, I think your monitoring example does suggest a case where the principal needs to say on whose behalf they are working. Maybe something like agency is needed for these cases. I could imagine a case where there is a pre-existing relationship between the customer and the organization - in which case the customer becomes another object and their are rights and quotas associated with that relationship - but I might work for two organizations with the same customer so ultimately someone or something has to disambiguate - and that someone would be me (and you have to take my word for it as far as I can tell :-) )

    I still think the key to this is some kind of “federated group membership”, it would definitely deal with all of the “content ownership” problems which (I feel) are the core issue (the “new content” case I mention can be disambiguated by where I want to publish the content, BTW.)

    comment at 16. April 2006

  7. Bill Burcham:

    Mark: Don’t be too quick to trivialize the content creation case. The very notion of publishing to a “where” (”where I want to publish the content”) begs the question. Publishing to a “where” presumes that there are different “where’s”. The usual notion of a “where” is all bound up with notions of access control and protection and firewalling and separate systems.

    I for one, don’t want to publish to a “where”. Publishing to a “where” is where we are now. You publish to a personal Internet-readable blog. You publish to a corporate (Intranet) blog. You’d like to use a blog-style interface to publish private information for yourself and perhaps “syndicate” it to various audiences later. I’d like to separate the idea of audience from the idea of “where” and jettison the “where” notion entirely.

    comment at 16. April 2006

  8. Alastair:

    Mark: if I understand it correctly, one of the key differences between group membership access control model and an agency-aware identity model is the fact that with the latter model you explicitly select which principal you are operating on behalf of. In my experience it is relatively uncommon to select a “primary” group in order to do something similar for a group membership model. This is possibly because the concept of a primary group is not well intuited amongst non-techy types. In general I think the idea of agency fits more naturally into our every day experience. Which, after all, is what we’re striving for here.

    In any case I don’t want to see these two models as alternatives. Instead I think they are quite complementary, such that an individual acting as an agent for some principal can be given group memberships, access control, and so on, based on the agency. eg “technicians from vendor X can connect to all of our equipment which are under support agreement from that vendor” would define access for a group of agents (”technicians from vendor X”) without requiring identity of those technicians.

    comment at 16. April 2006

  9. Mark Allerton:

    Alistair: the reason that it is “relatively uncommon to select a primary group” is that it is normally completely unnecessary - the entity you are acting on behalf of is implicit in the operation you are performing.

    In your example, how is an “agent” different from a regular group member? It seems to me that your scenario cannot work without the target system being able to determine a) I am who I say I am and b) that I am a technician from vendor X. You can’t skip that first part - you have to be able to identify technicians even if their rights are only defined via their membership of a group. it’s not enough for audit records to just say “an anonymous technician from X did this”. Is mentioning accountability too enterprise-y?

    comment at 17. April 2006

  10. Brad:

    Until then, what if I could at least store all of my user accounts somewhere. I have spreadsheets at home & at work where I store them and then a few post-it notes in my desk with random credentials. Something like what they’re working on over at 7dots (http://blog.7dots.com/articles/2005/12/24/what-is-7dots) would help until the the consolidated user account idea is ironed out.

    comment at 20. April 2006

  11. Jef:

    OK, Bill, I [think I] get it after reading it. I actually want to build something like this for my lowly li’l windoze mosheen, but more like a personal profile. I understand that it isn’t a problem on a mac, but on my machine, I have a bunch of crazy things that happen at start up that take way longer than they should. I would really like to log in as the “information worker me,” or the “developer me,” or the “web browsing me,” and I would like the system to load only those pieces of software that I need and/or configure for that profile. I could create completely different user accounts, but then I run into the copy problem you mention. Maybe that should be what I work on for next time :)

    comment at 25. April 2006