Why does standards certification matter?

It’s a good month for identity certification at Microsoft! We are excited to have achieved two important goals: OpenID Certification for Azure Active Directory and also FIDO Certification for Windows 10. You may or may not know what these particular protocols do, but even if you don’t, it’s worth talking about what these certification programs accomplish.

The goal of certification in the standards world is to ensure conformance to protocols. In FIDO Certification, the tests are both physical and digital; for example, authenticators must prove that they are storing keys and secrets in a secure environment, such as a trusted platform module (TPM), and that the secure environment can only be used when a user gesture is performed. Resistance to physical attacks, such as side-channel attacks, must be demonstrated, as well as protocol conformance. A third party performs this certification, with the goal that anyone who uses a certified product can have reasonable confidence that the solution hasn’t cut any corners.

The OpenID Certification is a different beast from FIDO Certification. Because OpenID Connect is a web protocol, there are fewer hidden parts; it’s easier for anyone to inspect and validate the protocol messages exchanged. The OpenID Certification process is therefore lighter weight and uses self-certification. With self-certification, those seeking certification run their own tests. The results of those tests are then published for scrutiny by all. In this case, the certifying organization is putting their reputation on the line. It isn’t a third party that claims adherence, it’s the owner of the implementation themselves. While those organizations could lie, most prioritize their reputation over any short-term gain that could come from misrepresentation.

A lot of developers have been successfully using the OpenID Connect with the Microsoft Identity Platform for years, so what’s the big deal? There are a couple of reasons why it matters. First, certification enables third-party vendors who are completely platform-agnostic to develop with confidence. This gets us closer to a world that requires as little custom connectivity as possible. Second, these tests sometimes catch things! The simple assurance of knowing that the development team has worked through all the edge-cases is valuable, even for established platforms.

If you go back a decade to when security assertions markup language (SAML) implementations were being certified, certification was highly formalized, took a long time, and cost a lot of money. We have iterated on that pattern with OpenID Connect, creating a lightweight and more inclusive practice. I don’t think this is the final frontier for certification, however. I believe that we will see the kinds of standards that lend themselves to automation evolving towards inline “test-driven” certification, where simple checks are performed by underlying layers as part of everyday software design lifecycle. Indeed, some projects are already using the OpenID Certification test suite in that way.

Whether the tests are automated, manual, or process-driven, at the end of the day, the goal is to ensure that what is promised on the outside matches what is implemented on the inside. It takes a lot of time and attention to faithfully implement protocols and certify those implementations, but the effort is worth it.

Congratulations to our engineering teams on both of our certification achievements!