The well-known usage of X.509 certificates is TLS (Transport Layer Security), but X.509 certificates are used in other various places. For example, in the OAuth world, RFC 8705 defines methods to utilize X.509 certificates for client authentication and certificate-bound access tokens. Please visit “OAuth 2.0 Client Authentication” and “OAuth Access Token Implementation” for further technical details.
I hope this article could help you understand the basics of X.509 certificates. Finally, I highly recommend “Bulletproof SSL and TLS” (by Ivan Ristić) for deeper dive.
Nice find! Our lineage is something like “X.509 → SPKI/SDSI → UCAN”, so these diagrams very roughly describe our signature chains.
UCAN today is a “1.2. Self-Contained Type” from the OAuth 2.0 Client Authentication link, but with specific keys. We also importantly have an (unimplemented) solution to “4.4. Access Token Revocation” thanks to CIDs and having a secure data store with public data (WNFS).
4.4. Access Token Revocation
It is difficult, if not impossible, to revoke self-contained-type access tokens. Because the structure is the same as that of PKI certificate, a mechanism equivalent to PKI’s CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) must be in operation in order to revoke self-contained-type access tokens before their expiration.
The key distinction here is that we can have a user-hosted source of truth. Since everything works on the edge and offline, we’re always forking state locally and synchronizing the head (like Git), so changing the (e.g.) database doesn’t depend on a central store, and can always be rolled back. In X.509 or OAuth, you always need a live connection to check on your auth for your central resources. This sounds like a digression from UCANs, but it’s really essential for them to work at all, and is what is meant by “we believe that our system largely solves a the final few issues of SPKI”
