## **Groth16/ZK DID Specification**

- [W3C DID Core Specification](https://www.w3.org/TR/did-core/), which defines how DIDs are structured and resolved.
- A DID consists of three parts:
- **Scheme**: Always `did`.
- **Method**: Identifies the DID method (e.g., `did:example:123456` where `example` is the method).
- **Method-Specific Identifier**: Identifies the unique entity within the method.

### 1. **Purpose of the DID Method**
The main purpose of this DID method is to ensure compliance with W3C standards for verifying proofs generated by zk-SNARK protocols like Groth16. It aims to support both on-chain and off-chain verification processes.

- This DID method can be used either on-chain (EVM) or off-chain (server-side verification).
- The method should resolve proofs issued from zk protocols like zk-email, Semaphore, Anon Aadhaar, and OpenPassport.
- It should specify all the methods needed to verify a Groth16 proof, including:
- Fetching artifacts (proving key, verification key) from decentralized storage.
- Verifying the proof both on-chain and off-chain.

### 2. **Design of the DID Method**
- **Method Name**: `did:zkp`.
- **Identifier Structure**: The DID identifier (`@id`) should be derived from the verification key. There could be also a specificier for the network when the method index to an on-chain verification (e.g. `did:zkp:scroll-mainnet:123456789abcdefghi`)
- **Resolution**: The DID can be resolved in two ways:
- **On-chain**: The method should resolve the Ethereum address where the contracts are stored and include the network ID. The Solidity function signature for verifying proofs could be provided via an SDK, which wraps the call to the smart contract's verification method.
- **Off-chain**: The method should resolve the verification key stored on decentralized storage (e.g., IPFS) along with the public signals that are part of the proof. The verification process could either be delivered within an SDK (which implements the `verify` method) or through a server endpoint that verifies the proof.

### **DID Document Example (JSON-LD Format)**
The DID Document structure must support verification methods, authentication, and service endpoints.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:zkp:123456789abcdefghi",
  "verificationMethod": [
    {
      "id": "did:zkp:123456789abcdefghi#keys-1",
      "type": "Groth16VerificationKey",
      "controller": "did:zkp:123456789abcdefghi", // Entity that controls the DID
      "verificationKeyUri": "ipfs://Qm...",
      "onChainAddress": "0x1234...",
      "networkId": "1"  // Ethereum Mainnet
    }
  ],
  "service": [
    {
      "id": "did:zkp:123456789abcdefghi#proof-verification",
      "type": "Groth16ProofVerificationService",
      "serviceEndpoint": "https://zkp-verification.com/verify"
    }
  ]
}

### 3. **Storage Layer**
The storage layer for this DID method can consist of both blockchain and decentralized storage systems:

- **Blockchain-based DIDs**: These would resolve to EVM contracts that verify the Groth16 proofs using a Solidity verifier.
- **Non-blockchain storage**: Artifacts like the proving key, verification key can be stored in decentralized storage solutions such as IPFS, ensuring availability and integrity.

### 4. **Security Considerations**
For zk-proof-based DIDs, security is of paramount importance. This could be out of Scope for Now. Here are a few key considerations:

- **Verification Key Authenticity**: You need to ensure that the verification key stored on IPFS or the blockchain has not been tampered with. Techniques like cryptographic hashing (e.g., storing the hash of the key) or digital signatures could be used to verify its integrity.
- **Trusted Setup Validation**: If your system relies on a trusted setup ceremony for generating the zk-SNARK parameters, you may want to incorporate a proof or attestation that the setup was conducted securely. This can involve proving that the ceremony was conducted in a transparent, trusted environment.