Generative DID Maximalism
Interoperability through minimal building blocks
About Joel Thorstensson
Based on my article:
“Generative DID Maximalism”
Why DIDs can’t interoperate
> 167 DID methods in the registry
Multiple VDRs prohibitively expensive for consumer devices
did:ex1
did:ex2
did:ex3
did:ex4
did:ex5
did:ex6
did:ex7
Why do we need mutability anyway?
Generative DIDs and OCAPs
Object-capabilities for delegating DID control
Object-capabilities for delegating DID control
did:ex:A
did:ex:B
Data 1
Time
Delegate *
Write
Object-capabilities for delegating DID control
did:ex:A
did:ex:B
Data 1
did:ex:B
Time
Delegate *
Revoke *
Write
Object-capabilities for delegating DID control
did:ex:A
did:ex:B
Data 1
Data 2
did:ex:B
Time
Delegate *
Revoke *
Author
Write
We need a VDR!
We need a VDR!
Legend:
🔴 Pick one
🟡 Mix and match
🟢 Easily support everything
Example generative DID methods
Method: did:key
Generative: Yes
OCAPs: UCAN or ReCap
DID Key flawlessly work’s with the methodology described above, because it’s just a plain public key. This makes it really flexible as it can easily be deployed in HSMs, in your frontend code, in your backend code, in IOT devices, etc.
Method: did:pkh
Generative: Yes
OCAPs: ReCap
DID PKH also works flawlessly without any modifications. Most of the time this DID represents a users cryptocurrency wallet. ReCap delegation is used to delegate permissions from the users wallet to a session key (often a Key DID).
Example generative DID methods
Method: did:nft
Generative: No, not currently
OCAPs: ChainProof and ReCap
There’s a live proposal to make NFT DID purely generative. How would this work? Don’t we need a blockchain full node to resolve the owner of the NFT? It turns out that we can create something called a ChainProof, which is an object capability representing a state proof and encode this using CACAO. The ChainProof would provide a proof of the owner of the NFT at a particular blockheight, a ReCap delegation can then be used to delegate write permissions further to a DID Key for example. A ChainProof can be verified by anyone using only a light client of the given blockchain.
Generative: No, doesn’t exist yet
OCAPs: ChainProof and ReCap
A DID EVM could be created as a generalization of NFT DID. This method would also use ChainProofs for object capabilities. The method identifier would include a smart contract address and an evm method signature + potential call data.
Example generative DID methods
Method: did:dns
Generative: No, not currently
OCAPs: DNSProof?
Currently DNS DID relies on resolving DNS records to generate the DID document from that. It could potentially be possible to create a generative DID method where the verification method is simply the DNS name itself, and create a new type of object capability that encodes a DNSSEC proof. Ideally this proof can be independently verified after the fact. There are many centralized services that provide historical data. Ideally we could store the signed records as an OCAPs and only use the centralized services (ideally multiple) to look up historical public keys for root servers.
Method: did:mailto
Generative: No, not currently
OCAPs: DKIMProof?
Similarly to DNS DID, Mailto DID could potentially be reimagined as a generative DID method. The DKIM-signatures could be used as object capabilities, given that we can verify historical signatures.
Discussion
Thank You