The I-Files: The Truth Is Out There

Great news about Higgins and its first steps on the road to SAML V2.0 support! Some of the input from use-case contributors at the Project Concordia table included concerns about how identity selectors might tie into their current use of SAML and Liberty Web Services, and I’m sure Higgins will prove to be a useful test bed for scenarios these deployers have in mind.

This news bears on a topic I’ve been mulling over for some weeks now. In Concordia we’ve been discussing the different tradeoffs involved in making different entities “smarter” to handle multiple protocols. Scott Cantor has spoken eloquently in favor of the smart-relying-party method of improving interop in heterogeneous environments, by making what amounts to a do-everything toolkit available for service providers to install and use. I think it constitutes one good use case, but SURFnet chooses the smart-identity-provider approach using a translation hub/proxy instead, and George Fletcher has proposed some ways RPs and clients could get smarter together — these are valid too.

Scott’s comments highlighted the tension between APIs and protocols in providing consistency, repeatability, and interoperability in deployments. (In this post’s title, “I” stands for interoperability rather than identity.) Interop is something you measure between actual implementations (such as products, open-source projects, and other technology stacks), but protocols are a key part of managing and encouraging interop. I told a little story in the OASIS workshop to illustrate this tension…

A solution for cohesive treatment of pretty much any technical problem often starts as a proprietary API (or two or three).

In order to promote cross-platform and cross-language support, a message-oriented protocol gets created, either by fiat or by some open standardization process, to match it. (Sometimes a protocol is created without a nod to any existing API, of course.) As the saying goes, “The truth is on the wire.”

But in a highly distributed environment, inevitably such as those where federated identity is needed, the cost of getting all your partners to build and deploy support for handling these messages can be prohibitive. So some sort of common or standardized API, often associated with an open-source project, gets built that makes deployment easier. This is usually complicated by the need to create an API for each language or development environment. (By the way, I don’t mean to knock standardized APIs — such as those defined through the Java Community Process! — for their interop value. I’m just working through what happens when protocols appear on the scene.)

But then some competing protocols show up on the scene, which offer a different mix of capabilities or conceptually slice up the world in a different way.

So next we see an abstract API — enter Higgins! — created to unify or blur the distinctions between them. As a natural consequence, “glue code” is added, which is a huge convenience but which also adds distance between the deployer and the contract they enter into by using any particular message protocol.

Now multiple abstract APIs come onto the scene that purport to cover the same ground (I guess these would be the Lone Gunmen :-) ). Do they choose all the same protocol options in exactly the same way? Are translations back and forth happening similarly in each stack? What about the handling of impedance mismatches, where, say, one protocol has more features than another? Are some good ideas for consistent treatment buried in different pots of glue rather than being exposed on the wire?

Really, when a deployer chooses any one implementation stack, it amounts to a product decision — and the answers to these questions are important factors in figuring out exposure to lock-in. This is why documenting glue behavior is important, whether in profiles, extensions, gateways, translations, or even just descriptions of best practices.

It’s my hope that deployer-driven Concordia use cases can highlight specific needs for additional protocol guidance…which is useful grounding when architecture astronautics beckon.