Standards development is a long, painful process and often results in a compromise everyone involved can live with. Implementations claiming compliance to the standard are not assured of interoperability, especially when integrations are between implementations done by different vendors or organizations. This in turn highlights the need for, and value of, protocol profiles.
Having been involved in creating profiles, and having successfully convinced vendors to implement them, I am a true believer in their value. A protocol profile is the end result of a community getting together and saying “There are multiple ways of doing X in standard Y. We agree to pick one way to do X, and we are going to test that way of doing things to make sure that everyone who does it that way can talk to everyone.”
This is a concept that is very familiar in the standards world and product vendors can be asked explicitly if “Do you support profile Z of standard Y in your product?”. As I have mentioned before in “Standards Compliance - Balancing Purity and Pragmatism”, you prioritize interoperability at system boundaries, while being flexible inside those boundaries.
When people choose to go their own way a.k.a “We support standard Y, so we are interoperable;
who cares about any damn profile?”, you end up with a case study in what NOT to do. For an example, let me point to John Bradley’s recent blog post:
While HealthCare.gov is using SAML 2.0 they are not using a standard deployment profile like the FICAM SAML 2 Web Browser Single Sign-on Profile for the Federal Government or the SAML 2.0 INT SSO Deployment Profile used by Research and Education federations.[...]
The industry puts time and effort into producing profiles and testing against them, to reduce integration problems when people deploy federations. The [id]Management.gov for the US Gov is clear on its deployment profile for SAML SSO.
One of the problems the insurers had integrating with HealthCare.gov was a divergence they made from these profiles in what they were sending to the insurers.[...]
... software providers to the insurers scrambled quickly to modify our products to accommodate this strange behaviour in the weeks leading up to the launch ...John Bradley: Healthcare.gov SAML issues
Words fail me at this point. So I will simply echo John’s comment: “That is why problems like this that don’t need to happen annoy me so much”.
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.