In the previous post in this series, I issued an impassioned call for content providers to adopt MicroID as a way for individuals to create a verified social web of trust. “Verified” and “trust” are big words, so here’s a little breakdown of exactly how this could work. I’ll address these from the “verifier” and “content provider” positions – the verifier being a actual verifying service (like ClaimID) and the content provider being any web content service (flickr, del.icio.us, last.fm).
The core assumption of this system is that there are users who want to verify pages on the net. As the MicroID must reside in the page’s header (per the spec), there are two main content provider-side cases we must account for. First, there are pages on the net that users will have write access to (their homepage, their blog), and, second, there are pages on the net they won’t have write access to (at least to the header, these are your flickr, last.fm, etc.).
For this system to work, a user needs to have a verified email address on at least one side. If the user has write access to their content provider-side pages, validation is only necessary on the verifier’s end (our standard of ownership allows that if a user can edit a page’s header – thus adding a MicroID, that is a fair standard of ownership). If the user does not have write access to the content provider-size page, the verifier and the content provider must verify the individual’s email address (and automatically generate the MicroID from this email address).
In terms of actual implementation of the system, there are two roles – verifier and a content provider. As this post is written as a reference for content providers, I’m please to report that the content provider (you) need only to automatically include the MicroID in the page header. All you do is generate the MicroID off of a verified email address, and include it in the user’s page header. It couldn’t be simpler.
The verifier has a more complicated role, but not by much. The state of verification is a binary state. It means “At time x, resource y was verified”. If resource y changes, you need to break that verification. That’s really the only rule that verifiers need to enforce above and beyond. A verification is a state, and if the URL changes, they have to re-verify (because a new URL is really a new claim). If they change their email address, they don’t need to re-verify. You’re claiming a URL, not an email address. The email address got its verification when a human clicked on the link in the email you sent him/her. That state persists. Now, if a person adds a second, third, or fourth verified email address (so they can verify against different resources using their different email addresses), you just compute the MicroID for each when you verify, and if one matches, you’re in a verified state. It really is that simple.
So, what are the problems that you need to look out for? Well, people are going to complain that one person can have someone else verify an email for them. If I’m friends with Larry Page, I can have him verify the larry@google.com email address to my verifier. I’d argue that isn’t a problem as much as it is a solution. Say that you own a company, and your employees have profiles on many services on your behalf. Now you want to verify those services. So you ask the verifier to verify Susan, Bob and Kathleen’s email addresses, and you can then go out and verify the accounts they’ve created in content providers using their employee email addresses. So this “vulnerability” actually has an upside.
The real problem is DNS cache poisoning. Since a MicroID verification is done with an HTTP GET, the DNS system is its core vulnerability. However, this sort of attack doesn’t scale; it is also easy to distribute verification (verify from multiple locations and compare the results) to mitigate the possibilities of attack.
It is also important to remember that this system is limited by its simplicity. This simplicity is beautiful because it leverages our existing trust patterns. Two-sided email verification means something. A web of identity means something. The fact this couldn’t be easier means something. People can actually use this, and that means something.
I’d really like to urge some cutting-edge content providers to think about adding MicroID to their service. All they need to do is add the MicroID to their web templates. Since MicroID is a standard, anyone would be able to run the verification – wether it be a tiny outfit like ClaimID, or a Google or Yahoo. This easily answers a need that many of us feel very strongly about – how do we display proof-positive that we actually own something? And how do we do this incredibly simply, in a user friendly format.
Of course, there’s probably a good deal I’ve left out, and these posts have been quite lengthy – so I apologize. However, when you think about how this beautifully simple solution would work…it actually makes sense. So, content providers, will you join in this initiative? With this one little MicroID, we can start to change the nature of how we construct our identities online – for the better. Please drop me a line at fred @ metalab.unc.edu, or leave a comment, if you’d like to continue the conversation.
Tags: identity, microid, social software
“… the MicroID must reside in the page’s header (per the spec) …” really? The MicroID website contains two examples using class values.
And what values is ClaimID using in order to generate MicroIDs? I’ve tried several different sites and identifiers, and the microID I come up with (using the generator on microid.org) and the one ClaimID gives me never matches.
so I figured out how you’re computing microIDs after reading the comments here. I was leaving off the trailing slash of the URL, as the microID spec specifies. However, I’m still not sure about the microID that appears on my claimID page… how is that being generated?
That’s computed automatically from your verified email address and the current page location. A trailing slash is not automatically added to the URL.
Hope that helps.
Will, to your first comment, you are actually right. The MicroID spec doesn’t make requirements about implementation (nor should it). So I take that back. The implementation I describe requires MicroID be in the header of the page, as we are defining that as a protected space. As long as the email used by the automatic MicroID generator is verified there can be trust in the MicroID. Third-party verification of MicroID’s out of protected places like the header does get more difficult (again, though, an implementation issue as opposed to a ‘protocol’ issue)
I should also note that currently MicroID is not a official, protocolized microformat. Even thought the page uses the term – it has not officially been put forward yet. A microformat is a microformat just like a protocol is a protocol…not all protocols have RFC’s. Hopefully we can get some traction to actually start defining the MicroID official microformat.