The need for permissioned data-sharing and relationship management doesn’t discriminate in favor of, or against, any type of entity; the stick figures below, representing a data-discloser and a data-consumer, could be a big company and one of its suppliers (B2B), or a company and one of its customers (B2C), or a customer and one of the vendors in her life (C2B), a citizen and one of the government agencies he deals with (C2G), etc.
The process wants to become more “peer-to-peer” (P2P!) than it is today. Data-disclosers, often disadvantaged today because they’re pressured to over-disclose and under-enforce, need to be empowered in a more balanced way. But while we’d like our ProtectServe and Relationship Manager architecture to be suggestive for the general case, we had to get specific, and so our initial use cases involve a data-disclosing human being and a data-consuming web app; you can think of them as playing the roles of “customer” and “vendor” in VRM scenarios such as change-of-address.
Here were our major functional requirements:
- Allow individuals to establish policies for each data-sharing relationship they have, as an interface mode separate from the login process
- Allow individuals to conduct long-term relationship management, including modifying the conditions of sharing or terminating the sharing relationship entirely
- Allow data recipients to retrieve data directly from authoritative sources, guided by policy, even while an individual is offline, reserving approval loops for extraordinary circumstances
- Allow data recipients to retrieve individuals’ data from multiple online sources, on a one-time or repeated basis
- Do this simply enough to attract adoption and energy
Obviously these requirements drive a lot of decision-making all by themselves, but soon enough even more specificity is needed. And that’s where Bob Blakley comes in. Bob kindly provided a lot of detailed feedback to me recently on our ProtectServe user experience mockups. In the course of our chat, he nicknamed two distinct use case categories we were hoping to solve for, which clarified my thinking in a big way.
One set of use cases involves a User explicitly provisioning a Consumer app with a way to get some set of data. For example:
Registering for a new online account (or even buying something on a “one-night stand” basis, with no ongoing account) and providing stock info like a shipping address and credit card data (likely packaged into a set somehow)
Providing calendar data to businesses to solicit event invitations (cable customer service, dentist’s appointment), or — in the case of travel calendars — to control mail/package/newspaper delivery or solicit travel-related offers of products and services (like country-specific prepaid calling cards)
Making home inventory data available to insurers, or to estate-sale catalogue assemblers
- Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group
(Warning: meta-example!) Serving out some cooked form of Relationship Manager audit-log data to a company that builds reputation scores for Consumer apps
Noting that the user is fully in charge, and no Consumer even learns about the data’s availability without the User’s personal and active involvement, Bob gave this set of use cases the Delta Tau Chi name of Data Dominatrix.
We also worked with a secondary bucket of use cases, though it has presented us with interesting protocol and user experience difficulties: widely publishing the existence of data, then deciding whether to to release it on request (where the requests were not individually solicited). For example:
Putting links to your calendars, vCards, etc. on your blog, and then fielding requests from every party that wants it
Offering a package of demographic data about yourself to any survey service willing to pay your price
In his inimitable way, Bob named this one Hey, Sailor. (Hmm, I’m sensing a theme here. What sort of girl does he think customers are? Then again, it doesn’t help that sometimes we want “one-night stands” in our online relationships!)
These use cases affected our choices around things like:
- The dynamic nature of the introduction process between Consumers and other parties
- The granularity of contract terms as they apply to data resources
- Where users need to be involved real-time vs. where they at least want the option of real-time consent vs. where they don’t want to be bothered
By the way, we also discussed a third use-case bucket that has not been on my team’s radar, and which I don’t believe got a nickname: The User puts together a prospectus of data he’s willing to assemble, if the right offer is made by a potential Consumer. While this sounds very interesting, there are already enough business and technical question marks around the rest of the proposition to make me want to hold off. But hey, if anyone’s inspired to defend it (or name it!), let me know.