Category: User centric

Separating apples from oranges

Dick Hardt of Sxip posted a reply to my recent comments on the fears I have about attacks on OpenID:

My good friend Kim Cameron posted the following misinformation on OpenID:

InfoCards change the current model in which the user can be controlled by an evil site. OpenID doesn’t. 

If a user ends up at an evil site today, it can pose as a good site known to the user by scooping the good site’s skin so the user is fooled into entering her username and password.

An evil site proxying a web based OpenID Provider is a known security threat in OpenID. There are a number of ways of thwarting this attack, and given that the user has a close relationship with their OP, not difficult to deploy. Similar to the advantages that CardSpace has with a client side implementation, Sxipper is a Firefox plug-in that provides an OpenID user with the same client side protections as CardSpace. OpenID is a protocol, similar at a high level to WS-* — so this is somewhat of an apples an oranges comparison. CardSpace could support OpenID and protect the user.

I’d like to see OpenID and InfoCard technologies come together more. I’ll be presenting a plan for that over the next little while.

I’m looking forward to seeing your thoughts Kim! Perhaps supporting OpenID in Cardspace?

I'm not just talking about (realtime) proxying.  I'm talking about social engineering attacks in general.  Where is the misinformation in my description of these attacks?  

Dick reassures us that use of the protocol to help convince uers to reveal their credential is a known attack.  Should this make me feel better?  I don't think so. 

I also don't think the mitigations I've heard about are too convincing – with a couple of exceptions. 

One of those is the mitigation devised by Dick himself – called Sxipper.  This is a plugin for the browser which, as I understand it, take control away from the evil party.  If all OpenID implementations were to add this feature it would be a big step forward!

But in that case, if we want to separate apples from oranges, let's not say that InfoCards require a client component and OpenID doesn't.  Let's say that to offer reasonable protection, InfoCards require a client component and so does OpenID.  That would, as Dick proposes, properly separate discussion of protocols from the overall delivery of an identity solution.

Use of a hardware token at the OpenID site also mitigates the social engineering attack, though not the man in the middle attack.

More later about how Cardspace and OpenID can converge further.

Bill Barnes is CardCarrying

Bill  Barnes is more responsible for crafting the Cardspace user experience than anyone on our team.  Now, he's not only working on next generation Cardspace, but tackling the user experience issues that arise when integrating InfoCards into web sites (e.g. “how to build a relying party?”.  Of course, this is an on-going project and – great news – he'll be using his new CardCarrying blog to express his thinking and develop ideas.  For those interested in InfoCards, this is a “must-subscribe”.  Here's his take on what he's doing: 

Information Cards are a new approach to digital identity. So new that I’ve noticed an interesting phenomenon – in the hundred or so times I’ve presented our idea, to audiences of all kinds, it always takes the better part of an hour to convey. Sometimes more. And I’m a good speaker.

This shouldn't be surprising. They’re new, and one would expect the concepts to take a while to sink in. I remember the first time I saw the World Wide Web, then just a few months old. I just didn’t get it. My friend did a very admirable job as visionary, but it didn’t click. Same thing with TiVo. Again, I’m not dumb, not that dumb anyway, but new ideas take a while to filter in.

And Information Cards have it worse. They’re not just new, they’re different, and different is harder. You don’t just have to learn, you have to unlearn. This helps explain why security experts often take the longest to grasp what we’re doing – we’re forcing them to go back to first principles, and for many of them that’s a long way back. But even my mom has to unlearn passwords, and that won’t happen instantly.

I love to talk, I do. So I don’t mind speaking for the better part of an hour if that’s what it takes to get someone up to speed. But I have two jobs. My busy schedule simply won’t allow me to teach Information Cards to every man, woman, and child on the Internet today. How are we going to educate them? More to the point, how will website X, which thinks supporting Information Cards will garner more customers from increased security and convenience, educate them?

The good news is, not everyone needs to understand the end-to-end meta-architecture. They just need to understand what they need to make it work. One of the reasons we adopted the Card metaphor was that it brings with it some intuition. Hopefully, then, a given website won’t have to do very much explanation.

Here’s what I think they need to know, in language that I am continuing to develop. My hope is that, with these few key concepts under their belt, the flow of the website plus the user experience of their identity selector, be it Windows CardSpace or a competitor, will be clear enough to take them the rest of the way. So, without further ado:

Information Cards are like digital versions of the cards in your wallet. You can make personal cards for signing in to websites – they are like passwords but are much harder to steal. Personal cards are stored on your computer, and you can use a single card to sign into multiple websites.

You can also download managed cards from organizations like banks, associations, and businesses. When you want to prove something about yourself to a website, for instance “I am a member of club X” or “I work for company Y”, show that website a managed card. A managed card is stored on your computer, but the information it conveys is not.

These are the key points I think people need to understand. And the second part, managed cards, isn’t necessary if your site doesn’t take managed cards, and that’s most of them out of the gate. So really it’s one paragraph, three sentences, four or five concepts.

Don’t get me wrong, I think four or five concepts is a lot, and I don’t expect everyone to get it right away. I think inevitably what will happen is that a small group of geeks will learn these concepts deeply, and start to evangelize them in the blogosphere, in media, and to their parents. A good analogy here is RSS. My experience in that hardly anyone outside the technorati knows what it is yet, and very few people will bootstrap themselves simply by seeing that magic orange square. Conversions happen one at a time, from one satisfied (and informed) customer to another. My mom will use Information Cards because I tell her why she should.

I have heard some other great ideas about educating people. More on these later. Meanwhile, let me know how you would educate a user at your website on what Information Cards are, and why they should use them at your website. Would you use my language or a variant thereof? Share the love.

Oh, one more thing. I’m not speaking in an official capacity here, but I don’t think it’s reasonable to expect Microsoft or anyone else to mount a giant P.R. education campaign on Information Cards, any more than you would expect them or anyone else to convince you to use RSS. If it’s really a good technology (and I think it is) it will succeed because it is in everyone’s benefit when it is used. So I think everyone shares the educational burden. So get teaching.

Virtual gardens with real-world walls

Here is a fascinating piece from OZYMANDIAS that oozes with grist for the User Centric mill.  This seems to be about walled gardens with barbed wire.  Please don't take what I'm saying as being critical of Sony in order to puff some other company (like, er, my own).  I'm talking about the general problem of identity in the gaming world, and the miserable experience much of the current technology gives us.  I think I should be able to represent my gaming personas as Information Cards – just as I would represent other aspects of my identity – and use them across games (and one day, even platforms) – without linkage to my molecular identity. 

News on the web today is that Xfire is suing GameSpy for how their GameSpy Comrade “Buddy Sync” feature creates friends lists. To quote:

Now Battlefield 2142 is caught up in a legal tangle between rival in-game instant messaging programs Xfire and GameSpy Comrade. On October 16, Viacom-owned Xfire filed suit against News Corp subsidiary IGN Entertainment over its GameSpy Comrade program, which comes on the Battlefield 2142 disc. IGN Entertainment also owns IGN.com, a GameSpot competitor.   

Xfire is claiming that GameSpy Comrade's “Buddy Sync” feature illegally infringes on its copyrights. Buddy Sync retrieves users’ friends lists from other instant messaging programs like AOL Instant Messenger and Xfire, and gives players the option of automatically inviting those friends who have GameSpy accounts to join the users’ friends lists on Comrade.

If you read a bit deeper you find that what's basically being challenged is GameSpy's use of information (friends lists) that has been publicly published by Xfire on their website. Xfire claims that GameSpy's reading of that data is to enable GameSpy to bolster their own friends lists:

In a filing in support of the restraining order, Xfire CEO Michael Cassidy specified how his company believes the Comrade program works. First, Cassidy said it reads the user's Xfire handle from the XfireUser.ini file, then visits a formulaic URL on the Xfire site to get a list of the user's friends (for instance, to find the friends list of Xfire user Aragorn, Comrade would go to http://www.xfire.com/friends/aragorn). The names on that friends list are then compared with a central IGN database of Comrade users’ Xfire handles, and if any matches turn up, the user is asked if they want to invite those people to their Comrade buddy lists.

I am not a lawyer, and can't definitively comment on whether information that's made public in this fashion can or cannot be harvested. My gut is that it's probably kosher – we have plenty of website scraping applications in the wild today that do just this, including best price searching sites. What does fascinate me is how this suit highlights how busted Sony's PS3 online network is, and how companies are fighting to position themselves to take advantage of this financially. Bet that seemed to come out of right field. Wink But here's where I'm coming from.

I wrote earlier about why Sony's enabling of Xfire for PS3 games wasn't as exciting as it might seem. Take a read, and then let's talk about just what the experience of being an online user on PS3 is likely to be like.

So I buy my PS3, bring it home, and go online. The first thing I'm going to be asked to do is create some sort of Sony Network ID. That “Sony ID” will apparently bring basic presence and communication features via the crossbar interface. So far so good. Now I decide to play Insomniac's Resistance, which recently stated the following:

Insomniac's Ted Price: “The buddy list is specific to Resistance. And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game. The buddy list tab is where you can access your friends, ignore list, messages, etc.”  

1Up (to reader): “Does this mean there's a system-wide friend's list, but you have to compile game-specific friends lists for each online game you participate in? That doesn't make much sense, and hopefully today's event will clear up the situation.”

Yes Virginia, that's exactly what this means. Even though I already have a “Sony ID”, I may have to create a new “Resistance ID” to play. And then start thinking about just how broken the experience is when you try to invite someone to a game. Do you send it via the Resistance UI? What screenname do I send it to? If I want to add you to my “Sony ID” friends list, do I need to send you an in-game message to ask you what your real “Sony ID” name is? What about game invites? How does that work across even just these two IDs?

You think that's bad? Now let's open up a few more games from different publishers. Each of these publishers had to make a choice of what online interface to use – again, because Sony's online network just isn't ready. So they'll choose between writing their own (as did Insomniac for Resistance), or perhaps licensing Xfire, or GameSpy, or Quazal, or Demonware. So now we have five potential networks with different namespaces, and an inherent  lack of ability to communicate (chatting, voice, invites, finding friends, etc.) between them, and even across to just the “Sony ID” namespace. Think we're done? Nope… what happens if each publisher doesn't stick with the same online solution for all of their games? This is very likely as most publishers use different developers – so even across a single publisher, you may find fragmented communities.

The only consistent tie all of these different community fragments has is that a user should always have their Sony ID. That gives you a lifeline to be see friends when they are online… but only in the crossbar UI. Will you even be able to see what game they're playing? What about what network that game uses, and whether that friend is logged into it? How will you get messages in a timely manner? Remember Ted Price's quote above? “And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game.” Doesn't sound like a user-centric design decision to me.

So… back to Xfire and GameSpy. I said earlier this suit is a direct result of how busted Sony's online network appears to be, and I just described some of the issues you'll likely be facing later this month. Yes, it's targeted at a PC title right now (Battlefield 2142), but that's just noise. What we're really seeing with this suit are online middleware companies trying to position themselves to become the eventual defacto solution that publishers will use. Just as with web search and instant messaging, these companies are trying to get momentum and user base that will cause them to be the “PS3 online” solution of choice. And this suit is simply one of many battles we'll see in this space, especially as PC and console crossplatform connectivity becomes more important in the coming years.

When my role as a player is really valued, I will be seen as owning my own buddy list.  Using zero knowledge technology, it will be possible for me to hook up with any of my buddies’ personas – across various games and without committing sins of privacy.

 

Ping unveils Managed Card IP written in Java

Ashish Jain of Ping Identity seems to have broken another barrier by demonstrating a “managed card” identity provider written in Java.

In the world of InfoCards, we talk about two kinds of “identity provider”.  One is a “self-issued” card provider, through which individuals can make claims about themselves.  The other is a “managed” card provider, which supports claims made by one party about another party. 

Examples of managed card providers could include claims made by an employer about its employees; a financial institution about its customers; an enterprise about its customers; or a reputation service making claims about its users.  While the technology for posting tokens from an identity selector like Cardspace to a web site can be very light weight (RESTful), that for building managed card providers is more challenging.

Here's how Ashish puts it:

The Managed Card IdP as well as the RP server that we demonstrated at DIDW is now available for a test run. It’s still early access…so expect some issues. But if you do want to try early, give it a go. It should give you an idea of the things to come.

baby_beer400x299.jpeg

Please do the following (you need to have RC1 client installed on your machine).

  • Access the IdP Demo here.
  • Enter your information and click ‘Get Card’.
  • When the popup happens, click “open” to save it to the CardSpace Client. Alternatively, you can save it to the disk and double-click to install it. (You can change the extension from .crd to .xml if you are interested in looking at the contents).
  • Close the CardSpace Client.
  • Next go to the RP site here.
  • Click on the Managed Infocard Image.
  • Your CardSpace client should pop-up at this time and only the relevant card should be available for selection.
  • Select the card and it will challenge you to enter your IdP credentials. The server doesn’t perform any password validation at this time (as long as the username is correct).

And you should be logged in to the Relying party. The relying party page also displays the IdP as well as the RP message flow.

I tried it and it definitely worked for me.  I'll do a screen capture.

I don't know if the picture in Ashish's piece shows something he drank as a baby, but if so, a lot of other programmers may want to try some. 

 

DasBlog site InfoCard enabled

Of course Kim Cameron's Identity Blog has been InfoCard enabled for a while, and I've written about the process.  Now others are working (more on this later) to produce a WordPress InfoCard Plugin for everyone who wants to start accepting InfoCards.

Then a while ago I learned that Rob Richards had InfoCard-enabled his Serendipity-based blog and again published the code for others to examine.  

Now Kevin Hammond has done the same for DasBlog – though I'm not sure yet if I can leave comments using InfoCards:

Taking inspiration from Kim Cameron and how he CardSpace-enabled WordPress, I did the same with DasBlog 1.9.6264.0. casadehambone.com now supports logging into the administrative account using Windows CardSpace allowing me to throw the use of passwords to the wind!

The great thing is that it only took minor changes to three source files and the introduction of one new configuration option each to site.config and siteSecurity.config. I have a little more work before me to make configuration just a tad easier, but the great thing is that this works really well.

I owe special thanks to Clemens Vasters who suggested this morning that the proper “hack” to get this working was to build DasBlog with Visual Studio 2005 and the Visual Studio 2005 Web Application Project add-on. DasBlog built out-of-the-box without issue, making the integration of TokenProcessor.cs to decrypt the SAML token a piece of cake.

If you haven't looked at Windows CardSpace yet, head on over to cardspace.netfx3.com and start reading. Now that Windows Internet Explorer 7.0 is released and Release Candidate 1 of .NET Framework 3.0 is available, you'll find the mainstream barriers to adoption are quickly eroding.

I hope Kevin also publishes his code so others can learn from it.

BBAuth and OpenID move identity forward

I read this piece by Scott Kvelton and wanted to make it clear that my concerns about user experience when using protocols that redirect you from site to site to site were not meant to put down the positives that both those technologies represent. 

I think BBAuth and OpenID both move identity forward.  Count me in as a supporting that.

I‘m just saying that I think we should co-operate to fix the redirection user experience, and replace it with something that is way less phishable. 

Scott says:

Lots and lots and lots and lots of discussion going on regarding BBauth and OpenID 

Kim Cameron had an interesting post today concerning the interface issues with BBauth as well as OpenID:

My concerns really originate with the user interface issues. And OpenID has the same problems to the extent that people end up with multiple identity providers (which they will).

I appreciate Kim’s passion about InfoCards and the concept of a consistent user interface. I think its a fantastic idea. So let’s be pragmatic about it. We’re here today: no consistent user interface, lots of usernames and passwords and phishing is a huge problem. We want to get here: consistent user interface, one username and password and phishing becomes a thing of the past. Great. Where do we start? I don’t think InfoCard is the answer. Let me explain.

How do we know InfoCard provides a great interface for users? When I first saw and used an InfoCard it freaked me out. “What the heck is popping onto my screen?!” Talk about a paradigm shift. Answering the this-is-a-great-user-interface question is an iterative process. It takes time and lots and lots of user input.

My answer?  You build interfaces and test them.  You look at the numbers.  You test phishing approaches on a wide assortment of people.  You find out what works and doesn't, and keep evolving the interface.  If we take this as a starting point, we'll all end up agreeing.

The problem with redirection within the conventional browser is there is no way to know for sure where you've ended up – especially if you aren't a network engineer. 

The fact is we have no idea how users are going to use user-centric identity so how can we make assumptions about the user interface today that aren’t iterative?

But if this type of SSO were to become a massive success, that success would bring about its downfall. For it would then be worth attacking and very vulnerable at the same time.

If something like OpenID or BBAuth takes off, there won’t be a downfall. The platform will continue to evolve and get better. Is InfoCard the final and complete answer? We have no idea. The real question is which platform is best suited to constant evolution? Like Kim is a broken record about InfoCards (his words, not mine), I’m the same way about OpenID … 🙂 I believe OpenID is best suited to this kind of evolution.

Sorry – the redirection aspect of the incremental UI is still, in my view, vulnerable.  None the less it's a step forward from where we are today.  I'm not arguing that InfoCard is the final word on anything.  I'm arguing that it helps you deal with multiple identity providers, eliminates “redirection attacks”, prevents the evil site from being in control of the user experience.  Surely these can't be seen as bad things?  OpenID could take advantage of them by including support for that interface.

Kvelton concludes: 

OpenID is incremental by its nature. Its not a quantum leap. Its a URL. Users today are starting to think more and more in terms of URL’s … just ask a MySpace or blog user (I have cold hard data on this one; my babysitter is a MySpace user). Its iterative. We’re not trying to boil the ocean in the first go at this. We don’t know how users are going to use this thing. So let’s make the fewest number of assumptions for the users before we deliver something. Watch how they use it, find out what makes sense. Repeat.

A lot of users will be fine with URLs for their public personas.  But I fear they can still be phished during redirection.

Is BBauth, CardSpace or OpenID the end-all-be-all solutions for single sign-on? Definitely not today. One thing is clear though; companies and users alike are seeing the value of user-centric identity and its slowly but surely happening; CardSpace, OpenID and BBauth are clear indications of this. This stuff doesn’t happen overnight but the ship is slowly turning in the right direction.

There is wisdom in this.  But if Kvelton is against giving the InfoCard visual metaphor a try, then I don't get it.  It does nothing to undermine OpenID.

 

Hans gets more specific about Yahoo BBAuth

Several readers have asked me to comment on the recent post by Verisign's Hans Granqvist about “security problems in BBAuth”.  He writes:

I have had concerns about Yahoo!’s choice of security of BBAuth. Jeremy Zawodny responds to my posting to ydn-auth list:

“While I can’t comment on the choice of algorithm, I can say that some of the technology used in BBAuth was not developed solely for use with BBAuth.

Okay, fair enough.

But then he continues:

“In other words, we’re reusing some existing stuff that’s been tested in the field and proven to work well for our needs.”

Now, this doesn’t sound right. Not at all.

MD5 has been broken for a few years now. According to Ferguson’s and Schneier’s Practical Cryptography it’s possible to find MD5 collisions in 2**64 evaluations (using the birthday paradox). This was too easy 2003, and it sure is not more difficult now.

Be that as it may. Perhaps these collisions are purely academic.

What’s worse is the lack of a proper HMAC. In Yahoo!’s BBAuth, the MAC is created by hash(text + key) where ‘+’ denotes string concatenation.

This simplistic way of building a pseudo HMAC scheme is not secure. Readers of Practical Cryptography may want to turn to section 7.5 for more information. In short, tacking the key on to the end leads to key recovery attacks that are much easier to execute than they should be.

What scares me is that this broken scheme apparently is used in plenty of other Yahoo! products. I would not be surprised if there are attackers trying to exploit this weakness at this very moment.

My advice to Yahoo! is to change this to a proper HMAC right now. Other identity protocols, like OpenID manages to require HMAC-SHA1 or HMAC-SHA256. There are OpenID libraries for all major programming languages available, so it’s definitely not too hard to implement.

My thinking?

I believe that when it comes to security, it's better to use an algorithm that has been widely vetted (like HMAC-SHA256), and to avoid creating new ones unless you really need to – or have a long runway to test them on.  I also think protocols should use algorithm identifiers.  With security, it may become necessary to migrate to new algorithms when we least want to, without blowing all the downlevel clients out of the water. 

But despite my “high-minded principles”, if you look at the actual content of what Hans calls “text” in the BBAuth protocol, it looks to me like it is full of entropy (a good thing): although it contains some fixed information, it also contains a token, which is variable and not calculable by an evesdropper; a timestamp, which makes long-running attacks impossible; and a shared secret, which makes multi-site catalog attacks impossible.  So this is not toy cryptography given Yahoo's purposes.  That isn't to say Hans doesn't make some good points.

My concerns really originate with the user interface issues.  And OpenID has the same problems to the extent that people end up with multiple identity providers (which they will).

I'm talking about the fact that users are redirected from one context to another quite different one.  We have found that systems that work this way introduce a lot of “noise” – let's call it ambiguity – into the channel between the system and the user. 

The user can be confused – by accident or, worse, on purpose. 

It's the “I'm-buying-a movie-from-someone-but-now-I'm-at-Yahoo-and-now-I'm-not” problem.  In the midst of the redirections, the user can potentially be redirected to a wolf-in-sheep's-clothing, who can relieve her of her secrets and employ them for other purposes. 

Suppose that Google and MSN and AOL and eBay all do the same thing as Yahoo.  Then things would get really confusing for the user, wouldn't they?  As she visits different sites she would find herself redirected to a bunch of different home pages…  MSN here, AOL there, and who knows what else.  This kind of redirection is just not good from the point of view of users being certain about what's happening.  It's similar to getting a URL in an email.  This is one of the main reasons I think that a strong, consistent visual experience like InfoCards is key to building something safe, and why I want to see all of this converge.  But of course, everyone knows I'm like a broken record on this.

Some of my concerns may not matter much when it comes to controlling access to your photos.  But if this type of SSO were to become a massive success, that success would bring about its downfall.  For it would then be worth attacking and very vulnerable at the same time.  That's why I think it is best to combine it with the type of experiential system I've been talking about before any of these problems arise.

 

 

Everyone's coming to the party

New marketing “inspirational speaker” (did I say the right thing?) Deborah Schultz bridges us into a marketing world waking up to the fact that the consumer is indeed in control.  I find the confluence of user centrism really amazing – it lets us move up a level and see our identity work in light of related social trends:

msacrossedfingers.jpgSo while the blogosphere was speculating on the now confirmed Google/YouTube deal over the weekend, the annual ANA Masters of Marketing conference took place in Florida.  As reported in the NY Times today as well as on various marketing blogs, it seems that the big advertisers and marketers are waking up to the fact that the consumer is indeed in control. This probably has a lot to do with visions of dollar signs dancing in their heads.   

So, the big guys now know the buzzwords and are ‘talking the talk’.  My fingers are crossed that they can indeed ‘walk the walk’.

Page Views and Banner Ads alone will not cut it in the new marketing universe and there really are no shortcuts.  New metrics and a new cultural shift is needed. As per Pete Blackshaw's recent posts here, here and here (yes, I love Pete's stuff) and Steve Rubel's column in Adage discuss – engagement is more than ‘asking your customer's to create content for you.

Until the INTENT of the customer is addressed (i.e. engaging with me when and how I want and need you to) I fear we will just be creating ever more Dove real beauty ads and derivative Mastercard Priceless commercials.  Hey, I am happy the big guys are taking note, but true change will only happen when CRM changes to VRM (I remain and am always a Doc protege).  As Kim Cameron eloquently put it:

The way I read Doc’s ideas, he’s talking about a real inversion of what advertising is and means.  Instead of suppliers advertising what they want us to buy (by spamming our attention), we’ll advertise what WE want to buy, and suppliers will make us offers.  Sounds a lot more efficient to me.  What am I missing?  Why doesn’t everyone want to do this?

Maybe because a lot of what advertising is about is getting us to want things we don’t know we want.  But even that can be done in other better ways too.  Like by producing cool things and having them explode into discussion.  Doc said this too, didn’t he:  Markets are conversations.

Let's see if the big guys have the patience required to ‘get it’.  I remain hopeful yet skeptical. 

It sounds to me like the timing is right to get the geeks and the marketers together for an old fashioned “throwdown” on getting past jargon and discussing how to get this done to the benefit of BOTH sides..  Stay tuned!

They once just loved me for my credit card…

Doc's Vendor Relationship Management concept is getting clearer and stronger all the time.  And now I see how and why it ties in to his “Markets are relationships” mantra, eclipsing his tremendously influential, “Markets are conversations”.

For me it's an aha moment.  Sort of like figuring out that you are part of a relationship problem, and not simply a victim of it.  Maybe we really can use technology to move even large companies towards rich relationships with individual customers, responding to an expression of their needs that they own and control. 

In the old world, only corporations and governments had computers to help sort out their problems.  That created a transient situation I have called historically upside down. 

In the new world, individual people can have their own computerized systems helping them just as enterprises do.  And most interesting, these systems can potentially interwork with those run by enterprises.

Doc's VRM proposal is an example of this.  And what's great about his explanation is that we can see how both sides of the relationship end up benefiting.  Have my robot do lunch with your robot – they'll come up with something.  Here's Doc's piece:

Responding to what what says here (which enlarges on what I said here) Kim Cameron replies, “This is exciting stuff – I'm talking Identity Big Bang content.” He adds,

The way I read Doc¹s ideas, he's talking about a real inversion of what advertising is and means. Instead of suppliers advertising what they want us to buy (by spamming our attention), we'll advertise what WE want to buy, and suppliers will make us offers. Sounds a lot more efficient to me. What am I missing? Why doesn't everyone want to do this?

Yes, except I also think it's important not to understand VRM (Vendor Relationship Management — the reciprocal of CRM, or Customer Relationship Management) as the reciprocal of advertising. Or the opposite of advertising. Or even the opposite of marketing. I don't think it helps to frame it in terms of any of those things. 

It's something new. Rather than advertise, we notify. We assert. We express. I don't care what we call it, as long as what we do doesn't come across as individuals being just as bad-mannered as advertising has been for the duration.

Kim also says,

Maybe because a lot of what advertising is about is getting us to want things we don¹t know we want. But even that can be done in other better ways too. Like by producing cool things and having them explode into discussion. Doc said this too, didn¹t he: Markets are conversations.

Also true. But VRM isn't just about conversation. It's about relationships. And transactions.
 
We've always understood markets in terms of transactions. We wouldn't have markets (or economics, or business schools), without them. And lately we've begun to understand markets in terms of conversations as well. But relationships remain a wild frontier.
 
On the vendor side we've talked and coded ourselves into assuming we have relationships with customers. But CRMs don't relate. Worse, they are delusional about relating. Here's how Wikipedia currently puts it:

Customer relationship management (CRM) covers methods and technologies used by companies to manage their relationships with clients. Information stored on existing customers (and potential customers) is analyzed and used to this end. Automated CRM processes are often used to generate automatic personalized marketing based on the customer information stored in the system.

Wow. Can't wait to make love to that.
 
When you read down through that whole Wikipedia entry, you see how CRMs actually mean to be nice, to respect the customer, yada yada. The problem is, they bear the full burden of a relationship that doesn't exist, because there is nothing much to relate to on the other side. Or worse, the only mechanism for relationship is the one that facilitates the transaction: the credit card.
 
We need to equip the customer with something that facilitates relating to vendors — and takes some of the relationship burden off the vendors as well. 
 
The relating may be enduring or transitory. It may involve disclosing some identity information; or it may keep us anonymous (while disclosing other information that's useful). It must, however, be useful to both sides. We don't have that with advertising (which, aside from all the waste it involves, brings the wrong perspective and sets of assumptions to the problem).
 
I like Dave's prototype idea for “a movie review system where I own and control my data”, because it's a great first step. It's says to Vendor CRMs, “This is my data, and it's independent of your silo. And that makes it more valuable to both of us than it would be if it lived in your silo alone.”
 
We need to discover some what VRM can do before the rest of it can become clear. Which it will. Inevitably.
 
Bonus link.

Very strong stuff – and has such a nice balance.