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.
“What sort of girl does he think customers are?”
We’ve already established what sort of girl they are. Your protocol is all about haggling over the price. I suppose that makes RMs really Personal Information Management Programs.
I like the “Hey Sailor” variant, with perhaps more specific late binding as to the data transaction being offered. All that you need to advertise is enough information to attract the right Sailor, you don’t need to specify the data. For example, I don’t have to say “Hey Sailor, want my vCard?” You can say “Hey Sailor, I’m looking to buy a baby stroller. Interested?”
In other words, the publication can be a request for services, independent of the data transaction, which could be negotiated later. To be concrete, like posting a link to a personal RFP to Twitter with a hashtag #prfp. “I’m looking for a baby stroller in Minneapolis ASAP. http://bit.ly/fe2f33 #prfp”
This is close to Hey Sailor, but doesn’t specify the data type. It publishes the service endpoint for discovering the data options, with a tag indicating who might be interested (sailors selling baby strollers near Minneapolis, presumably).
That service endpoint (http://bit.ly/fe2f33) would handle the data transaction, including authentication and moderating the scope or availability of information based on same, e.g., offering credit references or real-time geo data to approved Sailors. The call for Sailors need not be specific to a particular piece of data, such as a vCard or iCal.
Hi Joe– Great observations! I had considered personal RFPs as a Hey, Sailor type of use case, but hadn’t gone very far down the road of imagining how much data would have to be released as a “taste” (which does release some personal data into the wild for free, so to speak).
The service-endpoint piece you describe could be generic ProtectServe, if we take the lessons of this use case (along with all the others) properly in further design work. For example, we’d been envisioning that meeting the terms of a contract may be more than the Consumer just saying “I agree to the contract” – it may require providing positive claims, like “here’s the receipt for the money you require to be paid to see your data”.
The offering to Sailors might or might not advertise the data format in which the offered data is encoded, but standard data formats are, I think, important for making an ecosystem of this sort powerful and generative. Content negotiation could perhaps be used in delivering data in a form the Sailor/Consumer could handle, though the simplest thing would be to have a personal RFP format. (This was one proposed example.) Simple and RESTful is good, in my book, and I hope we can use the power of resources and URLs and content types in getting this going.