Coming across this retreat from the wonders of OAuth 2.0 in the daily Lynnogram reminded me of my own Hypotheses, little seeds of experience that can sometimes defend the diligent designer from the wayward path to hell:
OAuth 2.0 and the Road to HellBy Eran Hammer Thursday July 26, 2012
They say the road to hell is paved with good intentions. Well, that’s OAuth 2.0.
Last month I reached the painful conclusion that I can no longer be associated with the OAuth 2.0 standard. I resigned my role as lead author and editor, withdraw my name from the specification, and left the working group. Removing my name from a document I have painstakingly labored over for three years and over two dozen drafts was not easy. Deciding to move on from an effort I have led for over five years was agonizing.
There wasn’t a single problem or incident I can point to in order to explain such an extreme move. This is a case of death by a thousand cuts, and as the work was winding down, I’ve found myself reflecting more and more on what we actually accomplished. At the end, I reached the conclusion that OAuth 2.0 is a bad protocol. WS-* bad. It is bad enough that I no longer want to be associated with it. It is the biggest professional disappointment of my career.
Eran Hammer was instrumental in OAuth 1.0. He then moved the efforts into an IETF working group so as to "improve" it to Enterprise grade. He didn't survive the transition.
Which reminded me of what I'd written in "Hypothesis 4 - The First Requirement of Security is Usability." Sadly, until today it seems, I had neglected to publish the relevant seed! Hardly a usable Hypothesis, indeed, and apologies to all. Here it is:
#4.4 No Committees!It should be clear by now that committees are totally out of the question. They are like whirlpools, great spiralling sinks of talent, so paddle as fast as possible in the other direction.
On the other hand, if you are having trouble shrinking your team or agreeing with them, a committee over yonder can be useful as a face saving idea. Point them in that direction of the whirlpool, give them a nudge, and then get back to work.
And, for my sins, I have also packed in H4.5-7, and the entirety of Hypothesis 4 is now published.
As an aside, there is also an emerging consensus about committee-protocolism as being the wrong way to go about industrial-scale security. Note Adam Langley's remark:
"So, for new primitives, you may want to produce solid
implementations for different platforms to seed the
implementation ecosystem. Not just reference
implementations, but ones that are good enough that
they dominate the set of implementations. For example,
if I specify curve25519 in a protocol, I can be pretty
sure that everyone is going to be using djb's reference
code. That's a major advantage."
It's about simplifying the engineering of cryptoplumbing so we can get to the point where one person can create the majority of the implementation. Reliably.
Posted by: Iang (commenting on Adam Langley's comments) at March 7, 2013 03:02 AM