The hard stuff – VRM Use Cases

Last week was the Internet Identity Workshop in Mountain View, California, which is, without reservation, the most productive technical gathering I know of. An “unconference,” (facilitated by the incomparable Kaliya Hamlin) it dumps the talking heads for interactive discussions so that folks can get real work done. The culture and focus enable a truly impressive amount of collaboration and co-creation as people dig in and work on the hard stuff of Internet Identity.

And there is a TON of hard stuff. Just ask Microsoft and Kim Cameron, whose CardSpace is making up for the failures of Passport. Or anyone who thought PKI (public key infrastructure) would solve the problems of Internet Identity. Or David Recordon and the folks of OpenID who brilliantly solved the challenge of a user-centric Single Sign On only to find that was just the first of many challenges of Identity and then answered in part with OpenID 2.0 and OAuth, and continue to answer collaboratively with the rest of the IIW community.

One of the hardest problems discussed at IIW is how we apply the open approach of the Internet to traditional buyer/seller relationships. When customers can come from anywhere and leave at any time, the silo-based world of proprietary lock-in is rapidly becoming outdated. It is not just unsavory for customers, it is actually damaging to vendors who doggedly defend their CRM systems and industrial era mindset. Fixing this problem is what VRM is all about.

In a planning workshop before IIW, a few of the early contributors to VRM met and started to map out the simplest use case we could think of: changing your primary postal address. We’ve all had to do it and it rarely goes smoothly. In the US, it often starts with a Change of Address card sent to the USPS, plus updates to magazine subscriptions, credit card companies, the IRS and the Department of Motor Vehicles, utility companies, ad nauseum… and eventually emails or letters to those friends we want to inform. It is structurally ideal for the user as the point of integration, since ultimately only the user knows for sure when and where they are moving.

What we found was that even this seemingly “simple” use case required a lot of baselining, normalization of language, and formal abstraction to fully clarify the details of what should happen when designed for the users’ needs rather than the vendors’.

In the end (with about 80% completion) it boiled down to a three-step abstract use case narrative, five requirements, and 5 supporting use cases (6 with the base case) for two actors, the AddressChanger and AddressUser:

Use Case Narrative

1. AddressChanger decides to move
2. AddressChanger expresses new address to system (optionally including scheduling information)
3. AddressUsers get the new address when they need it

Requirements

1. Address stored independently of any particular vendor
2. Owner of address can choose who stores canonical source (self-storage ok)
3. Data should be in an open format and portable without data or service loss
4. Data transfer and use is always under user control
5. Vendors can discover the appropriate service for each user

Supporting Use Cases

1. AddressChanger Changes Address (base case)
2. AddressChanger Manages Address Holder Permissions (and data subsets)
3. AddressChanger Accesses Audit Report
4. AddressChanger Reviews Address
5. AddressUser Gets Current Address (pull)
6. AddressUser Subscribes to Address Changes (push)

This level of definition specifically leaves the design and implementation details up to subsequent engineering. The first step for VRM is to formally define the requirements of the system in the individual’s terms. Once we agree on that, we can move to specifics of how the requirements can be met. For instance, in the above definition, the user may or may not directly interface with an “Address Service”. The expression of a new address and the authorization management could all–theoretically–happen at standards-compliant vendor websites (who are in effect acting as the Address Service). For example, when I tell Amazon I have a new address, they could automagically update the cloud so that other authorized vendors get that address, and those “authorized” vendors could have been set up at the same time I signed up for their service. Use cases 5 and 6 are alternative design choices, but the consensus was that a standard system should allow the users to make that choice rather than restricting it at this stage.

As we make design choices, we can clarify the challenges and additional requirements those design choices imply. Those design choices will in turn suggest further use cases, which, in the case of VRM, can be considered for further development and standardization if merited. For example, Amazon currently lets me maintain any number of addresses of record… how would we update the Use Model for the Address Service to allow multiple addresses, including the additional authorization complexities? Plaxo, in contrast, allows two addresses, a personal and a business address, which syncs nicely with their permissions framework for who gets updates to which address. What do these usage situations imply for the entire use model? How should/might we expand the use model to standardize how this advanced functionality is supported in a cross-platform user-centric way?

We then took the simple use case as outlined above and worked through a Gap Analysis, led by Brett McDowell with Paul Madsen, Paul Trevithick, Andy Dale, Doc Searls, and Drummond Reed contributing, among others. That conversation morphed from the AddressChanger use case to the AddressUser to map out how current technologies implement this use case, including any overlap and missing pieces. Here’s what we came up with:

It is more than a bit technical and without a good discussion, it is hard to understand the details (I will point out that the BA in the cloud is British Airways, one of many AddressUsers in the system). Yet, this is the magic of IIW, this is the hard stuff, collaboratively worked out by folks who are intimately involved with all of the competing technologies… because at the end of the day, without interoperability, Identity (and VRM) are just another proprietary data service.

Here’s Paul Madsen’s post-IIW reflection and continuation on the Address Change use case. Good stuff. You can clearly see how the “simple” use case outlined above starts to address sophisticated real-world situations. You can also see how this is just the beginning of a conversation that both explores and defines some critical uses of both Identity and VRM. Paul outlined specifically how the WSF framework could implement the use case with particular design choices along the way, such as when & where the user interfaces with the Address Service. The same scenario could also be implemented with Liberty’s framework or OpenID+OAuth. And as Paul states, just about any aspect of Identity could be managed this way. And for some use cases, we need even further specifications, such as how we manage Personal Health Care records or how a Personal RFP is structured, propagated, and responded to.

I’m looking forward to moving this forward and transforming more of these “simple” use cases into consensus requirements for reinventing the modern marketplace, or as we like to call it, VRM.

Bonus link: a great post by Joel Spolsky of Joel on Software on the value of solving the hard problems.