Data minimisation, real at the disclosure step, and the opposite of minimal at the collection step

Our architecture is built to minimise what a verification discloses, through an unaudited selective-disclosure path. It does not minimise what we collect: we ingest a full identity document and a biometric capture, which is the maximum for the purpose, not the minimum. Nothing here is legal advice.

The principle

Collect only what the stated purpose requires, and keep it no longer than that purpose needs. It is Article 5 of the GDPR, and the equivalent principle in Türkiye's KVKK, and the hotel ruling is the clearest illustration of it biting in practice: submit the required fields, do not hoard the document they came from.

Where we genuinely minimise

At the disclosure step, and it is checkable:

$ curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer
  format : vc+sd-jwt

200, checked 2026-07-31. A relying party can be given the attribute it needs, a date of birth, a residency status, without receiving the document, the photograph, or the identifier that joins the person to every other record about them.

At the retention step, in the schema rather than in a policy: identity documents, selfies and voice audio carry a purge timestamp defaulting to 30 days; session recordings to 365 days. The purge deletes the stored object and then the row, and for recordings it deletes the media while keeping the non-personal integrity verdict, which is the right shape: erase the personal material, retain the evidence that a check happened.

That second mechanism is the most genuinely minimising thing we have built, and it is described in full on right to erasure versus the audit trail.

Where we do not minimise at all, and will not pretend to

To establish that a document is genuine and that a live person matches it, we need the whole document and a live capture. There is no version of that check that takes less.

So at the point of collection we are maximal, not minimal, and any page implying otherwise would be describing a different product. What our architecture changes is what happens after, how much travels onward, and how long it stays.

That is a real and useful property. It is not the same as collecting less, and the difference matters to anyone reading Article 5 carefully.

Four bounds on what we just claimed

• Unlinkability requires BBS+, and BBS+ is unaudited. SD-JWT gives selective disclosure; it is linkable across presentations by design. See selective disclosure mechanics.
• The purge ships defaulting to dry-run. A deployment that never enables it retains everything while appearing to have retention.
• Retention is not per-customer. A retention_days field exists on the organisation record and nothing reads it: the window is deployment-wide, despite the schema implying a customer could set their own.
• Nobody has assessed any of this. Our own whitepaper describes data minimisation under a heading about compliance by design. That is a design intent stated in our own document, not a data protection impact assessment, not an independent legal assessment, and not a regulator's finding. No such assessment has happened.

The sentence to take away

"The architecture is built to support minimising disclosed data" is true. "Solidus has been assessed as compliant" is not. They are different claims, and only the first one has evidence behind it.