I sometimes talk to people who ask "Why do we need SSI? What's wrong with X.509 certificates?" Here's some thoughts.

X.509 is a standard that defines the format for public key certificates. Public key certificates can be used to tie a public key to other information. The most common use, by far, is TLS/SSL, the basis for trust in HTTPS, the protocol that secures the Web. In TLS, the certificate binds a public key to a domain name (and perhaps other information).

The first challenge for many people is determining whether X.509 certificates are more like verifiable credentials or DIDDocs. This is understandable since X.509 combines the functions of these two separate SSI standards. X.509 certificates themselves are like DIDDocs in that they bind information to a public key. But the hierarchical public key infrastructure (PKI) of X.509 is meant to attest to the veracity of the the X.509 certificate. And X.509 extensions allow other information to be included. So, X.509 certificates also bind the public key (as an identifier) to real-world attributes. DIDDocs don't have anything like PKI. Rather SSI uses verifiable credentials to assert information about a decentralized identifier in a trustworthy way.

Another important difference between X.509 certificates and DIDDocs is that the primary purpose of the DIDDoc is to bind the public key in the DIDDoc to a decentralized identifier, or DID, whereas X.509 certificates can bind the public key to a subject name and other information like a domain name. Extensions to the certificate allow it to also bind the public key to other information. The important distinction is that the DID is required and represents a unique name for the DIDDoc. A DID must have some means of resolving to the DIDDoc¹. The DID provides a level of indirection to the public key. Consequently, the public key associated with a DID can be rotated without changing the DID and so it can be used as a permanent identifier. I won't get into the details around how this is done securely, but you can read far more detail at The Architecture of Identity Systems if you're curious.

The veracity of an X.509 certificate is usually determined from the strictly hierarchical public key infrastructure (PKI). For example, when you visit a web site, your browser uses the X.509 certificate from the web site to establish a secure connection. If you click on the lock, you'll see information about that certificate. The web site's certificate was signed by some organization that is attesting to the information in the certificate. You can use the certificate of the signing organization to know its public key to do the check. But how do you know that certificate is valid? It's signed using the private key whose public key is in yet another certification, and so on. Eventually this has to stop and it does when you get to a certificate that was stored in browser when it was built. CA Browser Forum is the organization that determines what certificates are worthy to be inside browsers.

In contrast, the veracity of the DID and associated DIDDoc is ascertained by a heterarchical method. The DID and DIDDoc are self-asserted and self-certifying. You can use cryptographic means to determine that the binding asserted in the DIDDoc has not been tampered with, but the DID infrastructure itself does nothing to tell you who or what the DID is bound to in a verifiable way. For that, we use verifiable credentials.

Suppose the DID in question is one Alice generated to give to Bravo Corp, her mortgage processor. Bravo knows nothing about the DID they've received except that it's bound, in the associated DIDDoc, with a specific public key (and possibly an endpoint of some kind). They ask Alice to prove things about herself as part of the mortgage application process and over time learn quite a bit. Alice proves her name and date of birth using a verifiable credential representing her driver's license. She proves her income using a verifiable credential from her employer, and her banking information using a verifiable credential from her bank. The information in each of these verifiable credentials is attested by its issuer: the DMV, the employer, and the bank. Bravo's reasons for trusting these organization are up to Bravo:

• The may be well known.
• Bravo may have a prior relationship with them.
• Bravo might ask them to prove things about themselves (using verifiable credentials, of course).
• Or they may belong to a trust framework that Bravo can use access publicly.

Furthermore, zero-knowledge proofs (ZKPs)² allow Alice to combine the attributes in these various credentials (and others) in a way that only discloses what Bravo is asking for and nothing more. And her digital wallet was able to do this for her automatically without Alice having to pick and choose the various attributes from various credentials herself. The proof shows that the information from these three credentials is all bound to the person who controls the DID that Alice gave to Bravo. The proof also shows that these credentials have not been revoked.

You can imagine Alice having X.509 certificates from the DMV, her employer, and her bank that attest these same things (through X.509 extensions). She would also have a personal certificate with her public key that she used to anchor each of these other certificates. The X.509 certificates are not linked in any way other than Alice's public key. She has to use the same public key in all of them so they can be correlated. She uses her personal certificate to prove she's in control of the public key she provides to the DMV, employer, and bank. If she changes her public key, so has to get new certificates. This is a good example of the dual nature of X.509 certificates. Alice's personal certificate looks like a DIDDoc, but the certificates with extensions look like verifiable credentials.

There's no easy way for Alice to restrict what attributes she shares when she shares these certificates. She has to share the entire certificate. Bravo would trust these certificates in the same way your browser does, by following the chain to some smallish set of trusted certificate authorities fo each kind of certificate (driver's license, employer, or bank). Bravo would also check certificate revocation lists for each certificate to ensure they're still valid.

The advantage of X.509 certificates is that the technology, processes, and governance behind them are well-known and understood. No small thing. The public key infrastructure is well developed with a long history of securely communicating trustworthy public keys. DIDs and verifiable credentials are relatively new. Although standards, open source code, and multiple vendors exist, they are unproven compared to X.509.

So, why do something new? DIDs, DIDDocs, and verifiable credentials have several advantages over X.509 certificates:

1. DIDs are more secure. DIDs allow public keys to be rotated in a trustworthy manner. Consequently, Alice can rotate the key underlying the DID at will without having to get new credentials. The identifier lives as long as Alice needs it to. Alice won't be tempted to hold onto a potentially comprimised key because she's worried about the inconvenience.
2. SSI uses the right tools for each part of the process. The SSI architecture cleanly separates providing an identifier for Alice from proving things about Alice. The binding between the DID and its associated public key can be verified cryptographically without relying on a hierarchical chain of authorities. The fidelity of the credential exchange can be verified cryptographically using information in a public credential registry (often a ledger of some sort). This separation allows the methods and tools to be crafted to the needs of each kind of document.
3. Verifiable credentials minimize information disclosure. Sharing only what's necessary protects Alice's privacy. This Webinar on ZKP-oriented Credentials from Daniel Hardman is an excellent, approachable tutorial on the many benefits of ZKPs for credential exchange.
4. SSI data sharing UX is safer. ZKPs provide convenience for Alice saving her time, and reducing the chance of her oversharing through human error (i.e. they are safer from a privacy perspective).
5. SSI has a consistent UX. SSI wallets and agents provide a good user experience for managing relationships, storing credentials, and responding to proof requests. As far as I know, X.509 certificate wallets do not exist as such, so they would need to be developed to provide a comparable user experience.
6. Verifiable credentials provide better interoperability. Alice is able to use multiple credentials from different issuers and prove things to many verifiers because of standards, not just for data formats, but also protocols for issuace and presentment. I know of no standards for how X.509 credentials can be used to prove the kind of information in the mortgage example in an interoperable way. They have been around for over 40 years and yet they are almost exclusively used for TLS and nothing else.

The high-level goals of X.509 certificates are similar to those of DIDs and verifiable credentials. But DIDs and verifiable credentials represent an innovation that takes learnings from 40 years of experience and new developments in cryptography into account to provide a better, more flexible solution to the problem of exchanging data in a trustworthy way. SSI in the form of DIDs and verifiable credentials promise a global, interoperable data exchange metasystem that is cryptographically sound with an excellent user experience.

Notes

1. The resolution need not be global or public. For Peer DIDs, the resolution is local.
2. Note that not all credential exchange methods use ZKPs. They should.