#SSI101: What exactly does Spherity write to the blockchain?
Spoiler: we write less than you might expect!
Having explained why DIDs get anchored to a blockchain, we turn next to what exactly each of those anchors looks like: “look-up records” in an addressing system similar to email, except without central authorities. Then, we can turn to how blockchains differ for DID-anchoring purposes, and to how the blockchain-agnostic, interoperable W3C standard organizes them all to work together. If you’ve been reading our SSI 101 series start to finish, you’ll be a DID expert by the end of this entry!
Deep-dive: DIDs as an addressing system
The best way to understand the “blockchain” part of blockchain identity is that a DID works like an email address. Before the “@” of an email address, you have a unique, individual “account name”, and after “@,” you have what we call an email’s “domain,” which we could think of as the published alias of the relevant account-handler that manages that unique account name on its mail servers. Domains are published and updated through the same domain name service (DNS) that governs web addresses, through the same system of whitelists, spam blacklists, and mutually-updating registries administered by the internet utility company, ICANN.
In a DID, the unique string equivalent to an email “account name” is a DID’s “method-specific identifier,” a long, non-human-meaningful string of characters and letters which is the “public” half of a cryptographic keypair. These public keys look very different from method to method, because they are generated by different cryptographic systems. (In most cases today, this public key is what we would colloquially call a Bitcoin or Ethereum “address,” since cryptocurrencies use the same cryptography to track the pseudonymous “accounts” that hold and transfer assets between them.) Before we can explain how these DID public keys are used to verify an identity or information signed by that identity, though, we’ll have to explain the rest of the addressing system.
The DID equivalent of an email “domain” is called a “DID method” which is a technical name for the platform-specific “driver,” or set of rules, for tracking down current contact information for a given unique, individual entity. A common misconception is that a DID method is synonymous with a blockchain, but many blockchains (Ethereum and its DLT forks in particular) can be anchored and accessed by many different methods. Even though a method refers to a set of rules rather than to a specific address, database, or body of information, the analogy to email still works fairly well: each identifier is unique within a given domain, and to “resolve” (get actionable contact information) about the former, you must first query the latter about the former, requiring you to first “resolve” the latter.
In the case of email, this is a relatively simple 1-to-1 translation: the centralized domain name server (DNS) system translates a name like “@spherity.com” to the IP address where spherity’s mailservers can be found, who will answer to the name “spherity.com” and handle incoming mail for all its accounts. From there, a straightforward client-to-server communication can take place, with a real address, discussing a third party: the specific account managed by that server.
In the case of DIDs, there are more steps to avoid this kind of centralized registry, although the results are still analogous. Unlike a DNS record that sits in an administered, hierarchical database, A DID Method combs through a horizontal blockchain or other data store looking for self-published records and updated. It gathers these and returns these real-time results in a standard format called a “DID document”: this information “anchors” the DID that authored it to a blockchain in a timestamped, public way. For more information on the differences between this “self-publishing” system and more conventional registries, see the previous entry in this series.
In the case of an update or revocation, all W3C-compliant methods return the most recent record, even if that record contains nothing, or a link to another method, which is what it will contain if a DID subject exercises the DID standard’s agnosticism to the fullest by moving their DID document to another chain and method. In this case, the “resolution” process simply starts over by querying the next method in the chain of records, in which case it might comb back through another blockchain.
For this reason, a DID method can be thought of as a kind of “lookup function”: a very simple algorithm for verifying and finding all the DIDs that self-publish contact information on a given blockchain or permissioned ledger and return the most recent record for further processing, verification, communication, etc.
“DID Documents”: the business card of the decentralized web
A DID Document, the public record representing a decentralized identity, can be thought of like a business card, containing a minimum of actionable information:
- the public key — or a set of public signing keys — of the entity who created and controls the record
- authentication mechanism by which DID controllers can cryptographically prove that they are associated with a DID
- a crypographic “proof” and contextual information about the cryptographical “curve” (equations) can be used to verify that proof against that public key, minimizing the need to interact with any outside authority or other software to check the validity of the document
- time metadata about when the DID was initially created and, if applicable, when it was most recently updated, rotated, or added to
- in a few cases, “schema” and/or “context” information allowing platform-specific structures for extra information and future extensibility (see the official W3C documentation for more information)
- one or more “service endpoints,” which are long strings that function as addresses (like URLs) which might be needed for further verification or communication services, usually handled by what contemporary programmers call “APIs” (“application programming interfaces,” for server-to-server communications)
To continue the analogy to email, one of these service endpoints might specify a communication protocol (and address) for direct, human-to-human communication, the equivalent of the email server address to which the second half of an email “resolves.” However, this is only one kind of service endpoint: endpoints are their own complex, multi-dimensional form of addressing, which can range from the highly fixed and trackable (not much different than a phone number or an email address) to the highly contextual and privacy-preserving. For more on the latter, see our forthcoming 101 on tracking and privacy.
As for the more static and persistent kinds of service endpoints, one use case discussed in our 201 article about intelligent serial numbers makes persistent, public tracking information available via an endpoint directing any actor (machine or human) to a webpage or an even more persistent read-only resource where recycling or licensing information is displayed. In many other use-cases, endpoints point to services running in a cloud that provide information to other services running elsewhere on the internet, allowing collaborative automation beyond the organizational boundaries of the original DID subject publishing the record. These could entail data transactions, cryptocurrency transactions, search queries; the format is deliberately open-ended to allow future forms of communication between data “services” not yet designed today.
A blockchain by any other name
One other way in which the DID anchoring system is future-proofed is that it is entirely agnostic about the blockchains themselves. Any fully-public or public-permissioned digital ledger can have DIDs anchored to it, including testnets and permissioned “side-chains” within a given blockchain system. The Ethereum method that Spherity uses, for instance, can be configured to anchor DIDs to, and retrieve DID documents from, all the various Ethereum testnets, Ethereum’s mainnet, or permissioned Quorum chains interchangeably. What’s more, a Spherity DID can be “moved” (i.e. re-anchored) between these chains, or even moved to a completely different method and a different kind of blockchain at any time, without losing its history or invalidating its signatures on old data.
Posting (or updating) a DID document can carry a transaction cost (and a carbon footprint) vanishingly close to zero on a testnet or on a permissioned ledger, although the permissions to such a ledger are usually expensive in some other way.
Meanwhile, on a public blockchain based on Proof-of-Work, a small amount of “gas” or equivalent transaction fee is usually required at the time of registration for the “miner” whose block will contain the DID document as a payload. Unfortunately, virtual “gas” isn’t the only thing burnt by public blockchain traffic. The carbon footprint of a transaction on a public Ethereum blockchain equals approximately the daily consumption of 1.25 US households. If you would like to provide decentralized identity to 1.000.000 manufactured products it super unsustainable and uneconomically to anchor their DIDs on a PoW chain (stay tuned for founder Carsten Stoecker’s forthcoming 301 proposal for a more sustainable useful PoW mechanism!). These blockchain-specific details are administered by the method, and the software systems built by Spherity and others to anchor DIDs according to a given method handle these details invisibly in the background.
It is worth noting, in the interest of future-proofing this very article, that slipping tiny JSON-formatted DID documents into the non-transaction storage area of a cryptocurrency blockchain is not the only imaginable way to create a decentralized registry for self-published DID documents. All that a DID registry really requires is a relatively long-lived, persistent record generated from the consensus of different, independent authorities, that can serve as an uncontroversial publication vehicle on a global scale; at the moment, blockchains and DLTs offer the only feasible incentive and governance structures for administering such a publication record. Research into theoretical alternatives such as IPFS-based sidetree protocol or cloud journals is ongoing, though: there is currently a project being incubated within the decentralized identity community to create a network of cloud-based logging agents that would maintain a common state via a similar consensus-mechanism, although it is unclear if this will replace or supplement the existing blockchain anchoring. Spherity is very committed to experiment with and adopt the alternatives to PoW-blockchain based DID methods.
On-chain identities, secure off-chain data
The blockchain-anchoring of DIDs described so far is really the lowest level or “layer” of the decentralized identity system Spherity is building in cooperation with the broader SSI community. By itself, however, it is not that powerful, and its complex mechanisms to decentralize and operate without registries would seem overkill if all they powered was an alternate addressing system. The true power of DIDs lies in their relationship to off-chain data stored in the next layer of the decentralized identity stack: Verified Credentials, which are discrete, portable, and entirely off-chain units of data. When compared to other systems that use blockchains to track sensitive or controversial information, the breakthrough of SSI lies exactly in this one feature: because the controlling identities have been encoded and maintained on-chain, their valuable information need not be.
The main benefits of storing valuable information on a blockchain (reliable and authoritative time-stamping, cryptographic proof of authenticity, and tamper-proofing of contents) can be achieved by independent, off-chain verified credentials, which are cryptographically bound to on-chain identities in a time-stamped and self-tamper-proofing way that proves its own authenticity. Indeed, as long as the relationship between on-chain identities and off-chain information is handled carefully, that data retains all the privacy, portability, minimization, and accuracy rights guaranteed to its subject(s) by the GDPR.
Nothing else needs to be stored on-chain, unencrypted, or in any publically-accessible way, and Spherity, like most major SSI solution providers, uses digital ledgers and blockchains for little else, in keeping with the principle of data minimization (which applies triply when the data is stored immutably and in public!). This Minimum Use of Blockchain Principle and Spherity’s serverless cloud identity infrastructure ensure that identity related operations and agent-to-agent transactions scale very nicely and significantly off-chain.
One notable exception to this minimization are the on-chain reference materials used by so-called “zero-knowledge” credential systems, which can selectively share or prove pieces of a Verified Credential without revealing the entire credential. Similarly, some SSI systems other than Spherity’s use an on-chain revocation registry to simplify the “end-of-life” of DID documents or Verifiable Credentials. But these are, strictly speaking, implementation-specific exceptions to the basic rule that a DID is anchored to a blockchain only at birth and at “rotation” or updating; the rest of its data, as well as its true value and utility, lives off-chain.
Another implementation-specific complication worth mentioning is the work Spherity has done to integrate trust systems rooted in blockchain records with more traditional, institutional roots of trust, such as government identity registries housed on traditional servers backed by Credential Authority (CA) certificates and addressable via nationally-controlled namespaces (aka “government DNS”). Digital identity credentials issued to citizens or to registered legal persons (i.e., companies or organizations) can be “re-signed” or “co-signed” by their DIDs and wrapped in VCs, linking (in a granular, privacy-preserving way) government identities and decentralized ones. This offers the security and control of a decentralized identity for establishing a channel of communication with an unknown counterparty, but leaves open the option, within that channel of communication, to provide official, centralized credentials, should the situation require that additional, external root of trust. In this way, the best of the decentralized world and the centralized world are available: individual users and the kinds of trust necessitated by their use-cases can negotiate which exact admixture they need of privacy and institutional backing.
Having left the blockchain behind, we can now turn in our next entry to the Verified Credentials themselves, which are the “killer app” of the SSI ecosystem: they enable credential-based trust between any two parties and audit trails with the highest possible levels of privacy and security.
