Abstract

There are - and should be - many different approaches towards the implementation of Vendor Relationship Management (VRM); this is neither undesirable nor problematic, since VRM's goal of enabling a person to "have control of their own data" can and will doubtless be achieved in many different ways.

So far most discussion around the architecture of VRM implementation has been "identity-centric" - the terminology of internet "identity" technology has been adopted and serves as a touchstone to guide how VRM-enabling applications should behave, and what functionality they should offer to their users.

We offer an alternative "web-centric" description and architecture for VRM, leveraging concepts from familiar technologies such as browsers, feeds, blogging-software and Ajax applications, in order to provide VRM functionality in a different manner, with a lower barrier to adoption, lower "time to market", and with a different approach towards data-management. what about user-centric and its distinction from user-driven? -Adriana Lukas 2/6/08 10:22 AM update: the distinction is covered in the blog post Two tales of user-centricity.

Our goals in this paper are to:

1. invent as little as possible
2. reuse only popular technologies, techniques and user-interface metaphors in order to enable VRM, and...
3. provide maximal inclusiveness and extensibility to the VRM implementation, to permit the greatest potential for growth.

Glossary

VRM User

You, the person who possesses VRM software and seeks to use it to share information with third parties.

 

VRM Document (or just "document")

a data file of arbitrary format, which might usefully be shared or published via VRM; examples include but are not limited to: vCard, hCard, iCal, JPEG, PDF, MP3, HTML, XML; a VRM Document should have a IANA-registered content-type and subtype (eg: "text/csv") or have a widely recognised x-token (eg: "text/x-vcard"). See IANA

 

VRM Object (or just "object")

a VRM Document which has been superencoded (if necessary) to be fit for direct, literal inclusion within a VRM Feed's structure, possibly with the inclusion of tags or other metainformation describing the document.

 

VRM Feed (or just "feed")

a series of one or more VRM Objects which have been encapsulated in a popular web syndication format, as described below. The feed's URL will also provide a simple API permitting retrieval of individual VRM Objects, encapsulated in a feed "wrapper" for orthogonality.

 

VRM Friends (or just "friends")

the set of vendors, associates, personal friends and other third parties who possess the necessary individual credentials to access (ie: "subscribe to") some or all of a VRM User's feeds.

A Note On Self-Assertion

Several previous VRM use-cases have been advanced where two parties must attest to the content of a document - for instance one specifying the number of AirMiles that passenger "John Doe" has available to spend; such a document might usefully be simultaneously asserted as correct by both "John Doe" and "United Airlines".

These assumptions have led to greater complexity of the proposed VRM solutions to date, so for this discussion we shall assume that such "joint assertions" are unusual boundary cases and instead we shall focus primarily upon "self asserted" data, returning to "jointly asserted" data if the need later arises.

Version 0.1 : Saving You Some Typing

At its most fundamental level the technical challenge of VRM is for an individual to electively and securely share information with a number of other parties who have an interest in that information, and for the parties to be able to respond to the information owner.

At the IIW2007b conference, Muffett proposed a step towards "Feed-Based VRM":

"If I am signing up with an online Bank and I need to give them my mailing-address, rather than filling out several input boxes with the same old information again and again, why can't I just paste them a URL to where a vCard resides on my webserver, which they can retrieve to get the information, show it to me, and I can confirm it? And if I move house then I can update the vCard and they can get it again and again..."

...where 'vCard' is a standard data format to encode names, photos and other business-card information, used for instance as an export format for Apple's "Address Book" application. See [VCARD]

hCard is more suited as it can be on the main webpage easily, but the principle is sound -Kevinmarks 1/17/08 1:48 PM 

This example was chosen specifically to address the use-case narrative being examined at IIW2007b, the 'Change of Address' narrative:

http://blog.joeandrieu.com/2007/12/11/the-hard-stuff-vrm-use-cases/

Use Case Narrative

 

• AddressChanger decides to move
• AddressChanger expresses new address to system (optionally including scheduling information)
• AddressUsers get the new address when they need it
  

Requirements

 

• Address stored independently of any particular vendor
• Owner of address can choose who stores canonical source (self-storage ok)
• Data should be in an open format and portable without data or service loss
• Data transfer and use is always under user control
• Vendors can discover the appropriate service for each user

Supporting Use Cases

 

• AddressChanger Changes Address (base case)
• AddressChanger Manages Address Holder Permissions (and data subsets)
• AddressChanger Accesses Audit Report
• AddressChanger Reviews Address
• AddressUser Gets Current Address (pull)
• AddressUser Subscribes to Address Changes (push)

...but even with its extreme simplicity, the idea fulfills about 12 of the 14 given use-case bullet-points:

AddressChanger decides to move

is my choice, so is possible

 

AddressChanger expresses new address to system (optionally including scheduling information)

means "I update the vCard", thus possible; though scheduling is not available in v0.1 example

 

AddressUsers get the new address when they need it

means "They fetch the current vCard when they need it", thus possible

 

Address stored independently of any particular vendor

is possible; any webserver will do

 

Owner of address can choose who stores canonical source (self-storage ok)

is possible; ditto

 

Data should be in an open format and portable without data or service loss

is possible; vCard is an open format

 

Data transfer and use is always under user control

is possible, if rather coarse ("all or nothing")

 

Vendors can discover the appropriate service for each user

can be addressed with some extra work

 

AddressChanger Changes Address (base case)

requires me to move, which is possible

 

AddressChanger Manages Address Holder Permissions (and data subsets)

is possible, if rather coarse ("all or nothing")

 

AddressChanger Accesses Audit Report

means "I read my Apache logfiles", which is mostly possible

 

AddressChanger Reviews Address

is possible if unnecessary as I own the data and am thus definitive

 

AddressUser Gets Current Address (pull)

is the exactly the whole point (ie: possible)

 

AddressUser Subscribes to Address Changes (push)

is not the model we are proposing here (ie: not possible in v0.1)

...and In this list we are missing only two requirements ("vendors can discover"; "subscribe to pushes") and one half ("optional scheduling information").

Version 0.2 : Keeping All Your Addresses Up To Date

The possibility of fulfilling more than 80% (about 12/14) of a VRM use-case merely by posting a vCard to the web is exciting; it also suggests that hopefully some of the remaining functionality might be obtained without needless complexity.

This led to version 0.2 of the proposal, suggested by the desire to provide one's address vCard to multiple banks, with some degree of privacy:

Alice owns the domain "www.foo.com" and has installed VRM-software upon it; she is signing up with two banks - Bank1 and Bank2 - and wishes not to retype her home address repeatedly, nor suffer the hassle of updating that information next time she moves house.

She creates a vCard document - "homeaddr.vcf" - using a module that is part of her VRM software; we'll describe more about the VRM software later, but for the moment think of it as being a bit like Flickr or Wordpress.

She logs into her VRM software on www.foo.com and adds both Bank1 and Bank2 as separate entries to her "VRM friends list" - this requires no involvement from the actual banks since this is purely a convenience for her record keeping.

When signing-up with Bank1, Alice requests from her personal VRM software a Bank1-specific URL for her home-address vCard, which might look like:

http://www.foo.com/vrmget/homeaddr.vcf?key=1e974ca0d53d95a7a113968badfdb4b4

...and pastes that in Bank1's website, who may then retrieve her address and display it so she can confirm it.

When signing-up with Bank2, Alice likewise requests from her VRM software a Bank2-specific URL:

http://www.foo.com/vrmget/homeaddr.vcf?key=9797df035db1a441101f757b3cc8564d

...and pastes that in Bank2's website, who likewise retrieve the address, display it, etc.

Alice's VRM software will log at what times and from which IP addresses the information was retrieved - providing an audit trail - and will reject/log attempts to fetch the information using bad or fake "keys".

Extra information supplied by Alice could specify how often the banks should refresh their mailing-address information; should she ever wish to withdraw access by a bank to her mailing details, she merely drops the bank (and its "key") from her "VRM friends" list.

Aside from the obvious "friends-list" concept, the inspiration for this data access-control functionality was modeled upon GoogleCalendar's "Private Address URL" feature:

http://www.google.com/support/calendar/bin/answer.py?answer=34576

Your calendar's "Private Address" in XML or iCal format lets you easily view a read-only version of your calendar from other applications. Using this address, you can access your calendar from feed readers (like Google Reader) as well as products that support the iCal format (like iCal for Mac). Your calendar's "Private Address" in HTML lets you view a read-only version of your calendar without signing in to Google Calendar.

To obtain your calendar's private address, just click on the "XML", "ICAL" or "HTML" icon. A pop-up window with your calendar's private URL will appear.

Additionally, you can export your calendar information by clicking on the "ICAL" button and clicking on the displayed URL.

Note: the private address was designed for your use only, so be sure not to share this address with others. If you want to let others view your calendar, you can share your calendar's public address (or "Calendar Address") with them. If you accidentally share your calendar's private address, click on the "Reset Private URLs" link to regenerate your calendar's private address.

...although in VRM we will be generating separate "Private Addresses" on a per Bank / per Friend basis, rather than a single URL common to all of them.

In addition to some degree of authentication and access control, version 0.2's use of differing URLs per Bank implies the information owner may choose to provide different addresses to different banks (eg: homeaddr.vcf vs: workaddr.vcf) or indeed of any other information or documents which might usefully be shared.

Version 0.3 : Sharing Your Data With Your Vendor-Friends

Authentication (described above) means that only a designated set of VRM Friends can access Alice's VRM Documents, the membership of the set being entirely under Alice's control.

Since another of the fundamental goals of VRM is the ongoing sharing of a stream of data with interested parties, we should also look at how people achieve this with other parts of the web.

A critical observation is that an information owner rarely wishes only to share single, self-contained atomic items of data with other parties; in fact "mailing addresses" are a limited example of what VRM seeks to enable, and do not provide a very interesting use-case.

A better, more interesting use-case might be wine:

Bob is a wine enthusiast; he drinks a few bottles each week, and has relationships with several local wine shops who supply him. He regularly posts his tasting notes to his blog and several of his vendors have taken to reading it in order to supply him better.

There are several aspects to this use-case, both good and bad:

• use of a blog to share information; a blog is a easy way for an individual to share information with a readership with minimal administrative overhead. The information itself provides value to his readership.

   

• use of a blog to manage information: Bob's tasting notes are archived in his blog, and are thus searchable both chronologically and by keyword, and also likely indexed by lots of tags: "Merlot", "Cabernet", "white", "oaky", "eaten-with-fish" - and so forth. This "databasing" aspect provides value to Bob.

   

• chronological updates: the number of wines that Bob has tasted increases weekly; vendors are more likely to be interested in a feed which tracks Bob's past two months' worth of tastings than they are a historical Excel-database dump of everything he's ever tasted.

   

• requirement for eyeballs: generally a blog consists of free-form text; folksonomic structures such as "tags" exist to permit a degree of semantics and "machine readability" but otherwise the data in blog postings require human interpretation.

From this use-case we can infer much functionality, and refine and simplify our architecture:

• All VRM documents could/should be shared as "feeds" (like RSS or ATOM feeds) which automatically provide a chronologically ordered stream of documents (such as Bob's wine-blog postings).

   

• Where non-chronological or self-contained documents (such as Alice's home address) exist to be shared via VRM, they should be shared as a feed containing exactly one item; an orthogonality which simplifies VRM implementation.

The "reuse as much as possible" design goal suggests that we should employ one or other of "RSS" or "ATOM" to implement the "feed" technology which we are describing, since both are well-understood and well-documented formats, are well suited to the task, and are familiar technologies to millions of people worldwide so there will be minimal barrier to adoption.

However: there is a problem with RSS, ATOM and in fact most any "feed" mechanism as currently utilised by Web users...

The Problem With "Directly Embedding" Documents Into Feeds

A traditional RSS or ATOM "feed" which supposedly has non-HTML / non-XML documents "embedded" into it, typically has nothing of the sort. Instead the feed references the documents via a completely separate set of URLs; for example a podcast RSS feed contains a series of XML objects which point at a series of MP3 files which may be held on the same webserver, or even on an entirely separate server:

A feed on www.foo.com contains 4 postings; posting number 3 "embeds" (via hyperlinking)

an MP3 held on www.bar.edu, an entirely other webserver with its own notions of access control.

...and further each XML object probably also points at a HTML page (a "blog posting") which relates to each specific MP3 file.

The problem with this "indirect embedding" from the VRM perspective is one of management complexity and access control; access to VRM feeds must be restricted to their respective subscribers (that is: Bank1 and Bank2 from the v0.2 example) - but then the selfsame access controls also need to be applied to the external documents, with new and different URLs, possibly hosted on other servers.

This rapidly becomes an N-squared problem of management and security complexity. Fortunately an acceptable - if somewhat radical - solution to this is trivial to implement: Direct Embedding of the data to be shared, into the feed:

A VRM feed is entirely self-contained, self-referential, and documents contain objects which may be individually retrieved - for instance http://www.foo.com/vrmget?object=3 in this example, which would yield a single-object feed encapsulating the "VRM document" which in turn contains the encoded JPEG. Object numbers would increase incrementally over time and not be reused;  objects which are not XML/HTML friendly would be "base64" encoded and embedded.

Or microformat-encoded (works fine for hCard etc), You could stay in HTML and use data: URLs if you want blobs inlined, though I woudln't recommend doing this for audio  -Kevinmarks 1/17/08 1:53 PM Fixed Thanks! -Alec Muffett 1/18/08 12:06 AM

In a tremendous feat of self-centeredness, the feed can be structured so that permalinks for objects in the feed refer directly back to the same feed, with some extra syntax to narrow the feed to refer to a single object, for instance:

feed url: (not functional for general public)

http://www.foo.com/vrmget/address.vcf

retrievable by Bank1 as:

http://www.foo.com/vrmget/address.vcf&key=1e974ca0d53d95a7a113968badfdb4b4

thirtyfirst object in feed: (not functional for general public)

http://www.foo.com/vrmget/address.vcf?object=31

retrievable by Bank2 as:

http://www.foo.com/vrmget/address.vcf?object=31&key=9797df035db1a441101f757b3cc8564d

...and so forth; so long as the VRM implementation is predicated upon receiving feeds of one or more objects which are encoded and embedded into a feed in a standard way, and so long as the contents of the feed are individually indexable by use of arguments to the feed URL, then we have sufficient functionality for VRM to work without having to manage external objects / documents.

But how shall we encode and embed the documents?

How Shall We Embed The Data, And What Will It Look Like?

Consider Alice and Bob:

Alice's address vCards are very strongly structured data documents but are not necessarily XML-compliant, nor suitable for embedding into a feed.

Bob's wine postings are free-form, human-readable and may be tagged for convenience, but in general they are certainly not strongly structured.

So: although VRM data should clearly be shipped, shared, published, encapsulated or embedded in a "feed", precisely how should it be encoded in order to make it feed-friendly?

One obvious solution to the above is to restrict ourselves to use of XML-friendly "microformats" which can be encapsulated by a RSS or ATOM feed without complaint from XML parsers.

So - in this - we would force Alice to give up "vCards" instead for "hCards", which were designed to be perfect 1-for-1 XML-compliant analogues of the vCard format, exactly to solve this problem.

This is delightfully convenient, but alas it is also constraining; XML microformats may already exist for postal addresses, probably music and perhaps for wine, but what about for cheese, bread, rocking-chairs, maine-coon cats, hoovers, dachshunds and haircuts?

Straw man - the same problem exists with any other non-existent format. You can use POSH to mark them up and evangelise them as formats later. -Kevinmarks 1/17/08 1:56 PM 
I don't think I see it that way; my thought was that creating formats in "plain old semantic html" is still an act of creation, which violates one of the rules above; hence my push towards encapsulation and using the feed as a transport for arbitrary pre-existing formats, and heavy example use of non-XML-friendly formats. Does that make sense? -Alec Muffett 1/18/08 12:16 AM

Well, then pick examples where pre-existing formats exist then, not silly "make up your own XML cruft" ones, my contention with all this is that it is the agreement on semantics that is hard, and microfromats try to slev that hard part, rather than punting on it like XML and RDF do -Kevinmarks 1/17/08 5:26 PM 

A VRM solution which is inclusive of non-XML-compliant formats will be more widely leveraged and creatively extended than any which imposes syntactic constraints upon the data it distributes.

There are two obvious solutions to the challenge of inclusivity:

1) Encapsulate any arbitrary VRM document - vCard, cheeseCard, wineCard, whatever - in a "wrapper" which coersces it to be an XML compliant object; for instance the RFC2397 "data" URL scheme :

<a href="data:text/x-dog-card;base64,aSBsaWtlIGRhY2hzaHVuZHMK" rel="enclosure">dog card</a>

This (or similar) solution would be used for any RSS-based solution to "Feed-based VRM" since RSS is incapable of encoding non-XML-compliant data without an additional layer of encapsulation.

2) Leverage the ATOM functionality which provides the above base64-encapsulation as part of the standard "atom:content" specification; see: ATOM

Both of these formats are potential solutions, each with pros and cons, so we raise them in this paper to foment discussion of which would be most suitable.

Version 0.4 : Putting It Together

Drawing together the themes from above:

Charlotte runs her own VRM software; it was a bit like Wordpress to install - click some buttons on her hosting provider's dashboard, everything's done automatically - and generally it's a lot like blogging software to use.

Charlotte uses her VRM software to maintain a "vendor friends" list, which is just the list of people with whom she chooses to share her more "sensitive" data - her mailing address, credit-card numbers, and other stuff like that.

A lot of her VRM feeds are public.

For Charlotte, VRM works around "Documents" - she creates them like she does "Pages" in Wordpress, and some plugins in the VRM software coerce (say) her mailing address into a "Document" of whatever format is preferred this month, and the document gets squirted out through a "Feed". When Charlotte signed up with her bank, she added them to her vendor-friends list and used that to generate a VRM-feed URL so they could retrieve her mailing-address document.

She's not had to change her address on their website since she moved; her software's audit trail tells her that they fetch her address daily, and they confirmed with her when they saw it change. It's nice to have a bank do that. Her previous bank was a nightmare, so she revoked their VRM-feed URLs and closed her account. They never knew she moved, so no more junk mail.

Charlotte's friend Dave manages his VRM somewhat differently - his VRM is hosted and he throws everything into one big feed and lets his VRM-friends pick whether they are actually interested in the beer he drinks and what brand of cat-litter he wants to buy next week. Charlotte couldn't live like that, she prefers to keep different classes of Document separate, so she can manage access control more easily. But that's Dave's choice.

Thinking about booze, that reminds her: she really must add her wine feed to that Napa wine-grower's VRM-aggregator that she found; it'll get her preferences some broader exposure, maybe she could pick up a few cases at wholesale prices...

Charlotte's and Dave's use case point in the direction which we believe VRM should be going, and they provide a surprising amount of insight into the technology which could take us there.

Firstly: Feeds-based VRM software could be a lot like blogging software, with much the same look and feel, the notion of friends lists, chronological ordering of documents (ie: postings) and so forth. It would even be worth investigating whether a Feeds-based VRM user-interface pilot could be built as a Wordpress or MovableType (Open Source Edition) plugin.

Secondly: How the user uses their VRM software is a matter of taste: Charlotte prefers the tidiness of having "themed" feeds, one for wine, another for her home address information, etc, and manages different URLs for each via her VRM Friends list.

Alternately Dave prefers to just one feed with everything in it, containing different VRM Documents being published on a First-In / First-Out basis; presumably all of Dave's documents are transient such as a list of his 20 most recent purchases - rather than fixed, such as his home address; otherwise the document containing his home address risks dropping off the list of "most recent documents". Further, he puts the onus upon his feed subscribers to determine whether they have an interest in his VRM documents.

There is no reason for him not to do this, and he should not be prevented from trying.

Eve is usually an Evil attacker... -Kevinmarks 1/17/08 2:01 PM

We can hypothesise a further VRM User, "Eve" perhaps, who runs more advanced VRM software that is capable of dynamically creating "hybrid" feeds for different subscribers, guaranteeing inclusion of both recent "transient" documents, as well as the current versions of "fixed" documents such as a mailing address.

Eve's proposed software is conceptually more complex than what has been proposed for Charlotte and Dave without being functionally more rich, so we can address it as a user-interface issue in a later document. We may also assume that Eve's "version 0.5" software can deal the hanging issue of "timed release" information, by the simple expedient of post-dating a document for release at some future time.

Frequently Asked Questions 

1. Which object formats will be selected to share information via a VRM Feed?

   None will be selected, all will be possible. It's not the intent of VRM to mandate object formats when it should be the users - and the users tools - which define what works best, in a folksonomic sort of way.

   
   

2. How will one 'tag' VRM postings for semantic purposes?

   TBD, answer depends on how we go with RSS to ATOM

   
   

3. How can I maintain control over an object after it has been read?

   Short version: you can't, no more than you can erase a memory from your mind; however you can prevent someone from finding out future information about you, by dropping them from your friends list.

   
   

4. How can I implement "timed release" of new information?

   By forward-dating your document postings, exactly like you might make timed-releases of blog postings.

   
   

5. How can someone discover my VRM Feed?

   TBD

   
   

6. Can I have someone host my VRM feed for me, rather than do it myself?

   Certainly; again the analogy with blogging is strong; there is nothing to prevent companies being set up to manage a VRM feed service on your behalf, but equally there should never be anything preventing you from setting up your own server.

   
   

7. Can I use cryptography to get more security?

   TBD, short version: "sort of" ; SSL for data in motion, Certs for site-to-site auth, perhaps. Nothing to prevent use of encrypted document formats, PKCS, etc...

   
   

8. PLEASE ADD OTHER QUESTIONS DOWN HERE TO BE ANSWERED

End