Posts Tagged: microid

Software — No Comments
22
Jun 06

Simple MicroID Verifier

I promise this is the last post on MicroID today (It’s only number three ;) The previous two are here and here). Just as we’re asking people to start adopting MicroID, we felt it is only fair to help people start verifying MicroID’s. I’ve written a very simple perl implementation of a MicroID verifier and released it under the GPL. Make sure you read the install notes, in its current state the verifier requires a DB (where you’ve stored links and MicroID’s), but if you don’t have a DB you can just strip those parts away and use my code as a reference.

Here are the links for download:
.zip download
.tar.gz download

Questions, comments, etc. welcome.

Thoughts — 4 Comments
22
Jun 06

Creating a Social Web of Trust with MicroID: Part 2

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.

Thoughts — 7 Comments
22
Jun 06

Creating a Social Web of Trust with MicroID: Part 1

A few weeks ago, we introduced MicroID based verification in claimID. Since doing so, we’ve seen use take off – a real sign that users are very interested in making actual verifiable claims of ownership of their web content.

First, lets start with a little history. A few months ago, Jeremie Miller, the creator of the Jabber messaging protocol introduced MicroID. Jeremie called MicroID “Small Decentralized Verifiable Identity” – an apt description. Jeremie also called MicroID radically simple, and he was absolutely right. The core technology of MicroID is a simple hashing function (more on this in just a second) – and this radically simple technology may change how we think of ownership and social trust on the web.

Lets explore the problem space for a second. You have stuff on the web that you’ve created. You’ve got your homepage, your blog, your del.icio.us links, your flickr photos, your last.fm playlist. All of these things were created by you – they are a part of your identity. The next question is: How do you prove to people that the content you’ve “created” was actually created by you? For the meantime, you post your name, your picture, your bio – stuff that helps people disambiguate you and make a reasonable guess that you are the author of your content. The problem arises when you want to make an actual verifiable claim of ownership on this content, because for the time being, all we have to go on is our instinct.

What if people could simply make verifiable, distributed, standards-based claims of ownership of web resources? You’re investing your time, money and effort into your peer production – doesn’t it make sense that you should be able to tie your production back to your identity?

Enter MicroID. A MicroID is a standard identity microformat. A MicroID looks like this (may not render properly in news readers):

<head>
<meta name="microid" content="a9993e364706816aba3e25717850c26c9cd0d89d" />
</head>

The MicroID is computed by hashing together a users email address and the URL they are claiming. The pseudocode looks like this.

MicroID = sha1_hex( sha1_hex( "mailto:user@email.com" ) + sha1_hex( "http://website.com" ) );

Indeed, radically simple. How does it work?

To start off, you need two things – a verified email address, and a URL. The URL is the resource you want to claim, and the email address is your identifier. The URL and the email are hashed together to produce a unique identifier (see the psuedocode above), which becomes a shared secret between a content provider and a verifier. The content provider and the verifier have both verified your email address; as such, you can create a claim of ownership in the verifier service using the url. The verifier then goes to the content provider and checks for the status of the microID, and if the microID exists, ownership is established.

Now, lots of people have gone up in arms about using an email address as a verification entity. I’ll be the first to admit that MicroID only works when the email address is verified (either by both sides, or by the verifier when the person has write access to the content page). If there isn’t a verification process, forget about it. But once we do verify those email addresses, things get very interesting.

To think about this reference implementation, we’ll need a content provider and a verifier. The content providers in this example will be flickr and del.icio.us, the verifier will be claimID. In flickr and del.icio.us, you have a verified email address. Say you use bob@microsoft.com for your flickr email, and bob@hotmail.com for your del.icio.us email. Using that verified email address, both flickr and Del.icio.us could compute a MicroID for your pages. Now, you want to verify these to your claimID. In claimID, you would verify each of your addresses (bob@microsoft.com, bob@hotmail.com). ClaimID would then go and check the MicroID’s on your claimed page, using MicroID’s generated by both of your verified email addresses. Since both email addresses were verified in claimID, claimID would be able to validate your claims and display them as such.

So something interesting just happened. That stuff about you, the stuff that you use to show people how cool and smart and hire-worthy you are, the stuff that is only tied together by the fact people believe what they see, now has something behind it. You are actually creating a web of identity, which is a very interesting thing. Imagine that I know you, but not very well. I know that your flickr pictures are by you, but I don’t really know what else is owned by you on the net. Since you’ve verified your flickr pictures to your claimID, I’d follow that line of trust around to other verified sites on the net. I’d develop a trusted picture of your identity. Imagine how useful this is.

Now, the counter argument is that all of this can be falsified. You can create a fake flickr account with a fake email address, and a fake claimID with a fake email address – sure. And you can verify using that fake email address. I acknowledge the validity of the case, but by doing so, you haven’t broken MicroID. MicroID verification only proves that two things on different services are the same – a claim and a content page. It can’t go any further than that, and I don’t think we want it to.

We construct a social picture of identity based on stuff we trust. I know you have a flickr page. I trust it because we’ve talked about it, or emailed about it. I can follow that flickr page back to your claimID, and I can trust your claimID because you’ve verified your flickr to it. Indeed, the trust process is bidirectional – which makes this completely beautiful. Sure, claimID does multifactor authentication with openID and multiple email addresses – but the point is you’re creating a web of identity. Anywhere I come into the web, as long as you’ve verified one thing to another thing, I can transverse the web and see a trusted picture that you’ve chosen to present. The only requirement is that I have a fair amount of trust of my entry node into the web – and that’s what we as humans already do.

So this is revolutionary. With this tiny little MicroID and a verifying service that follows the MicroID standard (doesnt have to be claimID, we’re just the first doing it), users can simply create these webs of identity. No need for verifying services to log in to each other, no need for passwords or API’s. All we need is a little MicroID, and we can start changing the nature of social identity on the net.

So this is the case for MicroID, and why you should implement it. In the next post, I’ll cover exactly how.