MicroID Development

One of the most fascinating experiences resulting from publishing MicroID has been the way that people try to understand it. It’s clear that I didn’t explain how I expect it to be used well enough, so this post is the start of a living FAQ I’ll be building through this blog and based on the comments posted (so post any new questions please!):

Q: Anyone can make a MicroID for me if they know my email address, how does that prove anything?
A: Yes! A MicroID doesn’t prevent spoofing, it simply enables ownership verification. I know that doesn’t make sense, but think about it with a real world example, pet tags. You put your phone number on your pet’s collar (or microchip implant these days) to identify that pet as yours. Sure, anyone can label their pet as yours, but what do you care? With the microchip example it’s even more clear, when you go to the vet they can check your ID and match it with the implant owner data, they validate that you own that pet. MicroID allows a service to validate that the content you link to on some other site, is actually yours if you claim it to be.

Q: How’s this any different than doing something like this?
<meta name=”contact” content=”mailto:” />
A: It’s functionally identical, publishing your email address allows the exact same level of ownership demonstration. Compare to the MicroID example:
<meta name=”microid” content=”9d6d3552e3304340849837313b0e34833e4c599b”/>
The only difference is the MicroID doesn’t expose the address, and you only have to reveal the address privately to those that you want to show ownership to. That’s enough reason alone to be useful.

Q: What identifiers can be used instead of email?
A: The only requirement is that the identifier you use as the source is
verifiable; email address, IM handle, phone number, even a PKI token, anything that
enables one to validate it. It’s only as strong as your ability to
verify that identifier is, which with email-confirmations is (un)
fortunately a very common practice and acceptable level of confidence for most systems.

Q: So my home page can now be verified as mine by just checking my email address, so what?
A: My perspective comes from online reputations, particularly
the reputation silos that are all of the various comment and content
moderation systems out there. Individuals put a lot of work into
building a reputation on all of these web communities, and that
effort isn’t portable today. By using MicroID and exposing a contact-
able identifier along with any of your posted content/comments on any of those systems you
can demonstrate/validate ownership of that reputation. MicroID is just an
alternative that provides this basic utility without forcing the
identifier into the public.

There are two important things that I’d like to get feedback on for the actual mechanics of MicroID.

First, Ben Laurie pointed out an obvious “why didn’t you…” in that we should be using HMAC to combine the two hashed identifiers. So, unless there are any objections, I’ll be updating the spec soon to use HMAC (it seems to be as widely available as sha1 alone).

Second is a deeper question, should the site or published-at URI be a complete one, or just a reference to the authority? Simply put, should it be ‘http://jeremie.com/blog/entry.php?x-y-z’ or just ‘http://jeremie.com/’? The former would require a unique MicroID generated for every URI it’s published at (is this even always known?). The latter would require a better description and common understanding of what the ‘authority’ is for any given URI. What this really comes down to is normalization, for the hashes to match, everyone needs to ensure the URIs are normalized the same.

Suggestions are welcomed here, I’m working on this project for how deeply useful it can be, not because I’m an expert in this area.

After the big splash last week, I’ve hardly had time to do enough follow up with the tremendous response, so I’ll do my best to get a few posts here and do just what the title says.

Part of growing a community effort include managing the flow of information, and I wanted to record my thought process at this point in time because I’ve been around for long enough to see some major shifts in how this is performed. Here’s the trends I’ve seen come (and go):

* Usenet News Group
* Mailing List
* Web Forum/BB
* Wiki
* Blog (we’re here, obviously)

The easiest way to centralize updates and record the evolution of an idea online seems to be a blog. Participants can post comments, anyone can opt-in for notifications, and progress can be visualized.

So, here we go!