Data Minimisation

Data minimisation is a legal and organizational principle: an organization that collects or processes personal data should collect and keep only what it actually needs for a stated purpose, not extra fields gathered "in case they're useful later," not data retained past the point it's needed, not more than the specific task requires.

Where it comes from

The idea predates modern data-protection law by decades. The OECD's 1980 privacy guidelines set out a "Collection Limitation Principle", one of eight founding principles of international data-protection policy, requiring that personal data be obtained by lawful, fair means and, where appropriate, with the subject's knowledge or consent, and limited to what's needed. The EU turned a version of this into binding law: Article 5(1)(c) of the GDPR (Regulation (EU) 2016/679) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed", one of seven core principles listed in GDPR Article 5, sitting alongside purpose limitation, storage limitation, and four others. Solidus wrote none of this; it's binding EU law, not a design choice any company gets to opt into or out of within its jurisdiction.

Not the same thing as Minimal Disclosure

It's worth being precise about a distinction this Lexicon draws deliberately: Data Minimisation is a legal duty imposed on organizations by data-protection regulators. Minimal Disclosure (a separate entry in this Lexicon) is a design principle for identity systems specifically, articulated by Kim Cameron in 2005, aimed at architects rather than compliance officers. They push in the same direction and often get satisfied by the same engineering, but one is law, the other is a design law, and conflating them makes both harder to reason about precisely.

Solidus's honest position

Solidus's own whitepaper contains a section titled "GDPR Compliance by Design," which describes data minimisation (citing Article 5(1)(c) directly) as one of several principles the architecture is built to support. That's worth stating for what it actually is: Solidus's own specification document describing a design intent, not an independent legal opinion, not a Data Protection Impact Assessment, not a regulator's finding. None of those exist yet. Solidus has not appointed a Data Protection Officer, has not completed a DPIA for its biometric KYC flows, and makes no claim of GDPR compliance as a certified or assessed status.

What is independently checkable, and narrower: the actual technical mechanism that limits what a credential presentation discloses, selective disclosure, documented in full under that entry, genuinely runs. Solidus's live testnet issuer speaks SD-JWT VC (confirmed via its OID4VCI metadata), and a BBS+ path exists on the same testnet but remains unaudited. "This architecture is built to disclose less data than handing over a full credential" is a claim you can check yourself, right now. "Solidus is GDPR compliant" is not a claim Solidus makes, and this entry does not make it either.

Check it yourself

curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer confirms the live SD-JWT selective-disclosure path, the concrete, checkable piece of this. There is no equivalent public artifact for a legal-compliance assessment, because none has been performed.