A question kept coming back to me while I was reading through Sign’s identity architecture.
If a government issues you a digital credential, how much of that credential does a verifier actually need to see?
It sounds like a philosophical question. It’s actually a systems design question, and the answer has enormous consequences for how national identity infrastructure gets built. Most existing digital ID systems answer it the same way: the verifier sees everything. You present your credential, the verifier checks it, all the data flows across. Age, address, tax number, employment status, whatever the credential contains. The system is efficient. The privacy model is essentially nonexistent.
Sign’s New ID System takes a different position, and it’s the one I’ve been thinking about most carefully.
The architecture is built around W3C Verifiable Credentials and Decentralized Identifiers, which are open standards that have been developing in the identity space for several years. But the implementation detail that caught my attention is selective disclosure. The idea is that a holder, a citizen in a sovereign deployment, can present only the specific attributes from a credential that a verifier needs, without exposing the rest. A bar needs to know you’re over eighteen. It doesn’t need your date of birth, your address, or your national ID number. Selective disclosure lets you prove the claim without revealing the underlying data.
This is technically possible through several mechanisms. Standard selective disclosure uses credential formats that allow partial revelation of signed fields. More advanced approaches use zero-knowledge proofs, where you can prove a statement about your data is true without revealing the data itself. Sign’s documentation references ZK attestations as a privacy-enhanced mode in their evidence layer, applicable where the deployment requires it.
I want to be careful here about what ZK proofs actually do and don’t solve, because this is an area where a lot of infrastructure projects oversell the capability.
A ZK proof lets you prove a computation was performed correctly without revealing the inputs. In an identity context, this means you can prove “my age is greater than 18” without revealing your actual birthdate, and the verifier can cryptographically confirm the proof is valid without ever seeing the underlying credential data. That’s genuinely powerful. But ZK systems have their own complexity costs: proof generation is computationally expensive, especially on mobile devices, verification requires the right circuit implementations, and the trust model shifts significantly toward whoever designed the circuit. If the circuit is wrong or compromised, the proof system fails silently in ways that can be very hard to detect.
For a national identity system running at scale, these tradeoffs matter practically, not just theoretically.
What I find more immediately interesting in Sign’s architecture is the offline verification pattern. Their documentation mentions QR and NFC presentation as required capabilities for national deployments. This is the scenario that gets overlooked in most Web3 identity discussions: what happens when a citizen needs to verify their credential and there’s no internet connection? In a wealthy urban environment, connectivity is assumed. In the actual deployment contexts where sovereign identity infrastructure matters most, connectivity is intermittent or absent.
Offline verification requires the credential to be self-contained and the verification to be executable locally without querying a remote server. The cryptographic signature on the credential does most of this work. But revocation is harder. If a credential has been revoked after it was issued, an offline verifier can’t check a live revocation registry. Sign references W3C Bitstring Status List as their revocation mechanism, which allows a compressed status list to be cached and verified offline within an acceptable staleness window. It’s not perfect. It’s a practical compromise that acknowledges real-world conditions rather than pretending connectivity is universal.
The issuer governance layer is the third piece I’ve been looking at carefully. In a national identity system, not everyone can issue credentials. A driver’s license can only be issued by an authorized transport authority. A professional certification can only come from an accredited body. The trust registry is the component that defines which issuers are authorized for which credential types, what keys they’re using, and what schemas their credentials conform to. Sign’s architecture includes this as a defined component in the ID system.
I’ve been skeptical about whether trust registries actually work in practice. The technical model is straightforward. The operational reality is that governments change, agencies restructure, issuing bodies get decommissioned or compromised, and key rotation needs to happen without breaking existing credentials. These are hard operational problems that live below the level of architecture documentation and show up only when deployments go live.
The selective disclosure model also has an interesting second-order effect worth thinking about. If citizens can selectively present credentials, verifiers are incentivized to request minimal data rather than hoarding everything. That’s the opposite of how most digital identity systems behave today. Most systems collect everything they can because data is cheap to store and potentially valuable later. A system where you can only get what you explicitly request, and where the citizen controls what they reveal, fundamentally changes the incentive structure.
That shift is harder to achieve than the technical implementation. It requires verifiers to actually adopt the standard, which requires the standard to be mandated or strongly incentivized at the national level. Sign is building the infrastructure. Whether the policy layer creates the conditions for it to work as intended is not something any protocol can fully control.
Still, the architectural direction here is more thoughtful than most identity systems I’ve reviewed.