May 9 2007 Meeting notes

Conference Call Notes

Drafted by Joe Andrieu, May 2, 2007

IRC

1. vrm at chat.freenode.net

Other Calls

Category:conference call

Attendees

• Joe Andrieu
• Iain Henderson
• Dean Landsman
• Kevin Barron
• Doc Searls
• Matt Terenzio
• Drummond Reed
• Nick Givitovsky

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, but only one author
project VRM definition	doc	1 week	still working on it
brainstorm Initiatives	all	ongoing
Set up Jabber Host for conference calls	doc	no date	new

Joe: remind Dean about transcript.

Notes

Agenda

• Update from Doc on Brussels
• IIW
• June 4th Discussion
• Use cases
• VRM blog
• Web page
• Point from last call

Brussels

Identity Open Space, hosted by Bret McDowell and run by Kaliya Hamlin.

Great talk given by JP Ragaswami: "Because of" effect of making money "because of" rather than "with" a particular technology.

What Iain is working on is quite a detailed document on B2B VRM.

Ben Laurie invited Doc up to visit Google. He's one of the Apache leaders, now doing stuff for Google.

Good diagram that brought together a bunch of VRM-related concepts. The main thing that came out for Iain was the interest by the Liberty Alliance guys to contribute to VRM. He agreed to join the Liberty Alliance. His hope is that we will join him.

Doc mentions Paul Madsen (of Liberty) had already contributed to the wiki, but it went away.

Paul had presented a working framework that is already workable, using standards-based exchanges for VRM. Liberty is probably the most down-stream of the identity systems for data to be trustably exchanged in an enterprise framework.

One thing we should explore is how to match up technologies like Liberty, like what Iain is working on, with particular use cases and how that would play out. Doc is going to be talking tomorrow/Friday morning with some of the Higgins folks. Higgins is a framework for multiple identity systems. I'd like to outline where some of these different technologies fit in.

Adriana was also there. Iain and she will be meeting tomorrow to continue the conversation. She works with J&J among other companies. Doc met with them last October at a meeting. They are interested in exploring VRM and Adriana is the link into them.

IIW

Let's try to set up a call-in conference at one of the break-outs so that folks who can't be there in person can join in for a session.

June 4

At Berkman in Harvard, we've set up to have a meeting on VRM. Berkman has an affiliation with the Internet Study Center (or something like that) at Oxford. And they have a really good teleconference set up that might be useful for folks in the UK.

We'll be discussing VRM in the AM and public radio/media in the afternoon.

Public Media/Public Radio

On the ride back from Brussels, Doc & Ben had an interesting conversation about the public media effort and Ben thinks that particularly use case has a viable solution using a relatively small number of use cases.

The interesting challenge there is pulling apart transaction and relationship. Generally, it works today by buying membership from a station, which in part means an unending supply of junk mail and solicitations.

What I'd like to do for the Berkman meeting is to come up with ideas for how that might be done. How we might separate the membership relationship from a simple, targeted contribution to a particular program.

So, perhaps we can create a solution cobbling together some technologies, then start working through organizational and political issues to get the solution deployed. There's a national organization, each station has its own issues, and then each producer of the individual shows. All of three have their own concerns and challenges.

Even if it doesn't work... Doc would like to see it fail for political rather than technical reasons. So lets find the technical solution and then work through the politics.

Keith Hopper of Public Interactive suggested that what we need is a new public station or make a new Internet-only national station, in order to try out whatever it is that we are going to do. That could be a working test-bed. It could have its own problems, but since Keith suggested, he might have a better idea of what might be involved with that. PI handles pretty much all the technology for public radio.

Use Cases

• Public Radio
• Personal Data Silos
  • Customer retain the memory of prior interactions with a particular supplier

Stories: Doc told story about problems with a vendor where the history of the customer service was problematic.

We need a totally agnostic body, a clearinghouse where both vendors and users can go without fear of mining, spamming, or fishery--not Google or Yahoo, etc. But somewhere that vendors & users have equal, shared control of the relationship-related data.

Drummond Reed mentioned his own efforts to solve this problem (commercially).

Looking at the customer-history tracking, what is the minimal set of data-types that need to be presented to each other?

As the customer, you have a specific memory, while the vendor has a general system of data that may not be well-focused or accessible. In helping the end-customer, it is about taking customer knowledge and sharing it with the vendor in such a way to plug it into their system.

Example: in a service relationship, where you appeared in person. So you had to represent that in person and represent that problem coherently. Nick got sent a wrong part by a refigerator company. And had to call a bunch of people. He documented that on his website, and was able to send that information to the next individual.

Another option is how Nordstom's attaches a return-UPC to the item.

The challenge is that each company may or may not accept anyone else's UPC. Which suggests that the easy, semi-automatic documentation of service history controlled by the user, we have a lot more viability, especially with adversarial vendors.

On top of that, we can also record whatever lookup code or case #, that might be provided by the vendors, allowing a hook back into the vendor system, should the vendor be able to respond to it.

Interestingly, the hook provides the fastest way for the vendor to pull up the countervailing evidence to compare with the customer-provided history.

In terms of adoption, this is in some ways related to the web. Somebody had to be first.

Perhaps this is essentially a digital receipt. So, to the extent that we can request digital receipts go to a specific identity. And these "digital receipts" could cover service transactions just as readily as purchases.

Staples is actually pretty forward thinking in this way. Dean shared a frustrating experience that he escalated to the president--cold calling his voice mail--and they actually bent over backwards to fix it.

This may also provide some interesting advantage as an early adopter if they can provide these "digital receipts" back to enterprise customers who might be able to more easily track that as corporate expenses.

VRM Flowchart

Someone asked for a VRM flowchart. I think that could be a useful tool, if we can figure out what it means.

There was one Johannes Ernst drew at IIW 2006b. Paul Madsen drew another one at IOS in Brussels.

Dictionary/Glossary

It is critical that we have a common terminology, common glossary so as we move forward, we can actually have a clear understanding of what we are doing.

IIW 2007

The next major live even for VRM development, evangelizing, and camaraderie is the Internet Identity Workshop in Mountain View, May 14-16. Many of us will be there. We hope you can join us.

Action Items

what	who	when	status