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”