June 20 2007 Meeting notes
Conference Call Notes
Drafted by Joe Andrieu, June 20, 2007
IRC
- vrm at chat.freenode.net
Other Calls
Attendees
- Joe Andrieu
- Dean Landsman
- Mark Lazar
- Brett McDowall
- Drummond Reed
- Keith Hopper
Notes
Standards & Practices
What is VRM? It is VRM if...
The issues that have been hot on the mailing list are the privacy dashboard and users as the point of integration. Standards and Practices combines these two.
One of the technical groups at Liberty came out of a workshop in April for user consent in e-government applications and they are working on a dashboard for e-gov applications.
Three dimensions:
- Technical normative standards which any implementor can implement.
- Interoperability standards so that you have some assurance
- Best practices: getting people together to learn together how to solve real world problems and drive market adoption further and faster.
The dashboard is a meme whose time has come. There was a privacy dashboard post. There was another one that was more general. This should become a standard feature; it would be consistent with models like Higgins. Such that a personal Higgins service would be exposed via a dashboard. There are some technical details... how do the pieces talk to each other. Then there is a need for a standard interoperable implementation, much like apache helps drive/stabilize web standards. Finally, there still needs to be policy layer interoperability. That is, the controls on the dashboard need to map to the controls offered by the different vendors. If there isn't a match it doesn't work.
So, what we actually need is to standardize and get interoperability at the policy layer as well.
Higgins and Sxipper. Higgins is open source. Sxipper is a proprietary application. They both use the identity meta-system, but one is an open, multi-vendor solution the other is a product. Both are solutions for personal data services. Higgins is middle-ware that will accommodate different protocols. Sxipper may not have that same design goal.
Sxipper has great ease of use with great details about what one chooses to share. Four different identity types ready to share. OnePassword, which is locally-based single-sign on of sorts. It's an elegant password-centric tool.
Avant browser also offered this sort of thing. Firefox also.
Password management is the very tip of the iceberg for automating the user interaction.
If we look at form-fillers, etc. OnePassword is pretty good. It encrypts it, works across browsers. But with VRM, we have protocols that are identity-aware. So the problem with Sxipper is that is perpetuates the transfer of identity for transactions. Such that vendors track you as your attributes. But we don't really need to send those attributes--we need the resulting trust that they create.
I don't want to have to re-enter my information all the time. But that is feeding a lot of information and trust, and responsibility on that tool. Having interactions on the web should not require the user to reveal all this data.
Does the party need to collect the data about me?
What about deliver via a clearinghouse so that the vendor doesn't need to know the address.
The vendor doesn't actually care about password management. So we can release that. The same thing can be true of the attributes, such as shipping address. If they could hand-off that information management task to a third party, then the vendor is minimizing costs.
One challenge is this data is that this data is used for multiple purposes. It isn't just a matter of shipping. Companies often use the data for marketing analysis. So, the question is how can we allow these more abstract post-sale functionalities without busting the privacy bubble.
In a web services scenario where all of these pieces are being done on behalf of the user, you can have the releases automated at the point of service.
Someone mentioned a Vodafone demo that implemented an address functionality through UPS that allowed delivery without the initial vendor knowing the address.
In some ways, this sounds a lot like Google checkout. This does perform this intermediary service, where it shares only a limited set of information with the vendor.
Many of these vendors are already implementing aspects of these services, but in a closed service.
Are there particular stumbling blocks?
The problem is that everyone rolls their own. Google, MSN, Yahoo!, AOL.
Given that there are these silo reactions, what is the common thing that they want to protect?
We have to show that their adoption is going to ease their customer acquisition process more than it will lead to customer attrition.
Which leads to the fact that they want all that data to do their marketing.
Show some grass roots momentum. So that if they don't, their partners are going to do it.
Also, look at Privacy International. There will be continued pressure from regulatory and markets. We have to hope that this will also help drive adoption.
There is also a huge problem with crafting a shared language between vendors. Establishing a shared lexicon is inherently slower than just building the code. So even vendors who like this sort of thing, have a faster route to market building it themselves.
Many vendors believe their own product is "magic" and often overlook the simplest users. Often the refrain is "but everyone knows how to..." How much of this needs to be couched to the average Jane & Joe? Will the large monolith even think this?
One concept that we've been promoting is that if there is trust established, then a big part of the job is already done.
User experience is critical to this, and the large vendors often deal with that at the tail-end of the implementation. So, if we solve that problem, it has a lot of options. And if we can package it in terms of killer apps, then we can cross the gap and get traction. For example, CardSpace packages a killer app for the WS* protocol stack.
That is, the app drives adoption of the infrastructure. Until we had websites that matters, http and html were irrelevant.
Demystification... early adopters are far more sophisticated that Joe six pack. But the interesting thing is that when we eventually get to Joe six-pack, it is critical to demystify the product. The interesting thing is that we know that there is an incoming generation that is net-native--extremely comfortable with digital tech. Yet, at the same time the fastest growing online segment is 55-74. (As the boomers age.) These individuals actually have some financial power. They spend money. It is critical to see this appeal to them. A great deal of what Dean does is "demystify" these sites. Getting web developers to use "normal" language to talk with "everyday" users.
A lot of companies (vendors) are asking for this information, because they always have... this is the basis of how they perceive the world.
One way to circumvent that may be to find the Vendor's killer app, where they don't or can't get the data today, but which could be created in the personal data store. That's sort of what Google Checkout is doing. There are millions of long-tail vendors out there who don't want to manage shopping carts and transaction management. Instead, they'll use PayPal or GoogleCheckout. There must be a vendor killer app that could bypass this challenge of changing vendor's data hording habits.
What is it that we would have Google Checkout do?
Where is VRM?
We are still early, developing a conceptual framework, and catalyzing efforts around one or more real-world use cases. The only use case we have formally adopted is the Public Radio/Public Media initiative, with which Doc is running ahead full steam.
There are a few things going on in the background that may or may not be ready for public consumption. We are currently operating under the Harvard Berkman umbrella. We have gotten a lot of great feedback and learned that in a number of quarters there is a lot of activity near or directly aligned with what we are doing.
What is the VRM framework? Is there a flow chart?
Iain Henderson and Alan Mitchell have taken the lead on that. They've done an incredibly good job.
We are early on in the process, but making progress.
I think we need a more relevant work plan, where each call is focused on specific work case. Or we could have a more focused discovery conversation.
Work Plan
Next up: let's try to schedule a one-day planning meeting to map out a forward-looking time horizon.
We have gotten a lot of energy and traction developing a workable conceptual framework and a population of talented folks energized and able to contribute.
The next appropriate step looks like outlining a long term plan. With that we can itemize the concrete deliverables we need and rally people to work on those items.
- What are our three year goals?
- What do we need to do in the next year to achieve that?
- What are the deliverables, tasks, and subtasks required to realize the next year's objective?
A one day planning meeting in the next 60 days sounds like the right thing to do. Dean & Joe will coordinate with Doc. Brett made a commitment to join us for a one day session, perhaps in Boston, which will also help him evaluate whether or not he is the best liaison with Liberty at this point.
Status
| what | who | when | status |
| ---------- | ---------- | ---------- | ---------- |
| open id on wiki | david | no date | |
| static website development | doc, dean, joe, chris | no date | |
| group blog/RSS to wiki (venus) | doc | no date | up, talk to doc if you want to author |
| project VRM definition | doc | 1 week | still working on it |
| brainstorm Initiatives | all | ongoing |
Action Items
| what | who | when | status |