[Originally submitted to DIF's medium.com account by Daniel Hardman, lead editor on the Peer:DID specification and major contributor to the DIDComm specification]
DIDs are normally assumed to be rooted in a public source of truth like a blockchain, a database, a distributed file system, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases, and it’s been the major focus of DIF’s ID Working Group so far.
However, the vast majority of relationships between people, organizations, and things have simpler requirements, and now DIF’s thinking about those, too. When Alice (Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve their DIDs, only Alice and Bob do. Peer DIDs address these cases. Instead of storing a DID doc in an oracle, they call for a DID doc to be exchanged with a peer. This makes them unsuitable for use cases that require public reputation, but it also gives them some useful characteristics, which is why they’ve become important in various places of a decentralized identity architecture (and why it makes sense for DIF to shepherd them to adoption):
- They have no transaction costs, making them essentially free to create, store, and maintain.
- They scale and perform entirely as a function of participants, not with any central system’s capacity.
- Because they are not persisted in any central system, there is no trove to protect.
- Because only the parties to a given relationship know them, concerns about personal data and privacy regulations due to third-party data controllers or processors are much reduced.
- Because they are not beholden to any particular blockchain, they have minimal political or technical baggage.
- Because they avoid dependence on a central source of truth, peer DIDs free themselves of the often-online requirement that typifies most other DID methods, and are thus well suited to use cases that need a decentralized peer-oriented architecture. Peer DIDs can be created and maintained for an entire lifecycle without any reliance on the internet, with no degradation of trust. They thus align closely with the ethos and the architectural mindset of the local-first and offline-first software movements.
In many ways, peer DIDs are to public, blockchain-based DIDs what Ethereum Plasma or state channels are to on-chain smart contracts — or what Bitcoin’s Lightning Network is to on-chain crypto payment.
Peer DIDs were first proposed a couple of years ago in various decentralized identity circles. They already have a reasonable spec with several early implementations. However, they can benefit from a framing that uses the same general principles articulated in KERI (another DIF ID WG item). If we do our work well, peer DIDs will become a special case of KERI, and we’ll be able to generalize even further, to a DID method that is entirely blockchain-agnostic — capable of running in “peer mode” or in “anchored mode,” without associating the DID method with strong assumptions about the source of truth. This could lead to a welcome spike in interoperability that will benefit all of us.
If you are interested in joining this effort, please contact #wg-id on DIF’s slack, or email the group at id-wg@lists.identity.foundation . We meet every other Monday at 11:00 Pacific time, 20:00 Central Europe Standard Time; to join the work, reach out to membership@identity.foundation and the team will help to find a way.
