Changing Your Address

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?

---

---

Contributions