I’m tired of typing my postal address into Web sites. Furthermore, it’s
stupid, wasteful, and a little worrying that so many of them out there have
stored copies of it. Wouldn’t it be better just to give them the address of my
address?
[This is provoked by an acronym-heavy discussion that’s sloshing around
online; a good sample of the thinking may be found in
“Feeds-Based VRM”:
A Web-Centric Approach to VRM Implementation, by
Adriana Lukas and
Alec Muffett.]
Your Offline Address, Online
The idea is this: Instead of filling your address into a form, you give
them a URI for your address, where a Web site’s server can fetch a
machine-readable version and fill in all the fields. In the case where the
site only needs your address once, this is worthwhile for labour-saving and
quality purposes; how many times has it taken you three tries to get all the
pieces of your address into the right place on a persnickety Web form, and how
many other times have you noticed a dumb error in an on-file address you entered
earlier?
Suppose the Web site needs to keep your address; perhaps they’re
going to send you something every month. Then this URI-based approach really
shines, because if you move, then you just change your online address in one
place and then anyone who needs it every so often goes and picks it up when
they need it, and they’ll have the latest version without you having to run
around the Web and change it everywhere.
This seems like a no-brainer, and if you buy into it, there are maybe a lot
of other similar cases. Here are some other things that you might want to
keep online in one place, control yourself, and deal the addresses of out, as
required: your credit card info, your FedEx account, your health-insurance
number, and your frequent-flyer programs.
Of course some of these get into very sensitive security issues; but
actually we’re getting pretty good at providing information on the Web in a
secure way.
The people who are thinking about this are slinging around
jargon from the “VRM” (Vendor Relationship Management) community and
from the Identity community. I’m not really a member of either, and
thus am probably missing some of
their finer points. But the notion of you controlling your own automated
information dispensary seems like an obvious winner to me, and furthermore,
one that ought to be easy to build using existing Web technology, right out of
the box.
And you don’t have to be that paranoid about privacy and security
issues to appreciate the advantages of controlling the storage and delivery of
information about yourself.
Technical Issues
This originally came across my radar because Alec Muffett asked me what I
thought about the idea of using Atom (RFC4287)
as a wrapper format for this kind of data.
Off the top of my head, it sounded plausible. Atom is XML, which
helps with internationalization, and then it also provides you with a
guaranteed last-updated timestamp and a nice globally-unique identifier for
each item.
Let’s focus on that nice simple example: storing your address online.
The first thing you need to figure out is how to encode the address
machine-readably. From where I sit, it looks like the vCard format is the
most deployed and is thus probably well-debugged. It comes in three flavors:
plain-text, XML, and an XHTML microformat.
Any of them would work, either on their own or in an Atom wrapper; I’d be
inclined to pick the native plain-text version just for simplicity.
Speaking of simplicity, I guarantee that if this idea got momentum, you’d
hear voices raised arguing that vCard is just too simple for this or that
business’ addressing needs. Well, too bad, they don’t have to play if they
don’t want to. My bet is that the upside from bringing order to this chaos
is much bigger than the cost in forcing businesses to dumb down their
addressing data.
So, what would using an Atom wrapper, as opposed to just a naked vCard
resource, buy you? To start with, you’d be able to batch up
things for delivery; for example separate billing and delivery
addresses. Or for that matter everything you want to share to drive one
particular transaction: address, credit card, and affinity programs.
On the other hand, there’d be a cost, because you’d have to give the
receiver two pieces of information: the URI of the feed and some sort
of selector for the bit that contains the particular item in question.
While thinking about this, I realized that we never specified a
fragment-identifier syntax for Atom, so in
http://example.com/feed.atom#37, the #37 doesn’t
actually mean anything. Sigh.
I pinged
Joe Gregorio online and asked “Did we
really not do that?” and he replied, more or less, “D’oh, we should fix that.”
Neither
of us can remember the issue ever coming up for discussion during the Atom
process.
So actually, it’s not obvious to me that an Atom wrapper is
a good idea here. The timestamp would be nice, but then a well-run
Web server should also provide that information.
Take-Away
Unless I’m missing something obvious, the notion of everyone bringing
the online information about themselves under their own control, using plain
vanilla Web technology, seems like a winner.
What would it take to get this started?