Couple of weeks ago Joel Thorstensson published a post called "Generative DID Maximalism". At the time of publication, there are 167 DID methods available. We could reasonably assume, there will be more: one for every major brand, like Adobe or Facebook. Joel reasonably notices that most of the methods require quite heavy machinery to run, which does not play well with the stated goals of DID ecosystem. That plainly makes various DID methods not interoperable, in a sense that a DID-powered application would have to spend extensive resources (blockchain nodes, indexers, databases, data retrieval APIs, etc) to support all of the DID methods.

The blog post suggests we focus purely on generative DID methods, i.e. the ones that do not require external software to resolve and do not support mutability, and compose them using a revocation registry to make a user's DID mutable.

The question still remains on what to do with other ~160 DID methods, let's call them non-generative or NG. What if a user got stuck with some proprietary or heavy method, and still would like to get access to an application that supports generative DID methods only? To make the situation more concrete, let's consider Alice who is given did:ng:alice. She would like to make a Ceramic stream, which for trust reasons, only support generative DIDs, like did:key or did:pkh. How can we make that happen?

Let's play the situation. Alice authors a stream as did:ng:alice. That fails, as there is no resolver for did:ng on Ceramic nodes. Okay, let Alice have a blockchain account which maps to did:pkh. She authors a stream using did:pkh, but there is no link to did:ng:alice. That's sad. Let's delegate a capability for the action from did:ng:alice to did:pkh she owns. Again, in the process of checking the capability, we'd need to resolve did:ng:alice, which does not work. Back to square one. If only we could somehow prove that did:ng:alice is the same entity as did:pkh: did:pkh → did:ng:alice.

To solve that we'd need to have a sort of link between did:pkh and did:ng:alice. I know of two ways to do that: Verifiable Credentials (or VC) and attestations (however they are implemented). They are more or less equivalent for our purposes, so let's call both an attestation. That way the link would look did:pkh → attestation → did:ng:alice. If we trust the attester, we trust the link.

Here I get flashbacks to various discussions around trust in Verifiable Credentials realm. Let's say we have an application that gates some content just to people who has >100 Twitter followers. A user presents a credential. Formally, the credential is valid: well-formed and properly signed. What if it was issued by a malicious actor, and the user is a bot having 0 followers? The answer I get usually is, well, the app should maintain a list of trusted issuers. Seems like a yet another interoperability nightmare, unacceptable for a decentralized network.

One idea that I have to resolve that conundrum is a DAO. Yes, a thing that is not in vogue anymore. What if we could form a DAO around an attestation schema? Every DAO participant claims to truthfully issue attestations, and provides a stake. If they are found guilty by issuing a false attestation, the stake gets burned. What gets changed from an application perspective then? Instead of maintaining a list of trusted issuers, it'll have a single self-maintained source of truth if an issuer can be trusted.

So, let's do a recap of the scheme. A user acquires a non-generative DID A, which she accepts as her online persona. Then she opens an application which allows you to log in with an ephemeral generative DID. When logging in she uses an ephemeral generative DID B (generate just in time) accompanied with a proof link A → B. Now the app knows that the user is DID B, and not DID A, and could interact with a proper entity, not an ephemeral one.

While general scheme is clear, few issues remain. First, now it is generally assumed, that identification (i.e. asking for the users's account) happens independently of authentication (i.e. asking for the signature to prove ownership of the account). We as an industry would have to adopt something like CAIP-222 in a wallet to allow the user present herself as she wishes. Second, I guess, request of the attestation should be a part of the user flow: the wallet should get the attestation and present it to the application, and that should be invisible to the user.

Photo by Ben Sweet on Unsplash

Couple of weeks ago Joel Thorstensson published a post called "Generative DID Maximalism". At the time of publication, there are 167 DID methods available. We could reasonably assume, there will be more: one for every major brand, like Adobe or Facebook. Joel reasonably notices that most of the methods require quite heavy machinery to run, which does not play well with the stated goals of DID ecosystem. That plainly makes various DID methods not interoperable, in a sense that a DID-powered application would have to spend extensive resources (blockchain nodes, indexers, databases, data retrieval APIs, etc) to support all of the DID methods.

The blog post suggests we focus purely on generative DID methods, i.e. the ones that do not require external software to resolve and do not support mutability, and compose them using a revocation registry to make a user's DID mutable.

The question still remains on what to do with other ~160 DID methods, let's call them non-generative or NG. What if a user got stuck with some proprietary or heavy method, and still would like to get access to an application that supports generative DID methods only? To make the situation more concrete, let's consider Alice who is given did:ng:alice. She would like to make a Ceramic stream, which for trust reasons, only support generative DIDs, like did:key or did:pkh. How can we make that happen?

Let's play the situation. Alice authors a stream as did:ng:alice. That fails, as there is no resolver for did:ng on Ceramic nodes. Okay, let Alice have a blockchain account which maps to did:pkh. She authors a stream using did:pkh, but there is no link to did:ng:alice. That's sad. Let's delegate a capability for the action from did:ng:alice to did:pkh she owns. Again, in the process of checking the capability, we'd need to resolve did:ng:alice, which does not work. Back to square one. If only we could somehow prove that did:ng:alice is the same entity as did:pkh: did:pkh → did:ng:alice.

To solve that we'd need to have a sort of link between did:pkh and did:ng:alice. I know of two ways to do that: Verifiable Credentials (or VC) and attestations (however they are implemented). They are more or less equivalent for our purposes, so let's call both an attestation. That way the link would look did:pkh → attestation → did:ng:alice. If we trust the attester, we trust the link.

Here I get flashbacks to various discussions around trust in Verifiable Credentials realm. Let's say we have an application that gates some content just to people who has >100 Twitter followers. A user presents a credential. Formally, the credential is valid: well-formed and properly signed. What if it was issued by a malicious actor, and the user is a bot having 0 followers? The answer I get usually is, well, the app should maintain a list of trusted issuers. Seems like a yet another interoperability nightmare, unacceptable for a decentralized network.

One idea that I have to resolve that conundrum is a DAO. Yes, a thing that is not in vogue anymore. What if we could form a DAO around an attestation schema? Every DAO participant claims to truthfully issue attestations, and provides a stake. If they are found guilty by issuing a false attestation, the stake gets burned. What gets changed from an application perspective then? Instead of maintaining a list of trusted issuers, it'll have a single self-maintained source of truth if an issuer can be trusted.

So, let's do a recap of the scheme. A user acquires a non-generative DID A, which she accepts as her online persona. Then she opens an application which allows you to log in with an ephemeral generative DID. When logging in she uses an ephemeral generative DID B (generate just in time) accompanied with a proof link A → B. Now the app knows that the user is DID B, and not DID A, and could interact with a proper entity, not an ephemeral one.

While general scheme is clear, few issues remain. First, now it is generally assumed, that identification (i.e. asking for the users's account) happens independently of authentication (i.e. asking for the signature to prove ownership of the account). We as an industry would have to adopt something like CAIP-222 in a wallet to allow the user present herself as she wishes. Second, I guess, request of the attestation should be a part of the user flow: the wallet should get the attestation and present it to the application, and that should be invisible to the user.

Photo by Ben Sweet on Unsplash