The OpenID trust chain vs the X.509 certificate trust chain
This is a transcript of my talk at the OpenID Summit that took place in Tokyo Japan in January 2024. It was an entertaining 15 minutes that focused on the upcoming OpenID Federation 1.0 and how standards can sometimes have unintended uses and consequences.
Fun fact: According to Wikipedia Godzilla has been the longest running and most viewed movie franchise in Japan!
This talk has two objectives:
To compare, at a high-level, the Trust Chain and the X.509 certificate chain.
What is the Trust Chain? The Trust Chain is the hero, the central character in the new standard for federating Internet services, applications and devices developed at the OpenID Foundation.
Given the 10 year anniversary of OpenID Connect, we’ll also talk about the magic and unanticipated uses and consequences of computer standards.
The X.509 certificate has achieved a silent "monstrous" presence on the planet. I reach into my pocket where my credit card is - and it has an X.509 certificate stored in its microchip. I reach into my other pocket where my smartphone is - it has dozens of root certificates in the OS, the browser and probably many more certificates in installed applications. There are millions web servers around the world and all that that allow HTTPS have certificates.
Was this success planned or envisioned by the people who invented the X.509 certificate?
Probably not, because X.509 became a standard in 1988. Several years before the World-Wide Web, the browser and SSL / TLS were invented.
What helped the success of the X.509 certificate?
It does what it does, in a simple and elegant manner. It binds, cryptographically, a name to a public key.
The certificates can be neatly chained, up to a trusted authority.
The chains are compact too. Owing to the 1980s, when big storage was measured in megabytes and network speed in kilobits per second. This is what made the binary ASN.1 encoding so hot and sexy in those days.
Let's double click on the X.509 certificate:
It has a name of the issuer and the name of the subject, i.e. the entity that holds the public key.
It has a validity time window.
Some optional constraints.
And of course, a single public key.
That’s how simple the certificate is. If we forget the extensions, which tend to get ignored, and when they aren't being ignored they tend to crash the validation 😁
Fast forward to the 2010s.
Roland Hedberg from Sweden invented the JWT Trust Chain to enable OpenID Connect relying parties and OpenID Connect providers to magically federate, using authorities called Trust Anchors.
In its minimal form the Trust Chain JWT looks pretty much like a X.509 certificate.
Yes, it differs in the encoding (JWT vs ASN.1), but also in some crucial fields that give its magic and open up new possibilities:
It has a dedicated field for metadata. So that, for instance, OpenID relying parties can securely and automatically get registered by OpenID providers.
It has a field for metadata policies. So that a trust anchor could for instance set a metadata policy for the FAPI profile.
OpenID Connect specifies 65 (!) metadata parameters, with more in various extensions. This is a good example of an unintended consequence in a computer standard. Would Roland have invented these capabilities for entity-typed metadata and its policing if the authors of OpenID Connect didn’t create these 65 metadata parameters? Probably not 😁
It has a field for including 3rd party accreditations, as JWTs, called trust marks.
This table gives us a neat overview of what extra capabilities the JWT trust chain has.
Two features must be noted because they are not obvious from the previous slide which showed the content of a trust chain JWT:
The properties of the Trust Chains enable federations to closely reflect the needs and realities of the real world. Federations can be anchored in more than one authority, nested, and / or incorporate additional dimensions of trust in the form of trust marks.
In 1988 we did not have web APIs, but today we do. This means a Trust Chain can be discovered and built by starting from an entity’s well-known federation URL. Applications can call federation web APIs to build and validate Trust Chains in real time. Applications can also query trust anchors and intermediate authorities and thus navigate / crawl federations.
Let's fast forward the timeline to 2035.
This is the year when Elon Musk finally brings humans on Mars 😁
The other big news of the year is the release of TLS 2.0, which replaces the X.509 certificate chain with the OpenID Trust Chain.
So, it’s 2035 and at the OpenID Foundation board meeting prior to the OpenID Summit in Tokyo the board decides to upgrade the openid.net website to TLS 2.0. Remember, this is the year 2035, so it hasn’t happened yet 😁
We click on the openid.net padlock icon and what do we see?
Wow, we see new things that weren’t present there before!
We see the usual field that says which authority verified the openid.net domain name.
Next to it we see a second field.
In OpenID Federation you can have entities present a single JWT that can lead to more than one trust anchor.
So, the second Trust Chain leads to the Internal Revenue Service (IRS) of the US where the OpenID Federation is registered as a non-profit organisation. In 2034 the IRS decided to become an OpenID trust anchor and so every company and non-profit in the United States can obtain a Trust Chain JWT from the IRS by enrolling its public JWK set.
The other items that you see are trust mark JWTs issued to the OpenID Foundation. That the OpenID Federation has obtained a trust mark from the Bank of America because it holds an account with the bank. And that the organisation has received certain certifications, like for having received Mars survival training. These trust marks are embedded in the Trust Chain.
So what has the Trust Chain achieved in the year 2035?
It has changed the paradigm of TLS and internet security in general, by evolving the infrastructure, from Public Key Infrastructure (PKI) to a more comprehensive Trust Infrastructure.
That’s pretty big news in 2035!
The slide deck in PDF:
