Benoit Leger-Derville
The best customer database might be the one you never built.
Since 2002, Nicolas Chalanset and I have championed one conviction at Stelau: authenticating people and checking their rights should not require collecting their digital lives.
The wallet opens that door. Information systems now need to step through it.
Less data to keep. Less data to have stolen.
Ten documents to teach a class. Seriously?
For a teaching assignment, I received this request. Identity, diplomas, insurance, criminal record, bank details… A complete file, soon scattered across email, applications and backups.
Before teaching, please send us…
Before 1 January
- 01Supplier information form
- 02Professional registration
- 03URSSAF compliance certificate
- 04Professional liability insurance
- 05Copies of diplomas
- 06Disability status evidence (RQTH)
- 07ID card, both sides, or passport
- 08Criminal record extract, bulletin no. 3
- 09Forecast annual quotation
- 10Certified bank details
The documents and their conditions, in full
- Supplier information form. The provider form to complete.
- Professional registration. Less than 6 months old: a commercial register extract (K, L, Kbis or Lbis), D1, SIREN notice, or training activity declaration, depending on status.
- URSSAF compliance certificate. Less than 6 months old.
- Professional liability insurance. The insurance certificate.
- Copies of diplomas. Evidence of qualifications.
- Disability status evidence (RQTH). For self-employed workers with the relevant French disability status (TIH), where applicable.
- ID card, both sides, or passport. A copy of the identity document.
- Criminal record extract, bulletin no. 3. Less than 3 months old.
- Forecast annual quotation. The expected contractual teaching volume.
- Certified bank details. For payment of invoices.
An example request received by Benoit. Registration documents are alternatives depending on professional status; the disability document applies only to the relevant self-employed worker status. This is not a Stelau recommended checklist.
Download GIF ↓Download GIF ↓
Every request has a purpose. But checking a qualification does not require keeping a diploma copy everywhere. We automated collection. It is time to automate verification.
Tomorrow’s systems will know how to ask again
STOP COLLECTING · VERIFY AS NEEDED · KEEP MINIMAL EVIDENCE.
Request what matters. Verify it. Use it. Delete what no longer needs to be retained. Ask again when the need returns. A one-off use should no longer become a permanent record by default.
Sending a letter? Obtain the address for that delivery, then remove it from the business workflow. Or delegate dispatch to an authorised provider without copying the address into every application.
Sending an email later? Arrange a bounded contact channel: a relationship-specific alias, relay or notification. One purpose, an expiry, revocation. Without a channel or mandate arranged in advance, a new interaction with the person will be needed.
The hotel invoice? Ask for the necessary details at the right moment. Keep the invoice under applicable obligations. Remove unnecessary working copies.
These architectures still need to be built and integrated. An alias or relay reference may remain personal data; sharing approval does not replace a lawful basis for processing. Storing less does not mean losing the ability to operate. It means designing differently.
Useful evidence, not your entire life
A purpose-built qualification credential makes the principle clear. The issuer signs a credential bound to your key. The RP requests the necessary attributes; you approve sharing; the wallet produces proof for this exchange.
One credential. Three actors. Two signatures.
From issuance to presentation: follow the VC, select attributes and test its binding to the holder’s key.
Issuer / Provider
Qualification body
iss · vct · _sd
cnf.jwk = HIssuer signatureWallet / Holder
Your attributes, your choice
RP / Verifier
Teaching service
qualification_valid
trueAwaiting presentationPresentation verifiedThe issuer signs a VC bound to key H.
The wallet proves possession of H. The issuer records its public key in cnf.jwk and signs the credential.
- iss
- issuer.example.test
- vct
- …/qualification
- _sd_alg
- sha-256
- _sd
- 4 × SHA-256
- cnf.jwk
- H P-256
- qualification_valid
- true
- name
- Camille Exemple
- birthdate
- 1999-04-12
- address
- Adresse fictive / fictional address
The values below are in the wallet’s disclosures. The signed JWT holds their salted digests, not these values in clear text.
The RP requests a qualification, not a file.
Compare a minimal and a named request. Each carries a recipient (client_id) and a challenge (nonce).
- client_id
- x509_san_dns:rp-a.example.test
- nonce
- …
- dcql_query
- claims: [ qualification_valid ]
Approve the requested attributes. The others stay local.
Selection follows the DCQL request. You can refuse sharing; the wallet does not send unrequested attributes.
qualification_valid: trueDisclosures for unrequested attributes stay in the wallet. An incomplete response to the request will not be sent.
Private key H signs proof for this presentation.
The KB-JWT binds the selected attributes to the recipient, challenge and time of the exchange.
cnf.jwk- aud
- …rp-a.example.test
- nonce
- …
- iat
- …
- sd_hash
- SHA-256( SD-JWT ~ disclosures ~ )
The KB-JWT signature is checked with key H from cnf.jwk. sd_hash binds the proof to the SD-JWT and disclosures actually presented.
The RP checks both signatures and the context.
A copied VC without key H fails. A presentation signed for RP-A does not answer RP-B’s request. Try it.
qualification_valid: true- Issuer signature—
- Disclosure digests—
- Signature with key H—
- Recipient + challenge + time—
- Presentation digest—
This binding does not stop copying received information. It prevents a new valid presentation without key H, or replaying this one in a different context.
The request is not satisfied. Approve the requested attributes, or refuse sharing.
Sharing refused. No presentation sent.
Cryptographic operations are unavailable in this browser. The educational steps and messages remain readable.
Inspect messages and signatures
Payload excerpts. The RP’s signed Request Object and X.509 trust, OAuth, metadata, status and hardware attestation are not walked through. No external service calls.
Ephemeral private keys, non-exportable through WebCrypto. In a real wallet, signing can be protected by a local or remote WSCA/WSCD (HSM).
VC: signed payload
Computed locally when the demo starts.OID4VCI: proof of possession of H
Computed locally when the demo starts.OID4VCI: Credential Request
Computed locally when the demo starts.OID4VCI: Credential Response
Computed locally when the demo starts.OID4VP: request (parameter excerpt)
Computed locally when the demo starts.KB-JWT: signed payload
Computed locally when the demo starts.OID4VP: Authorization Response (decoded vp_token)
Computed locally when the demo starts.The five steps in text
- Issue. The wallet proves possession of H. The issuer records its public key in cnf.jwk and signs the credential.
- Request. Compare a minimal and a named request. Each carries a recipient (client_id) and a challenge (nonce).
- Select. Selection follows the DCQL request. You can refuse sharing; the wallet does not send unrequested attributes.
- Bind. The KB-JWT binds the selected attributes to the recipient, challenge and time of the exchange.
- Verify. A copied VC without key H fails. A presentation signed for RP-A does not answer RP-B’s request. Try it.
The issuer’s signature protects the attested attributes. The holder’s proof binds the presentation to its recipient and the exchange’s challenge. Another service cannot simply replay it as a valid response to its own request. This does not stop the first recipient copying information it received: share less in the first place.
A retained record must support a specific decision, for a defined period. It is not automatically anonymous or re-auditable cryptographic evidence. Replacing a file of copies with a vault of complete presentations would miss the point.
2026–2031: stop collecting by default
Five moves for the next five years. A direction for work, not a regulatory timetable.
- — 2027
Find the excess
Identify and remove copies with no reason to remain.
- — 2028
Switch to evidence
A verified qualification instead of a duplicated diploma.
- — 2029
Ask again, just in time
One-off data. Authorised contact channels.
- — 2030
Break the chain of copies
CRM, logs, exports, backups: stop copying by default.
- — 2031
Scale it up
Extend, measure what remains, test failures and alternatives.
We do not need to wait for “ZKP everywhere”. Focused credentials and data obtained when needed already offer a starting point. Outages, lost phones and accessible alternatives must also be designed in: data minimisation has to work in real life.
The wallet is only the beginning
Issuers and wallets will continue to retain data. The shift is to stop copying it into every information system.
At Stelau, our work on wallets, applied cryptography and Nested VDS pursues that target: from data to evidence, from storage to verification.
Further reading
OID4VCI 1.0 · OID4VP 1.0 · SD-JWT and key binding — RFC 9901 · EUDI architecture · CNIL: retention · Consent · Anonymisation.
← All articles