May 16 2007 Meeting notes

Conference Call Notes

Drafted by Joe Andrieu, May 16, 2007

IRC

1. vrm at chat.freenode.net

Prior Conference Calls

Rather than do a standard subscribable podcast the calls are available for the list to download or stream. They are posted as mp3 files and can be accessed as follows:

May 2, 2007

• meeting notes 2007 05 02

March 21, 2007

• meeting notes 2007 03 21
• audio 2007 03 21

March 8, 2007

• meeting notes 2007 03 08
• no audio

February 21, 2007

• no meeting notes
• audio 2007 02 21

February 8, 2007

• meeting notes 2007 02 08
• audio 2007 02 08

Attendees

• Joe Andrieu
• Iain Henderson
• Dean Landsman
• Doc Searls
• Keith Hopper

Notes

Skype Simulcast

smarthart

Opening Comments

Lot of action and energy picked up.

Iain Henderson and Alan Mitchell have made good progress with the "flow chart". Many thanks to them.

First IIW Session

Andre Duran, mover behind IDWorld, Jabber, now at Ping Identity. He suggested that we look for particular use cases or applications and connect the dots from the user through to the CRM system or vendor.

Steve Gillmor said largely the same thing. Steve is the father of the AttentionTrust. (Not to be confused with Intention). "Set up strawmen and knock them down."

Paul Trevithick laid out a diagram showing a number of arrows from the user, indicating data stores on one side and on the other side of the line indicating the relatively impoverished data stores living in CRM at the vendors.

This led to the concept of "my red dot" or the personal data silo, which is the user-side store of things such as personal RFPs, digital receipts, transaction histories, affiliations, preferences.

My Red dot

Looking at it from the CRM perspective, we can identify three different pillars: sales, marketing, and customer support. So what does that look like for VRM from the customer perspective.

The Red Dot represents an identity-secure data store controlled by the user. Potential components stored therein: my past purchases, my support history.

Looking at the three pillars, what might a VRM interface look like from a user point of view. What if we pulled all three pillars together into a single interface. Where you can browse (shop), see purchase history, and see support history. What happens today is that we get put into a vendor data store, and when we call in, they get a screen full of relationship data (history). So, for the user, this is a place where this data can be managed/viewed/tracked across all vendors. Whenever I have had a support issue... right now we take notes, scraps of papers, post-its, etc. What if we have a central point to track all of those items digitally, just as CRM systems do for vendors.

My dish network is down. I've been calling them. (Other current topics I'm currently dealing with). Not only could the vendor's get this data, but we could publish this for other customers to view.

For buying, we fill out the query information, in this case for travel. That query goes out to the cloud, modulo identity access privileges, and airfare options come back to the user.

At the lightest level, a personal RFP is basically what we are submitting as queries at Google. (Information RFP). So, how is this data propagating/broadcast/discovered out in the cloud? Is it an RSS/Ping architecture or some other mechanism?

This outline is very conceptual and perhaps too specific.

The top piece (search) just doesn't exist. What that means is that you need a way for aggregating all this information to go back into the red-dot. Vendors could be sending data back, but how does that happen?

So what do we need as vendors? What do customers need?

One caution is building a central anything.

Joe introduced SwitchBook's Search Document concept which is intentionally structured to let users manage multiple search providers in the user context.

So, what technologies are out there that can make this happen?

If this were the web... we are asking for shopping carts at the stage when we are just putting together a website.

What protocols do we need?

At one level, we need to standardize license terms for accessing the personal data silo. (Identity rights agreements.)

The old architecture, the vendor defined architecture, didn't work because the telco wanted to be at the center. Why is it so hard for me as an outsider? But it wasn't so hard before. That's because vendors have IT departments, and individuals don't. So, perhaps we need an open source IT department to build the big red dot.

XDI has all this in there. But nobody is building it. We need to allow people to use that.

Jiffy Lube, for example, actually has much more information about the car's service needs than I do. So, the smart companies are going to jump on board and support the user. Because the user's IT department is going to build this "bazooka".

In addition to "where's the code". The issue is where are the standards?

Where is the leverage? We need a protocol, we need some software. There are standards that could or could not support aspects of VRM. But where is the leverage point where VRM really has an impact. What seems to be critical is giving users control over their own data, but being able to delegate management of that data by select partners. And you may want to change those relationships over time, without losing the data related to that delegation. The leverage may be in this point of user control over data.

If Netscape had not delivered both a server and browser at the same time, we would have floundered around for quite a bit. We still need somebody to base-line this code.

Why would the vendor do that?

In some industries, there are vendors who know they want more information about the user/consumer. Without Identity, you can't quite get that. So, users maintaining a rich profile that can be sent to multiple vendors.

Users fake data because vendors can't be trusted. Targeted ads aren't always enough to reveal information such as date of birth, etc. Controlled access to personal data, based on specific licenses, more users will be willing to exchange.

How do you make CRM systems accountable?

We understand that silos will be territorial and protected. But you can always point out a number of situations where the data is clearly falsified (too many users selecting "Alabama" or "Afghanistan" because that's first in the list.

If users are aggregating data that vendors want access to--because the entirety of the data is more valuable than just the parts created at any particular vendor--then vendors might agree to reciprocity on the data access, thereby providing their input automatically. (Think movie/book/media buying/viewing history).

P3P is a way for a site to specify their privacy policy in a programmatic way so that clients can automagically manage that. We need not only simple license, but simple language and simple icons so that users /understand/ their choices. Otherwise, users aren't going to use anything. P3P never went anywhere. Why?

Those privacy policies are enforceable.

At Berkman, one question is what do we break off from VRM to create a working group, especially in areas of law. Perhaps a privacy commons is the right approach.

Right now, Sxipper learns how you fill out forms so that you don't have to. What about doing that for CRM? That's what Mark Wahl is working on. Not only must you understand the data, but what transformations are required to map from a central data store to a particular form.

Important to extend VRM beyond the web... and providing real world (physical world) value.

As a consumer, with identity management systems, I can see it on the Internet. But as a consumer, I'm concerned about what folks like Equifax might do with our data.

With some sort of identity bank.

Today, you can "freeze" your credit report, which means that no one can get your credit data. It's like you're invisible.

Let's move towards a list of VRM principles, a la Kim Cameron's Laws of Identity. Then we could have a shared understanding of what it means to be VRM.

So.. it's not VRM unless it...

1. It has to come from the user side (is the user side)
2. Has to help vendors as well as users
3. Has to work across multiple CRMs
4. Has to be based on open standards (can be proprietary, but interoperable)
5. Has to facilitate/support
   1. transactions
   2. relationships
   3. conversations
6. Allows selective expression (Iain's x,000 variables)
7. Acts as a bridge to the physical world
8. Works on multiple devices
9. Must be compatible with the Seven Laws of Identity

One of Kim's law's is that unless it works with any and all protocols that might be used, it isn't a meta-system. (And it needs to be a meta-system).

Is VRM about relationship management or a go-to-market tool?

Is this upturning capitalism? Making the users go out into the market? Why isn't it more useful to just use Froogle?

The idea is to get it out of silos and give users control of it. Not to give vendors control over what they can and cannot share.[not sure I got that right. -joe]

We need a short, specific list of use cases so we can start to identify technologies and protocols for supporting it.

TagCommons (Tom Gerber, et al). They have a single blog entry with a canonical list of use cases. You /can't/ read that list and not come away with a clear understanding of what they are trying to solve.

Wrap up

Coming up.

• something next to SuperNova at the end of June.
• Doc's going to be visiting with Google on Checkout (informal)
• In the UK, we are getting a bit of a critical mass and so sometime around Guade c (Gnome-related) in mid-July.

As we start compartmentalizing what we are doing: law, technology, identity, etc., we need to think about how we coordinate that.

XDI is right up this ally. You may as well call it the VRM protocol. We should have a 1.0 spec out this summer. All of the VRM access-controlled data services are enabled by XDI, so this should be a huge enabler.

Why can't my shopping cart be used at more than one site?

A customer-contolled UPC offers the potential to enable transactions across vendors.

Think: Problems, Policies, Protocols as a triplet for each use case.

What are the primary limitations in this system? We need code so that there will be services and capability on both sides.

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

Notes

Agenda

Lot of action and energy picked up.

Iain Henderson and Alan Mitchell have made good progress with the "flow chart". Many thanks to them.

Action Items

what	who	when	status