Discussion: W3C Decentralized Identity Support

[kamescg]

Opening up this issue to start the conversation around how the Coinbase Smart Wallet can natively support W3C decentralized identifiers and verifiable credentials.

Context

For the most part it feels like the Ethereum ecosystem has mostly "poo-pooed" on the idea of decentralized identity if it's not onchain. And while I certainly understand that perspective, I still believe there is a lot of benefit to exploring and possibly supporting the W3C decentralized identifiers and verifiable credentials in a future smart account stack.

Early on in Ethereum's history the uPort team created an EVM based decentralized identifier standard.

Arguably it was (wayyy) to early in the smart account evolution to matter, but those foundations ultimately became what is Account Abstraction today i.e. created and popularized the "meta-transactions" standard allowing third-parties to pay gas costs for users.

I mention this because as Coinbase helps usher in a new era of smart accounts, I believe it's worth looking to the past for inspiration and ideas that may be worth bringing into the future.

Where do we stand today with decentralized identity?

As of today the did:pkh standard has received the most adoption. Why? It's simple, allows any Ethereum PK to become a DID and doesn't require a ton of technical infrastructure to support.

But the did:pkh standard has some serious limitations. it's not possible to rotate keys, update the did document, and thus you really can't rely on it for a long-running decentralized identity or take full advantage of DID capabilities.

Proposal

Several months ago the "Decentralized Identity System" proposal and prototype was published on Github.

did:dis Proposal: https://github.com/decentralized-identity-system/did-dis
Safe Module Implementation: https://github.com/decentralized-identity-system/safe-did-dis

The did:dis proposal outlines how to natively support the W3C decentralized identifier and verifiable credential standard in EVM based smart accounts - overcoming the problems inherit to uPort's original designs (paying gas to update the DID) by using the Cross-Chain Interoperability Protocol (EIP-3668) to support offchain lookups for a user managed DID document.

┌──────┐                                          ┌────────┐ ┌───────────────────┐
│Client│                                          │Contract│ │Identity Hub @ url │
└──┬───┘                                          └───┬────┘ └──────┬────────────┘
   │                                                  │             │
   │ did(...)                                         │             │
   ├─────────────────────────────────────────────────►│             │
   │                                                  │             │
   │ revert OffchainData(sender, urls, callData,      │             │
   │                     callbackFunction, extraData) │             │
   │◄─────────────────────────────────────────────────┤             │
   │                                                  │             │
   │ HTTP request (sender, callData)                  │             │
   ├──────────────────────────────────────────────────┼────────────►│
   │                                                  │             │
   │ Response (result)                                │             │
   │◄─────────────────────────────────────────────────┼─────────────┤
   │                                                  │             │
   │ document(result, extraData)                      │             │
   ├─────────────────────────────────────────────────►│             │
   │                                                  │             │
   │ answer                                           │             │
   │◄─────────────────────────────────────────────────┤             │
   │                                                  │             │

Similar to Farcaster it takes a "sufficiently decentralized" approach by intertwining onchain and offchain infrastructure to achieve a desired objective: scalable identity primitive that uses a blockchain as thin trust layer.

Technical Considerations

For the most part natively supporting the W3C decentralized identifiers and verifiable credential in a smart account can be handled in module and is not required to be a part of the core smart account logic.

So similar to the Safe multi-sig setup it would be great if the CoinbaseSmartWalletFactory.sol can also be passed calldata to enable a module in the createAccount(bytes[] calldata owners, uint256 nonce) function. Given the the nature of "transaction bundling" in ERC-4337 this can probably also be achieved in two separate transactions confirmed during a single block, but for simplicities sake it might make sense to overload that function with the ability to enable modules using the ERC-7579 standard.

But... the current did:dis proposal does require updating the Factory contract to also be a DID resolver and support counterfactual instantiation of DID document without having to deploy a smart wallet on a specific network.

Example of a constructed did:dis identifier.

did:dis:8453:0x1111111111111111111111111111111111111111:0x9999999999999999999999999999999999999999

CHAIN_ID = 8453
RESOLVER = 0x1111111111111111111111111111111111111111
ACCOUNT = 0x9999999999999999999999999999999999999999

The CHAIN_ID is used locate the RESOLVER smart contract, which in turn uses the EIP-3668 standard to fetch a DID document via an offchain Identity Hub managed by the ACCOUNT even if a smart account hasn't been deployed.

Designed so users can first start a decentralized identity then progressively convert it into a smart account. The reasoning for this is outlined in the very length post about a "meta-strategy for onboarding a million users".

https://hackmd.io/@kames/progressive-commitment-thresholds

tl;dr

The W3C decentralized identifiers and verifiable credentials standard are powerful primitives.

Since the Coinbase Smart Wallet is likely to be one of the dominant smart account implementations I think it's worthwhile to ask if and how the stack can also give users access to privacy preserving decentralized identity primitives

While I did write and create the did:dis proposal/prototypes, so smart accounts can natively support these standards I'm not necessarily promoting them as the "right" answer, but more-so referencing it as a way to think about intertwining onchain/offchain APIs for a scalable solution that can meet the future demands of a decentralized internet.

In fact if the RESOLVER element was stripped from the did:dis standard proposal DID support could be completely handled in a module and not require any updates to any of the core Coinbase Smart Wallet logic.