It’s a WRAP followup: maybe the goal was client-side certs?

I’m having some interesting offline followup discussions with folks about oAuth WRAP and my relatively negative reaction to it. One of the comments seems to be that SSL will recreate exactly the security that HMAC signatures were trying to achieve, and it was really hard for developers to do oAuth right in the first place.

I definitely sympathize with “it’s hard to get security right,” and I certainly agree that we should begin to standardize oAuth libraries ASAP. The reference implementations are okay, but they’re not solid enough for widespread standardization, which means people are cooking up their own, which is bad news. So yes, being able to delegate the security implementation to a well tested library is a good idea.

But I don’t think server-side SSL replaces the security we got from HMAC-signed requests. The key idea of signed requests is that if I intercept a request, I can’t steal the credentials. The only way SSL compares is if certificates are definitely checked or if client-side certificates are used for authentication. I don’t buy the argument that oAuth WRAP client-side libraries will do proper certificate checking. And I think that, while very cool, client-side SSL certs would make life potentially more complicated for developers (and would rule out JavaScript implementations for the foreseeable future.)

I’m very open to the idea of simplifying oAuth, and maybe there’s something to oAuth WRAP that I’m not seeing…. but the point is, the current oAuth WRAP security claims are, I believe, misguided in practice, and I hope the oAuth WRAP team thinks this through a bit more before all the big name web sites standardize on it, and the next favored technique for hacking your Facebook account is DNS spoofing the oAuth WRAP transaction.