[OpenID] openid connect - a high level review - thinking about what the lawyer or auditor needs

Fri Feb 17 11:54:58 UTC 2012

I briefly reviewed the openid connect specs (not having seen drafts for years), a rather strange lightweight PKI spec (RFC 6125) that seemed to make rather a mess out of settled engineering material of key management, a reference to an ITU-T spec (whose text I could not read), and OAUTH v2 specs.  I looked at it all as one family - defining a new generic upper layer protocol spec. It was clearly pointless trying to comprehend the anticipated reach or inner nature of openid connect without embracing the wider context.

Having worked with auditors and lawyers 15 years ago to write practice disclosures and then actual contracts for the then highly-engineered and internet-centric (vs web-centric) world of TLS, OCSP, and CMS and authenticode timestamping, I asked myself: could you reduce openid connect and all its supporting architectural and dependent infrastructure references to what THEY need? (knowing well how they think, at this point). Could I get to the core model? Could I translate it into the (declarative) language of legal or audit-testing protocols?

I decided the answer was yes, but it would take several months of work - mostly sorting through the morass and reducing it to declarative claims and or statements. I could only do it for a profile of the morass, though, and could not do it for the general case. (This is an innocuous but actually key observation, that comes only with considerable experience). Some of the material is almost still "work in progress", and there is a lot of duplication and overlap with older generation of specifications. There is also a not inconsiderable amount of architectural posturing at times, as I found folks reaching for a tone that defines  "what's different?" and justifies "why improve what's settled?" - since there really does seem to be 1 step forward 2 steps back, at times.

As I was doing this, I kept saying to myself... well I see folks really are attempting to build a new layer 5-7 upper layer protocol spec...and I see that it is in many ways merely a lightweight profile of stuff that already exists (much like ldap dumbed-down X.500 in the 90s, or SMTP dumbed-down MTP in the 80s), but I pity the non-specialist who is tasked with trawling through it. Its really not that lightweight, it just a different tone. And its a tone that justifies itself because the character of the problem really has changed.

If I had to answer the question to a non tecehnical person: why does it all exist (and what motivates it the change of tone)? I think the only 10 word answer I could give is: well the iphone changed the web. No longer is there only the hypermedia web browser. Now there is the iphone client too, and the web will never go back to being what it was (as originally conceived with the single, universal access device, hopping around from here to there, with limitless abandon, while you sit at a desk). And, so the internet/web security layer has had to evolve too ...to work with this new category of telematic client. And thus the security model (that was all tuned up for the presumptions of the document-centric, hypermedia-viewing web browser, and the web architecture) has had to change too. The ebook client (in the nook product, say) is another example of a non-web browser that acts as an access device for the web, featuring a managed interaction model.

If you have the knowhow and experience to map features from the older heavyweight techniques and method to their lightweight versions, it does get easier to comprehend. And, this does allow one then to map what appears new (but really is not) onto the established legal and auditor protocols (and consequently write something that would pass the legal review or audit disclosure examinations). it is possible to strip it all down and free it of the technicalities and the new pseudo-design vocabulary, and reduce it all to controls and claims.

I found the openid connect documents readable. But they do require a fair amount of context to be comprehensible. I found myself tending at times to say: ah that's just [this old thing] recast [as this new thing] - which did help comprehension (when wanting to map them down to their legal protocol equivalents, and borrow from older practices documents). I could kinda see where some political alliances have forced certain material together (often in ungainly fashion). But, when read it all as a set, I could see and grasp at the "generational shift" that is driving the change. Its hard to see it character at times (and folks seem to groping for a consistent language for its distinctive tone), but it is there. I could feel the pulse of the social movement (and didn't find myself rejecting it).

Its quite fun to then look back and say: well was that what I expected for openid? then answer is no, I didn't have any idea when I wandered into an openid session at a DigitalId world that this is what folks were contemplating. And, this observation is a little disconcerting (but not wholly unacceptable). I am glad we never deployed authenticated comments, OAUTH API endpoints, or used URI-based login dialogues (or NASCARs)m or bought into the minimalist UI theming trends. But I do find myself wanting to get out my compiler and apply some of the stuff FOR its architectural features. The specs worked therefore, in the evangelism sense, even though I found  at my stage of programming capabilities engineering pining for the nice simple microsoft "scaffolding" code that will reduce all the complexity (of OAUTH v1.x) for the likes of me to simple to understand models (using the firm's cloud-based STS "delivery vehicle")

Finally, it helped looking at the technology through the lens of NSTIC - imagining these documents and those of the supporting specs evolving into a settled national identity framework, with the robustness of the old phone system. And, I can see it happening. I can see why the generational shift is required, having grasped at the limits that folks are articulating as justicication for why the renewal process is required. I do see that there is an generic upper layer identity layer that was just not there in the design forums of 20 years ago (though ITU-T-era engineers broke the ground we are now standing on, characterizing an earlier veresion of the problem). And, I sense that quite different grade of engineering is ultimately involved, and its focused on a level of "globally managed" interworking that simply didn't exist -- in the first few generations of the web. 