Skip to content

Internet Identity Workshop 2006b and MicroID

I’m here at the Internet Identity Workshop and have been having a number of great conversations. The quality of the discussions is high and the number of demos is remarkable. Only seven months ago when I was in Mountain View for the earlier IIW2006, there were a couple demos of near-working implementations and a lot of excitement about what the next few months were going to unleash as these systems started to come online. It’s also when the idea was first hatched to bake OpenID into claimID. So long ago.

A great many things have happened since then. Higgins is now demoing live open source implementations of a variety of tools, including Bandit, around the newly announced OpenID 2.0 spec. We have full OpenID 1.1 libraries in all the major programming languages. OpenID 2.0 code should be rolling out within a couple weeks from a number of the vendors here. Dick Hardt of Sxip demoed the newly announced Sxipper Firefox plugin. There was a Safari InfoCard Selector demo complete with modal overlays. There were a surprising number of demos (Java, even) fully functioning with versions of Microsoft’s CardSpace (coming baked into every copy of Vista in a few short months). Avery Glasser of VxV Solutions demoed his company’s voiceprint technology fully integrated and interoperable with OpenID. JanRain demoed their new BotBouncer site designed to serve as a centralized CAPTCHA repository so users can know a particular OpenID has passed a humanness test.

I also ran a session this morning on MicroID and how it works as a lightweight verification method for claiming a webpage (and eventually a part of a webpage). I received a variety of questions about SHA1 and it’s being broken back in February of 2005 as well as the MicroID not being a true HMAC. The answers, as best I could describe them, hinge on the fact that these are not true secrets being hashed and passed around for MicroID. We’re only using hashing in the first place to try and obfuscate the email address of the user – not protect any nuclear secrets.

Additionally, Dick Hardt posed a question that forced me to step back and reconsider a couple things about MicroID.

He asked, if you’ve got an OpenID, couldn’t you just use it as the communication identifier itself and skip the hashing step (which exists to obfuscate the email for publication purposes)?

Of course, he’s right about this. If a site has decided they want to play along with all of this fancy identity stuff and expose something which allows others on the internet to verify claims that their users are the same person at a different service, why would they pick to expose MicroID if they could just implement OpenID and expose it instead?

The answer, I think, is mostly that it’s easier to do MicroID today (it’s just a hash). But in the long run, once OpenID is in a lot more places and a lot more visible to everyone online, it will probably be just as easy to simply include a user’s verified OpenID in the head of their page – no hashing – no obfuscation necessary.

Something like this:

<meta name=”openid” value=””>

Then, other sites can simply check to see that they, too, have independently verified that particular OpenID and ‘connect’ the accounts.

Just like MicroID does today.

In fact, I’m proposing here that MicroID be tweaked to include the opportunity to do just this. Declare as part of the spec the publishing standard for publishing OpenIDs as well as MicroIDs for public consumption.

Perhaps claiming a blog comment would be easy if it looked something like this:

<div class=”openid-”>

It seems simple enough and allows these simple claims to be made as the technology matures beyond simple email addresses as communication identifier.

MicroID specifies for the first part of its hashing formula to be any communication identifier, but if it’s an OpenID specifically, or i-name, it doesn’t need to be obfuscated and hidden from view.

Thoughts? What am I missing? Are there use cases where someone/someservice would still want to obfuscate the OpenID? Should it ever not be public?

Tags: - - - -

View blog reactions

{ 3 } Comments

  1. Fred | December 6, 2006 at 9:11 am | Permalink

    The situation you describe is just a microid claim w/o a hash. It is the exact same principle. The reason we hash is to build a identifier out of the claimed URL and the communication identifier. In the openID situation all a web service is doing is putting a “trusted” openID on the page, which is fine. If people want to claim via OpenID I don’t see a problem with it.

    But the reason MicroID is nicer is 1) it is simpler because it doesn’t require openID integration (i.e. is a long way away from being openID enabled, but it is easy for me to put a hash in the head) 2) the MicroID namespace already handles things like OpenId (you can put any communication URI in the hash – email, OpenID, XRI…). So in that sense OpenID is already built into MicroID.

    So I don’t think you’re missing anything, you’re just blessing one form of communication URI over another. Think about it – you could just publish verified email addressess too, they have the same power in terms of authentication as an authenticated OpenID does.

  2. Fred | December 6, 2006 at 9:23 am | Permalink

    Oh, and the purpose of the hash isn’t just obfuscation – it is to create a single reference that contains a join of the URI and the claimed URL. This is essential for decentralized claims because the hash contains both of the elements important to the claim. Once you start verifying multiple comm URI’s this just makes life a lot easier for verifiers (so instead of having to build a case if openid do this, if xri do this, it just finds a standard microid and compares). It is a slightly nominal rule but it makes sense.

    Damn I wish I was at this session.

  3. James | December 12, 2006 at 4:01 pm | Permalink

    Would love your thoughts on