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