Many of you were involved in the launch of the OpenID Foundation’s certification program for OpenID Connect Implementations. I believe that OpenID Certification is an important milestone on the road to widely-available interoperable digital identity. It increases the likelihood that OpenID Connect implementations by different parties will “just work” together.
A fair question is “why do we need certification when we already have interop testing?”. Indeed, as many of you know, I was highly involved in organizing five rounds of interop testing for OpenID Connect implementations while the specs were being developed. By all measures, these interop tests were highly effective, with participation by 20 different implementations, 195 members of the interop testing list, and over 1000 messages exchanged among interop participants. Importantly, things learned during interop testing were fed back into the specs, making them simpler, easier to understand, and better aligned with what developers actually need for their use cases. After improving the specs based on the interop, we’d iterate and hold another interop round. Why not stop there?
As I see it, certification adds to the value already provided by interop testing by establishing a set of minimum criteria that certified implementations have been demonstrated meet. In an interop test, by design, you can test the parts of the specs that you want and ignore the rest. Whereas certification raises the bar by defining a set of conformance profiles that certified implementations have been demonstrated to meet. That provides value to implementers by providing assurances that if their code sticks to using features covered by the conformance tests and uses certified implementations, their implementations will seamlessly work together.
The OpenID Foundation opted for self-certification, in which the party seeking certification does the testing, rather than third-party certification, in which a third party is paid to test the submitter’s implementation. Self-certification is simpler, quicker, and less expensive than third-party certification. Yet the results are nonetheless trustworthy, both because the testing logs are made available for public scrutiny as part of the certification application, and because the organization puts its reputation on the line by making a public declaration that its implementation conforms to the profile being certified to.
A successful certification program doesn’t just happen. At least a man-year of work went into creating the conformance profiles, designing and implementing the conformance testing software, testing and refining the tests, testing implementations and fixing bugs found, creating the legal framework enabling self-certification, and putting it all in place. The OpenID Connect Working Group conceived of a vision for a simple but comprehensive self-certification program, created six detailed conformance profiles based on the requirements in the specs, and quickly addressed issues as participants had questions and identified problems during early conformance testing. Roland Hedberg did heroes’ work creating the conformance testing software and responding quickly as issues were found. Don Thibeau shared the vision for “keeping simple things simple” and extended that mantra we employed when designing OpenID Connect to the legal and procedural frameworks enabling self-certification. And many thanks to the engineers from Google, ForgeRock, Ping Identity, NRI, PayPal, and Microsoft who rolled up their sleeves and tested both their code and the tests, improving both along the way. You’ve all made a lasting contribution to digital identity!
I think the comment I most appreciated about the certification program was made by Eve Maler, herself a veteran of valuable certification programs past, who said “You made it as simple as possible so every interaction added value”. High praise!
Here’s some additional perspectives on the OpenID Certification launch:
Today Microsoft released a Community Technology Preview (CTP) of