Technical Deep Dive: From SSI to zkID – The Evolution of Digital Identity

Digital identity is shifting from centralized databases to user-centric architectures. For developers, this effectively means moving from a "Collect and Protect" liability model to a "Verify and Forget" paradigm.

This article explores the technical primitives (DIDs, VCs) and the cryptographic evolution attempting to solve the "Privacy vs. Verifiability" dilemma: from SD-JWTs to BBS+ and finally zk-SNARKs (zkID).

1. The Primitives: DID & VC

Before diving into ZK, we must establish the two W3C standards that serve as the foundation.

Decentralized Identifiers (DIDs)

A DID is a cryptographically verifiable global unique identifier. Think of it as a user_id that isn't owned by a database admin but by a private key.

Key Definition: did:method:identifier

• Persistent: Never changes.
• Resolvable: Resolves to a "DID Document" containing public keys and service endpoints.

// Example: Creating a DID anchored to Ethereum (did:ethr)
import { EthrDID } from 'ethr-did';
import { Wallet } from 'ethers';

const wallet = Wallet.createRandom();
const did = new EthrDID({
  identifier: wallet.address,
  privateKey: wallet.privateKey
});

console.log(did.did); // Output: did:ethr:0x123...

Note: DIDs are blockchain-agnostic. did:web (DNS-based) and did:key (Key-based) are common alternatives.

Verifiable Credentials (VCs)

A VC is a JSON object signed by an Issuer's DID. It contains claims about a Subject (Holder).

// Simplified VC Structure
{
  "issuer": "did:web:university.edu",
  "credentialSubject": {
    "id": "did:ethr:alice",
    "degree": "Computer Science"
  },
  "proof": {
    "type": "EcdsaSecp256k1Signature2019",
    "jwt": "eyJ..." // The signature
  }
}

2. The Privacy Problem: Unlinkability

Standard VCs satisfy Authenticity (signed by issuer) and Integrity (tamper-proof). However, identifying the "Holder" usually requires revealing the full credential or a unique signature, which creates tracking vectors.

We need two properties:

1. Selective Disclosure: Revealing only specific fields (e.g., "Age" but not "Name").
2. Unlinkability: Presenting the same credential to two different verifiers without them being able to correlate the user.

Here is how modern cryptography attempts to solve this.

3. The Evolution of Privacy Solutions

Approach A: SD-JWT (Selective Disclosure JWT)

The Practical First Step

Instead of signing the whole JSON payload, the Issuer salts and hashes each claim individually.

• Mechanism: Hash(Claim + Salt) is signed.
• Disclosure: Holder reveals the plaintext claim and the salt. Verifier re-computes hash and checks signature.
• Trade-off:
  • ✅ Selective Disclosure: Works well.
  • ❌ No Unlinkability: The underlying signature is static. If you show the same SD-JWT to Verifier A and Verifier B, they can collude and track you via the unique signature hash.
  • ⚠️ Compliance Risk: Likely incompatible with strict privacy regulations (e.g., EU ARF guidelines on unlinkability).

For a detailed analysis of why the Ethereum Foundation and EU are moving away from SD-JWT, read our strategic deep dive: Ethereum Foundation's Privacy Strategy.

Approach B: BBS+ Signatures

The Cryptographic Upgrade

BBS (Boneh-Boyen-Shacham) signatures allow "Zero-Knowledge Proofs of Knowledge of a Signature".

• Mechanism: The Issuer signs a set of messages. The Holder can generate a unique ZK proof that they possess a valid signature on these messages, revealing only a subset.
• Trade-off:
  • ✅ Unlinkability: Every proof is mathematically unique. Verifier A cannot link the user to Verifier B.
  • ❌ Rigid Logic: You can only prove what is in the credential structure. (e.g., Proving "Age > 18" is hard if the VC only contains "Birthdate: 2000-01-01" without complex predicates).
  • ❌ Performance: Verification is computationally heavier than ECDSA/RSA.

Approach C: zkID (zk-SNARKs)

The Ultimate Paradigm

Here, we decouple the data from the proving logic entirely.

• Mechanism:
  1. Issuer signs attributes (e.g., birthDate: 1990-01-01).
  2. Holder generates a zk-SNARK (e.g., using Circom, Noir, or Halo2) inside their wallet.
  3. Circuit Logic: "I have a signed credential from Issuer X where currentDate - birthDate > 18".
• Trade-off:
  • ✅ Maximum Flexibility: You can prove computation on top of data. (e.g., "Is my credit score enough for this loan?" without revealing the score).
  • ✅ Future Proof: Issuer doesn't need to know the verification logic beforehand.
  • ❌ Client-Side Cost: High proving time on mobile (though improving with folding schemes like Nova).

4. Architecture Shift: "Verify and Forget"

Adopting zkID changes the fundamental backend architecture.

Conclusion

We are moving towards a stack where Identity is the platform.

For developers, the winning move is to stop hoarding user data. By leveraging standards like DIDs for addressing and ZKP (zkID) for proving, we can build applications that are verifiable by default and private by design.

References

• W3C Verifiable Credentials v2.0
• Ethr-DID Repository
• Vitalik Buterin on zkID
• BBS Signatures (NIST)