Why Web3 Primitives Belong in Identity, Selectively

The buzzword reflex

For a stretch of years, every identity-adjacent product launch had to mention blockchain, decentralization, or web3 to be taken seriously by a certain investor cohort. Then the pendulum swung the other way: any product that did mention those things got dismissed as marketing fluff. Both reflexes are bad.

The honest answer is that web3 primitives — verifiable credentials, signed update provenance, decentralized identifiers — solve some specific problems extraordinarily well, and solve other problems badly or not at all. The discipline is knowing which is which.

Where web3 primitives shine

Three places, in our architecture:

• Update provenance. When an institution receives an address change for a customer, it needs to verify (a) that the change was actually authorized by the right human, and (b) that the change has not been tampered with in transit. Cryptographic signatures backed by verifiable credentials solve this cleanly. No central registry required, no trust-the-issuer leap.
• Revocation. When a user disconnects a vendor, both parties need a tamper-evident record of when the disconnection happened, who triggered it, and what authorizations were in scope at the moment. Append-only signed logs do this elegantly.
• Cross-institutional reconciliation. When two institutions independently maintain copies of the same identity field, they need a way to detect drift and agree on the canonical record. Merkle-tree-based attestations let them do this without a central coordinator.

Where web3 primitives don't belong

Personal data itself never goes on a public ledger. Period. The blockchain is a poor database for sensitive personal information, and a worse one for compliance with regulations like GDPR's right-to-erasure. We use the cryptographic primitives. We do not use the public ledger as a data store. Anyone telling you otherwise is selling something.

Smart-contract escrow of personal data is also off the table for the same reason. The substrate for personal data has to be erasable; ledgers are designed not to be.

The pragmatic line

Use cryptographic provenance everywhere. Use distributed ledgers only where they materially improve auditability without exposing personal data. And resist the temptation to over-decentralize for the sake of brand positioning. The user doesn't care about decentralization — they care about not having to update their address forty-seven times.