Selective Disclosure and Privacy-Preserving Proofs
What wallet privacy promises rest on.
Wallets promise that people can share only what is needed. This course explains the techniques behind that promise, shows where each technique stops, and helps you judge claims about privacy in credential systems. It is a Knowledge course: you learn to explain and recognise, and you check that understanding with a quiz.
Who it is for
- HR and learning technology owners who will receive credentials from wallets (audience C3).
- Education IT and credential operations staff who will issue them (audience E4).
- Members of the standards and wallet community who want a shared vocabulary (audience P3).
Prerequisite: ICB-F06 Digital Identity and the EUDI Wallet: Essentials.
Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill SECP "Security, privacy and data protection" (VRITE pillar: Trustworthiness), level L4 "Assure", stage K "Knowledge". At this level the skill is: leads threat modelling and fraud prevention for credential systems; advises on key management and long-term validity. This course builds the knowledge that supports that skill. It does not prove that you can do the work.
Learning outcomes
- Explain the selective disclosure techniques used in wallet credentials.
- Compare credential formats by their privacy properties.
- Describe what zero-knowledge proofs could add and how mature they are.
Workload: self-paced, 3 hours notional learning. Live or workshop elements appear as facilitator notes.
Assessment: a knowledge check of 10 questions at the end of the course. Each module also has a short practice quiz that does not count towards the badge.
Badge: "Selective Disclosure and Privacy-Preserving Proofs (Knowledge, L4)", alignment code ICSF-SECP-L4-K. Evidence: passed knowledge check.
| Outcome | Module | How it is assessed |
|---|---|---|
| 1. Explain the selective disclosure techniques used in wallet credentials | Selective disclosure | Module quiz; final knowledge check, questions 1 to 3 |
| 2. Compare credential formats by their privacy properties | Formats compared | Module quiz; final knowledge check, questions 4 to 6 |
| 2. Compare credential formats by their privacy properties | Unlinkability | Module quiz; final knowledge check, questions 7 and 8 |
| 3. Describe what zero-knowledge proofs could add and how mature they are | Zero-knowledge proofs | Module quiz; final knowledge check, questions 9 and 10 |
Status of the topics in this course
| Topic | Status | Note |
|---|---|---|
| Wallet protocols and credential formats (OpenID4VC, SD-JWT VC, ISO mdoc) | Emerging | Specified for the EUDI Wallet; tooling and education profiles are still maturing. |
| EUDI Wallet (eIDAS 2.0) | Emerging | Member States must offer at least one wallet by 24 December 2026. Germany plans its state wallet ('d-you') for 2 January 2027 with basic functions first. Regulated private sectors must accept the wallet about one year after issuance starts. Readiness varies widely between Member States. |
Status as of November 2026; check before publishing.
Facilitator notes
**Optional live element (45 minutes, after Module 3):** a workshop where participants bring one credential use case from their own organisation and sketch what the verifier really needs to see. Close with a round in which each participant names one claim they would stop collecting. Prepare a flipchart with the four module titles. Ask participants to place sticky notes for questions they still have after each module. Use these notes to steer the discussion.Selective disclosure
Why share less
Think about a person who needs to prove one fact. A training provider wants to know that an applicant holds a professional certificate. The paper certificate also shows a full name, a date of birth, a home address and a grade. The provider needs one fact, and the paper shows five.
A wallet can do better. Selective disclosure lets the holder reveal only some of the claims in a credential while the verifier can still check that the credential is genuine and unchanged. The verifier receives less data, and the holder keeps control over the rest.
Three roles take part:
- The issuer creates and signs the credential.
- The holder keeps it in a wallet and decides what to show.
- The verifier asks for proof and checks it.
The central difficulty is this. A normal digital signature covers the whole document. If the holder removes a claim, the signature no longer matches, and the verifier cannot trust what is left. Selective disclosure techniques solve exactly this problem: they let a signature stay valid while some claims stay hidden.
Two ideas help you keep the topic clear:
- Data minimisation means collecting only the data you need for a stated purpose. Selective disclosure is a technical tool that supports it. The principle itself comes from data protection law and practice.
- Disclosure and proof are different things. A holder can disclose a claim, which reveals its value. A holder can also prove a statement about a claim, such as "over 18", without revealing the birth date. The second kind of proof needs extra support in the credential or in the wallet.
Salted hashes: the main wallet technique
The technique most relevant to current wallet formats uses salted hashes. A hash function turns any input into a fixed-length fingerprint. The same input always gives the same fingerprint, and it is not practical to work backwards from the fingerprint to the input.
The issuer follows these steps:
- For each claim, such as "family name" or "course title", the issuer adds a random value called a salt.
- The issuer computes a hash of each salted claim.
- The issuer signs the list of hashes, not the claims themselves.
- The issuer gives the holder the signed list plus every claim with its salt.
When the holder presents the credential, the holder sends the signed list and only the chosen claims with their salts. The verifier hashes each disclosed claim, finds the matching fingerprint in the signed list, and checks the issuer's signature. Claims that stay hidden show up only as fingerprints. Because each has a random salt, the verifier cannot guess the hidden value by trying likely candidates.
This pattern is the basis of SD-JWT VC, one of the credential formats named for the EUDI Wallet. ISO mdoc uses a related idea: each data element is hashed and the hashes are signed, so the holder can release single elements. The details differ, and Module 2 compares them.
![A credential discloses only selected claims](data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 450" width="100%" role="img"><title>A credential disclosing only selected claims</title><desc>A credential signed by an issuer holds four claims. The holder sends only two of them, family name and course title, to the verifier. Date of birth and home address stay hidden as fingerprints.</desc><rect x="0" y="0" width="800" height="450" fill="%23FFFFFF"/><rect x="30" y="60" width="260" height="330" rx="6" fill="%23F1F5F8" stroke="%23D8E2E9" stroke-width="2"/><text x="50" y="92" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Credential in the wallet</text><rect x="50" y="110" width="220" height="40" rx="6" fill="%23B1CF37" stroke="%2302375B" stroke-width="2"/><text x="60" y="135" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Family name: shown</text><rect x="50" y="165" width="220" height="40" rx="6" fill="%23B1CF37" stroke="%2302375B" stroke-width="2"/><text x="60" y="190" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Course title: shown</text><rect x="50" y="220" width="220" height="40" rx="6" fill="%23FFFFFF" stroke="%234F6576" stroke-width="2" stroke-dasharray="6 4"/><text x="60" y="245" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Date of birth: hidden</text><rect x="50" y="275" width="220" height="40" rx="6" fill="%23FFFFFF" stroke="%234F6576" stroke-width="2" stroke-dasharray="6 4"/><text x="60" y="300" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Home address: hidden</text><text x="50" y="350" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Signed by the issuer</text><path d="M290 160 L500 160" stroke="%2302375B" stroke-width="2" fill="none"/><path d="M490 152 L500 160 L490 168" stroke="%2302375B" stroke-width="2" fill="none"/><text x="300" y="145" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Holder sends 2 claims</text><rect x="510" y="110" width="260" height="130" rx="6" fill="%235DCAE7" stroke="%2302375B" stroke-width="2"/><text x="530" y="145" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Verifier receives</text><text x="530" y="175" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Family name, course title,</text><text x="530" y="197" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">fingerprints, signature</text><text x="530" y="270" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Hidden claims appear only as</text><text x="530" y="292" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">fingerprints that cannot be reversed.</text></svg>)
Other approaches and their limits
Salted hashes are one family of techniques. Others exist, and you may meet them in standards discussions.
Per-claim signatures. The issuer signs each claim separately. The holder can pass on single signed claims. This is simple, but the claims can lose their link to each other, and the credential becomes harder to manage.
Signature schemes with built-in selective disclosure. Some signature schemes let a holder derive a proof from the original signature that covers only the chosen claims. The verifier checks the derived proof against the issuer's public key. These schemes can also help with unlinkability, which Module 3 covers. They are less widely deployed in wallet profiles than salted-hash formats.
Predicate proofs. A predicate proof shows that a claim meets a condition, such as "birth date is before a given day", without showing the value. Zero-knowledge techniques make this possible, and Module 4 returns to it.
What selective disclosure with salted hashes does not do matters as much as what it does:
- The signature, the issuer's key and the structure of the credential stay visible and are the same each time the holder presents the credential. A verifier, or several verifiers who compare notes, can recognise the same credential again. This is a linkability problem.
- Disclosed claims are shown in full. A holder cannot show "over 18" from a birth date unless the issuer has also issued an "over 18" claim, or the format supports a proof about the value.
- The verifier can keep whatever it receives. The technique limits what is sent. It cannot limit what the verifier does afterwards. Policy, law and audit have to cover that.
Selective disclosure reduces what a verifier receives. It does not control what the verifier does with it.
Worked example: The corporate academy checks a safety certificate
The learning technology owner at a manufacturing company, Ms Okafor, wants contractors to show a site safety certificate before they enter a plant. The certificate in the contractor's wallet holds four claims: full name, certificate title, expiry date and home address.
At the gate, the verification service asks for three things: certificate title, expiry date and whether the signature is valid. The contractor's wallet shows these three. The home address stays hidden, covered only by its fingerprint.
The plant keeps a log of each entry. Ms Okafor's team checks that the log holds the title and expiry date and not the address. The data protection officer notes that the plant never had a reason to hold the address, so the design removes a risk instead of managing one.
Ms Okafor asks: what could still be linked? The same signature and issuer key appear at every gate visit. If the plant shares its log with a second site, both could see that one contractor entered both. She records this as a question for Module 3.
Practice activity: Minimise a request
Choose a credential check from your own work, for example proof of employment, proof of a course completion or proof of a professional licence. Write down:
- The one decision the verifier must make.
- The claims the verifier would need to make it.
- The claims the credential holds that the verifier does not need.
- Which of the unneeded claims could be misused if the verifier stored them.
Keep your notes for the workshop or for your own use. There is no single right answer. The point is the habit of starting from the decision and not from the credential.
Facilitator notes
Ask participants to share their lists in pairs. Look for cases where the "needed" list is longer than it should be. Common examples are date of birth when only an age check is needed, and full name when only a membership check is needed. Note the cases where a predicate such as "over 18" would help and where a claim would have to be issued for it. Time: 10 minutes for the activity and 10 minutes for discussion.Check your understanding
A signature is computed over the complete content. If the holder removes a claim, the content changes and the signature no longer matches. Selective disclosure techniques, such as signing hashes of salted claims, solve this by letting the signature cover fingerprints that stay valid when some claims are hidden.
The issuer signs the list of hashes. The claims and their salts travel separately to the holder. The holder can then reveal a chosen claim and its salt, and the verifier checks that the hash matches an entry in the signed list.
Without a salt, a verifier could hash every likely value, for example every possible grade, and compare the results with the fingerprint. A random salt per claim makes such guessing impractical.
Selective disclosure limits what is sent. It cannot limit what the verifier stores or does afterwards. Law, policy and audit have to cover that part.
Formats compared
Three formats, three families
The EUDI Wallet specifications name credential formats and protocols that work together. Learners often mix up the format, which describes the credential, and the protocol, which moves it. This module looks at formats and keeps protocols to a short note at the end.
SD-JWT VC. A credential built on JSON Web Tokens with selective disclosure through salted hashes. The issuer signs a token that holds hashes of the claims. The holder receives the token and the claims with their salts, and chooses which to reveal. SD-JWT VC is a credential format that fits web-style systems well, because it builds on JSON, a common data format.
ISO mdoc. A credential format from the ISO/IEC 18013-5 family, first designed for mobile driving licences. Data elements are grouped by namespace, each element is hashed, and the issuer signs a structure that holds the hashes. The holder releases single elements. mdoc uses a compact binary encoding and was designed with proximity use in mind, such as a presentation at a counter.
W3C Verifiable Credentials with data integrity proofs. A credential model from the World Wide Web Consortium. It can use different proof types, including signature schemes that support selective disclosure and unlinkability by design. Whether a given deployment offers these properties depends on the proof type that the deployment chooses.
Two points apply to all three:
- A format sets the technical possibilities. A wallet, an issuer profile and a verifier policy decide what happens in practice.
- A format that supports a property does not guarantee it. For example, a format may allow single-use credentials, but an issuer may still issue one reusable credential.
Comparing privacy properties
To compare formats you need a short list of properties. Use these:
- Selective disclosure: can the holder reveal single claims?
- Predicate proofs: can the holder prove a statement about a value without showing it?
- Verifier unlinkability: can two verifiers tell that the same credential was shown to both?
- Issuer unlinkability: can the issuer tell where a credential was shown?
- Offline presentation: can the holder present without a network connection?
- Maturity in wallet profiles: how settled is the format in the EUDI Wallet context?
The table below gives a cautious summary of the general position. It describes typical designs, and actual profiles may add or remove features.
![Format comparison table](data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 450" width="100%" role="img"><title>Format comparison by privacy property</title><desc>A table with three formats in the columns: SD-JWT VC, ISO mdoc and a data integrity credential with an advanced signature. Rows show selective disclosure, same credential recognisable across verifiers, and typical use. SD-JWT VC and ISO mdoc support selective disclosure but a reused credential can be recognised. The advanced signature type can avoid this.</desc><rect x="0" y="0" width="800" height="450" fill="%23FFFFFF"/><rect x="30" y="40" width="740" height="50" rx="6" fill="%23F1F5F8" stroke="%23D8E2E9" stroke-width="2"/><text x="50" y="72" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Property</text><text x="250" y="72" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">SD-JWT VC</text><text x="430" y="72" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">ISO mdoc</text><text x="600" y="72" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Advanced signature</text><rect x="30" y="100" width="740" height="70" rx="6" fill="%23FFFFFF" stroke="%23D8E2E9" stroke-width="2"/><text x="50" y="140" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Selective disclosure</text><rect x="240" y="115" width="140" height="40" rx="6" fill="%23B1CF37" stroke="%2302375B" stroke-width="2"/><text x="255" y="140" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Yes, per claim</text><rect x="420" y="115" width="140" height="40" rx="6" fill="%23B1CF37" stroke="%2302375B" stroke-width="2"/><text x="435" y="140" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Yes, per element</text><rect x="590" y="115" width="160" height="40" rx="6" fill="%23B1CF37" stroke="%2302375B" stroke-width="2"/><text x="605" y="140" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Yes, derived proof</text><rect x="30" y="180" width="740" height="70" rx="6" fill="%23FFFFFF" stroke="%23D8E2E9" stroke-width="2"/><text x="50" y="205" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Same credential</text><text x="50" y="225" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">recognisable?</text><rect x="240" y="195" width="140" height="40" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="255" y="220" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Yes, if reused</text><rect x="420" y="195" width="140" height="40" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="435" y="220" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Yes, if reused</text><rect x="590" y="195" width="160" height="40" rx="6" fill="%235DCAE7" stroke="%2302375B" stroke-width="2"/><text x="605" y="220" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Can be avoided</text><rect x="30" y="260" width="740" height="70" rx="6" fill="%23FFFFFF" stroke="%23D8E2E9" stroke-width="2"/><text x="50" y="300" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Typical setting</text><text x="250" y="292" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Web and online</text><text x="250" y="312" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">presentation</text><text x="430" y="292" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Proximity and</text><text x="430" y="312" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">online presentation</text><text x="600" y="292" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Depends on the</text><text x="600" y="312" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">chosen profile</text><text x="30" y="370" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Typical designs only. Actual profiles may differ. Orange marks a privacy limit, lime a supported feature.</text><text x="30" y="395" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Cyan marks a property that depends on the proof type chosen.</text></svg>)
| Property | SD-JWT VC | ISO mdoc | Data integrity credential with an advanced signature |
|---|---|---|---|
| Selective disclosure | Yes, per claim, through salted hashes | Yes, per data element, through hashed elements | Yes, through a derived proof, depending on the proof type |
| Predicate proofs | Not by itself; needs an extra claim or an extra technique | Not by itself; needs an extra element or an extra technique | Possible in some designs |
| Verifier unlinkability | Limited: the issuer signature repeats when the credential is reused | Limited: the issuer signature repeats when the credential is reused | Possible, depending on the proof type |
| Issuer unlinkability | Limited | Limited | Possible, depending on the proof type |
| Offline presentation | Depends on the profile | Designed with proximity use in mind | Depends on the profile |
| Maturity in EUDI Wallet context | Emerging; specified for the EUDI Wallet | Emerging; specified for the EUDI Wallet | Less settled in the EUDI Wallet context |
Use this table as a starting point for questions, not as a procurement answer. Real decisions need the current profile text and a threat model.
What decides privacy in practice
Privacy depends on more than the format. Four layers matter:
- The format, which sets what is possible.
- The issuer profile, which decides how credentials are issued. An issuer that signs one long-lived credential creates a stable identifier. An issuer that signs a batch of single-use credentials removes much of it. Batch issuance is a design choice that some profiles support, and it is one way to reduce linkability even with salted hash formats.
- The wallet, which decides what the holder can see and choose. A wallet that shows clearly which claims a verifier asks for supports informed consent. A wallet that hides this does not.
- The verifier, which decides what to ask for and how long to keep it. A verifier that asks for more than it needs, or stores what it receives, weakens every other layer.
Protocols, in short. OpenID4VC names a family of protocols for issuing and presenting credentials over the web. ISO/IEC 18013-5 describes proximity presentation for mdoc. A format can often travel over more than one protocol. When you read a specification, first ask whether it describes the credential or the way it moves.
Worked example: The university chooses a format for graduation credentials
A university registry, led by Dr Lindqvist, plans to issue digital degree credentials to graduates. Graduates will show them to employers, to other universities and to professional bodies.
Dr Lindqvist's team lists the likely verifiers and what each needs:
- An employer needs the degree title, the awarding institution and the award year.
- A second university needs the degree title and the grade band.
- A professional body needs the degree title and a confirmation of name.
All three formats from this module allow selective disclosure, so each verifier can receive its own subset. The team then asks the next question: do the graduates need protection from being tracked across these verifiers? The team notes that a graduate may show the credential to many employers over several years. With a reusable credential in a salted hash format, the same issuer signature would repeat each time.
The team decides to ask the issuer profile working group whether batch issuance of single-use credentials is supported, and to record the open question in the privacy impact assessment. It does not pick a format yet. It sets out its criteria first.
Practice activity: Build a comparison for your own context
Take your own organisation and list three likely verifiers of a credential you issue or receive. For each verifier, write down:
- The claims it needs.
- Whether the holder would mind if two verifiers could tell the credential was the same.
- Which of the properties in the comparison table matters most to you, and why.
Then write one sentence for each of the four layers (format, issuer profile, wallet, verifier) that describes what you would want to check.
Facilitator notes
Run a short group exercise: split the group into issuers, holders and verifiers. Each group writes the two privacy properties it cares most about. Compare the lists. Typical results: issuers care about maturity and tooling, holders care about unlinkability and clear consent screens, verifiers care about simplicity and legal clarity. Remind participants that the table is a simplification and that profiles change. Direct them to the primary sources in the final section. Time: 15 minutes.Check your understanding
A format, such as SD-JWT VC or ISO mdoc, describes the credential itself. A protocol, such as those in the OpenID4VC family or the proximity protocol in ISO/IEC 18013-5, describes how credentials are issued and presented.
Both formats let the holder reveal chosen claims or elements. The issuer signature and key repeat when the same credential is reused, so verifiers who compare notes can recognise it.
Selective disclosure still works, but the signature and issuer data repeat at each presentation. Batch issuance of single-use credentials is one way to reduce this, if the profile supports it.
Privacy depends on four layers: format, issuer profile, wallet and verifier. A table of typical designs cannot capture all of them. Current profile text and a threat model are needed for real decisions.
Unlinkability
What linking means
Selective disclosure limits what a verifier sees in one presentation. Unlinkability asks a different question: can anyone connect two presentations to the same holder or the same credential?
Linking can happen in several ways:
- Between verifiers. Verifier A and verifier B compare what they received. If a value, such as a signature or a key, is the same in both, they know the same credential was used. If they also hold a name or an identifier, they learn that the holder visited both.
- Between visits to the same verifier. A verifier can recognise a returning holder through repeated values and build a history.
- Between issuer and verifier. An issuer that sees where its credentials are shown, or a verifier that shares data with the issuer, can learn about the holder's activity. This is sometimes called the "phone home" problem. It arises when a verifier must contact the issuer to check a credential. Designs in which the verifier checks the signature locally, without contacting the issuer, avoid this.
- Through the data itself. A few disclosed claims can be unique enough to identify a person. A birth date, a postcode and a job title together can single someone out, even without a name. This is a re-identification risk, and no cryptography removes it.
It helps to separate three terms:
- Selective disclosure: revealing only some claims.
- Unlinkability: preventing presentations from being tied together.
- Anonymity: not being identifiable at all. A presentation with a name is not anonymous, even if it is unlinkable to other presentations.
A credential system can offer one without the others. A presentation that shows only the course title may still be linkable if the issuer signature repeats.
Techniques that reduce linking
Several techniques reduce linking. Each has costs.
Batch issuance of single-use credentials. The issuer gives the wallet many copies of the same credential, each signed separately and each with its own key material. The wallet uses each copy once. Verifiers cannot tell that two copies belong to the same holder from the signature alone. The cost is operational: the issuer has to produce, store and replace many credentials, and the wallet has to manage them. When the batch runs out, the holder must obtain more, and rules must decide how often.
Short-lived credentials. A credential with a short validity period limits how long a stable value can be tracked. The holder must renew often, which depends on a good issuer connection.
Signature schemes with unlinkable proofs. Some schemes let the holder derive a fresh proof from the same credential for each presentation. The proofs cannot be linked by their signature values. This is the approach that supports unlinkability without batch issuance. It depends on newer cryptography that is less settled in wallet profiles.
Local verification. The verifier checks the signature and the status data without telling the issuer. Where a credential needs a status check, such as revocation, the design of the status mechanism matters. A status check that queries one credential at a time can reveal which credential is being checked. Designs that publish status data in a way that does not identify one holder reduce this.
Pairwise or per-verifier identifiers. Where a verifier needs to recognise a returning holder, a wallet can provide an identifier that differs for each verifier. Two verifiers then cannot join their records by that identifier.
![Linking between verifiers](data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 450" width="100%" role="img"><title>Two verifiers compare a repeated signature</title><desc>On the left, a holder presents the same credential to verifier A and verifier B. Both receive the same signature value. They compare notes and learn that one holder visited both. On the right, the holder presents two single-use credentials with different signature values. The verifiers cannot connect them by signature.</desc><rect x="0" y="0" width="800" height="450" fill="%23FFFFFF"/><text x="30" y="40" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Reused credential</text><text x="440" y="40" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Single-use credentials</text><line x1="400" y1="20" x2="400" y2="430" stroke="%23D8E2E9" stroke-width="2"/><circle cx="90" cy="215" r="40" fill="%2302375B"/><text x="90" y="220" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%23FFFFFF">Holder</text><rect x="240" y="80" width="140" height="70" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="310" y="110" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier A</text><text x="310" y="132" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">sees value X7</text><rect x="240" y="280" width="140" height="70" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="310" y="310" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier B</text><text x="310" y="332" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">sees value X7</text><path d="M128 200 L240 125" stroke="%2302375B" stroke-width="2" fill="none"/><path d="M128 230 L240 305" stroke="%2302375B" stroke-width="2" fill="none"/><text x="250" y="225" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Same value: linked</text><circle cx="490" cy="215" r="40" fill="%2302375B"/><text x="490" y="220" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%23FFFFFF">Holder</text><rect x="640" y="80" width="140" height="70" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="710" y="110" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier A</text><text x="710" y="132" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">sees value K2</text><rect x="640" y="280" width="140" height="70" rx="6" fill="%23F78222" stroke="%2302375B" stroke-width="2"/><text x="710" y="310" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier B</text><text x="710" y="332" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">sees value M9</text><path d="M528 200 L640 125" stroke="%2302375B" stroke-width="2" fill="none"/><path d="M528 230 L640 305" stroke="%2302375B" stroke-width="2" fill="none"/><text x="590" y="225" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Different values</text><text x="30" y="410" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Values X7, K2 and M9 stand for signature data. They are illustrative.</text></svg>)
What no technique fixes alone. If the disclosed claims identify a person, unlinkable signatures do not help. If the verifier asks for a national identifier that is the same everywhere, verifiers can link by that value. The best result comes from combining a careful request (Module 1), a suitable issuing profile (Module 2), and a technique from this module.
Worked example: The HR department designs a contractor check
An HR operations lead, Mr Brandt, runs onboarding for external trainers. Each trainer shows a teaching qualification credential at three points: on first registration, when a course is assigned, and when a training room is booked. These checks are run by three different services.
Mr Brandt's team notices that if the credential is reusable, all three services receive the same signature and could join their logs. They look at what each service really needs. The room booking needs only to know that the trainer is registered, which the registration service already knows.
The team makes three changes:
- The registration service verifies the qualification once and issues an internal, short-lived access token to the trainer.
- The course assignment service asks for the qualification title only.
- The room booking service never sees the qualification credential at all.
This design needs no new cryptography. It reduces linking by reducing how many parties see the credential. Mr Brandt adds a note that for trainers who also work at other organisations, a wallet profile with batch issuance would reduce linking across employers, and he asks the education provider that issues the qualification whether it supports it.
Practice activity: Trace the links
Draw, on paper, one credential journey from your own context: the issuer, the wallet and up to three verifiers. Mark every value that stays the same across presentations, such as a signature, a key or an identifier. Then mark any claim that could single a person out when combined with another. Circle the three links that would worry you most and write one possible change for each.
Facilitator notes
This module fits the live workshop. Give each group an A3 sheet. Ask them to draw one journey and mark repeating values with an orange pen. Collect the circled links on a wall and sort them: "fix by design", "fix by technique", "fix by policy". Many links fall into the first or third group, which supports the message that cryptography is one tool among several. Time: 20 minutes.Check your understanding
When two verifiers see the same signature or key, they can tell that the same credential was used, and can join their records if they share data. Showing one claim or signing hashes does not by itself connect separate presentations.
A presentation with a name is not anonymous, but it can still be unlinkable to other presentations if the cryptographic values differ each time.
In batch issuance the issuer signs many copies, each with its own key material, and the wallet uses each once. Verifiers cannot connect them by signature. The cost is operational effort for the issuer and the wallet.
The booking decision needs only the fact that the trainer is registered. Removing the credential from that step reduces linking by reducing how many parties see it.
Zero-knowledge proofs
What a zero-knowledge proof is
A zero-knowledge proof lets one party, the prover, convince another, the verifier, that a statement is true without revealing why it is true. The verifier learns that the statement holds and learns nothing else.
A classic way to picture this: a prover wants to show that two objects are different without saying which is which. The prover can do this through a repeated game in which a verifier cannot guess the answer unless the prover really can tell the objects apart. After enough rounds, the verifier is convinced, and has learned nothing about the details.
In credential systems, the statement is something like "I hold a credential signed by this issuer, and the birth date in it is before a given day." The proof convinces the verifier of this. The verifier does not see the birth date, the signature or any other claim.
Zero-knowledge proofs have three properties:
- Completeness: an honest prover with a true statement can convince the verifier.
- Soundness: a prover with a false statement cannot convince the verifier, except with a very small chance.
- Zero knowledge: the verifier learns nothing beyond the fact that the statement is true.
You do not need the mathematics for this course. You need to recognise what the technique promises and to ask good questions about it.
What they could add
Compared with the salted hash approach from Module 1, zero-knowledge proofs could add several things.
Predicate proofs. A holder can prove "over 18", "resident in a given country" or "grade at least a pass" from the underlying value, without the issuer having to issue each derived claim in advance.
Stronger unlinkability. A holder can create a new proof for each presentation from the same credential. Each proof looks different, so verifiers cannot connect them by signature values.
Proofs about several credentials. A holder can prove a statement that combines claims from more than one credential, such as "the person in this degree credential is the person in this identity credential", without revealing the underlying data. This is an area of active research and specification work.
Proof of holding a key without revealing it, which supports binding a credential to a wallet.
Less dependence on single-use batches. A zero-knowledge approach can offer unlinkability from one credential, which reduces the operational load of batch issuance.
![What zero-knowledge proofs could add](data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 450" width="100%" role="img"><title>Disclosure compared with a zero-knowledge predicate proof</title><desc>Two rows. In the first row, the holder discloses a birth date and the verifier sees the date. In the second row, the holder sends a zero-knowledge proof and the verifier sees only the result: over 18, yes. The birth date stays with the holder.</desc><rect x="0" y="0" width="800" height="450" fill="%23FFFFFF"/><text x="30" y="40" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Disclosure of a claim</text><circle cx="80" cy="110" r="36" fill="%2302375B"/><text x="80" y="115" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%23FFFFFF">Holder</text><path d="M120 110 L400 110" stroke="%2302375B" stroke-width="2" fill="none"/><path d="M390 102 L400 110 L390 118" stroke="%2302375B" stroke-width="2" fill="none"/><rect x="190" y="85" width="140" height="50" rx="6" fill="%23FFFFFF" stroke="%2302375B" stroke-width="2"/><text x="260" y="115" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Birth date: shown</text><rect x="410" y="75" width="360" height="70" rx="6" fill="%235DCAE7" stroke="%2302375B" stroke-width="2"/><text x="430" y="105" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier sees the birth date</text><text x="430" y="127" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">and works out the age itself</text><line x1="30" y1="200" x2="770" y2="200" stroke="%23D8E2E9" stroke-width="2"/><text x="30" y="240" font-family="Open Sans, Arial, sans-serif" font-size="16" font-weight="bold" fill="%2302375B">Zero-knowledge predicate proof</text><circle cx="80" cy="310" r="36" fill="%2302375B"/><text x="80" y="315" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%23FFFFFF">Holder</text><path d="M120 310 L400 310" stroke="%2302375B" stroke-width="2" fill="none"/><path d="M390 302 L400 310 L390 318" stroke="%2302375B" stroke-width="2" fill="none"/><rect x="170" y="285" width="180" height="50" rx="6" fill="%23FFFFFF" stroke="%2302375B" stroke-width="2"/><text x="260" y="315" text-anchor="middle" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Proof: over 18</text><rect x="410" y="275" width="360" height="70" rx="6" fill="%235DCAE7" stroke="%2302375B" stroke-width="2"/><text x="430" y="305" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">Verifier learns only: over 18, yes</text><text x="430" y="327" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%2302375B">The birth date stays with the holder</text><text x="30" y="400" font-family="Open Sans, Arial, sans-serif" font-size="14" fill="%234F6576">Cyan marks the verifier, here an education provider or any other party that checks.</text></svg>)
How mature are they
The honest answer is: it depends on what you mean. Zero-knowledge techniques are well studied in research. Use in wallet credentials is still developing. Look at four dimensions of maturity.
Cryptographic maturity. Several zero-knowledge constructions are well analysed. Others are newer and have had less public scrutiny. A decision to rely on one needs review by qualified cryptographers.
Standardisation. Standards bodies work on signature schemes and proof formats that support unlinkable proofs and predicate proofs. Whether a particular scheme is final, widely implemented and accepted in the EUDI Wallet profiles is a matter to check against current texts. Do not assume it.
Implementation maturity. Libraries, wallets and verifier tooling need to support the scheme. Production-quality support, security audits and interoperability tests take time.
Operational maturity. Proof generation can cost computing power, which matters on a phone. Proof size and speed affect user experience. Status checks, key rotation and revocation need designs that fit with the proof scheme. Long-term validity is a concern: some schemes rely on assumptions that future computers could weaken, and an organisation that must keep proofs valid for many years should ask about this.
In the context of this course, the topic status is Emerging. The formats named for the EUDI Wallet are specified. Tooling and education profiles are still maturing. A cautious message for decision makers: plan for zero-knowledge proofs as a direction, use selective disclosure and careful issuing practice today, and avoid claims that a product delivers "full privacy" because it mentions zero knowledge.
Questions to ask when a vendor or a proposal mentions zero-knowledge proofs:
- Which statements can be proved, and which cannot?
- Which scheme is used, and where is it standardised?
- Has it been independently reviewed?
- What does it cost in time, battery and data size on a typical phone?
- What happens to a proof or credential if the underlying assumptions weaken?
- What does the verifier still see, and what can it store?
Worked example: The training provider considers age and eligibility proofs
A vocational training provider, led by operations manager Ms Rahman, runs courses with an age limit and with eligibility rules based on employment status. Learners show credentials from their wallets at enrolment.
Today the provider asks learners to show a date of birth and an employer confirmation. Ms Rahman's team would like to ask only for "age at least 18" and "currently employed in the sector".
The team looks at two routes:
- Route A: ask the issuers to add an "age over 18" claim and an "employed in sector" claim to the credentials. Selective disclosure then reveals only those. This works with salted hash formats and needs issuer cooperation.
- Route B: wait for wallets and verifiers that support zero-knowledge predicate proofs, then prove the statements from the underlying values.
The team chooses Route A for the next intake because it can be done with current tooling, and records Route B as a watch item. They list the six questions from this module and decide to ask them when a supplier proposes a proof-based solution. They also note that, in either route, the provider must decide how long to keep enrolment records and must say so to learners.
Practice activity: Question a zero-knowledge claim
Imagine a supplier states: "Our wallet uses zero-knowledge proofs, so verifiers learn nothing about holders." Write a short reply, no more than six sentences, that:
- Names what zero-knowledge proofs could add.
- Names at least two things the statement leaves open.
- Lists three of the six questions from this module that you would ask first.
Facilitator notes
Ask participants to read their replies aloud in pairs. The partner plays the supplier and answers briefly. This shows how easily a general promise hides open questions. Remind the group that the aim is informed questions and not rejection of the technique. If time allows, invite someone from the standards and wallet community (audience P3) to describe from experience which proof types are being discussed in their groups, without naming products. Time: 15 minutes.Check your understanding
A zero-knowledge proof convinces the verifier that a statement holds, such as "over 18", and reveals nothing beyond that fact.
Zero-knowledge techniques can support predicate proofs and fresh, unlinkable proofs from one credential. They do not control what verifiers do with the data and they do not remove the need for issuers.
Research on zero-knowledge proofs is advanced, but standards, tools and operational experience in wallet credentials are still developing. Decision makers should plan for the direction, rely on selective disclosure and careful issuing today, and verify current status.
Asking which scheme is used, where it is standardised and whether it has been independently reviewed addresses cryptographic and standardisation maturity, which are the foundation for any further decision.
Assessment and badge
This is the final knowledge check for the badge "Selective Disclosure and Privacy-Preserving Proofs (Knowledge, L4)", alignment code ICSF-SECP-L4-K.
Task: answer all 10 questions. Each question has four options and one correct answer. Read the explanation after each question, whether you answer correctly or not.
Evidence submitted for the badge: passed knowledge check.
Pass rule: 8 of 10 questions correct (80 per cent). You can retake the check. Passing shows that you understand the concepts in this course. It does not prove competency in a job.
Rubric
| Criterion | Questions | Evidence of understanding | Not yet |
|---|---|---|---|
| Explains selective disclosure techniques (Outcome 1) | 1 to 3 | Describes how salted hashes keep a signature valid, what the salt does and what the technique does not control | Treats selective disclosure as deletion of data or as control over what verifiers do later |
| Compares formats by privacy properties (Outcome 2) | 4 to 8 | Separates format from protocol, names what repeats across presentations, distinguishes linkability from anonymity and names measures that reduce linking | Treats all formats as equal or assumes a format alone guarantees privacy |
| Describes what zero-knowledge proofs add and how mature they are (Outcome 3) | 9 and 10 | Names predicate proofs and fresh unlinkable proofs, and gives a cautious statement of maturity | Treats zero-knowledge proofs as settled and complete, or as irrelevant |
Your certificate of completion
You passed the final check with %. Type your name as it should appear on the certificate. Your name stays on this device.
Certificate ID . Keep this ID: you need it to upgrade your certificate.
Need proof that others can check? ICoBC can upgrade your certificate to a signed Open Badges 3.0 credential after an identity check and a competence check, for €110 plus VAT.
Upgrade to a verifiable credentialBringing credentials to your organisation? ICoBC offers vendor-neutral consultancy.
Facilitator notes
**Delivery:** if the course runs inside a cohort, set a date for the knowledge check and offer a 30-minute question session beforehand. Collect unanswered questions from the module sticky notes and use them in this session. **After the check:** ask participants to name one change they will make in their own organisation. Avoid framing the badge as proof of job competency. It records that the person passed a knowledge check at ICSF stage K.Sources and further reading
Status as of November 2026; check before publishing.
The sources below are official texts, standards bodies and framework owners. Search for them by title on the owner's website, and check that you are reading the current version.
- Regulation (EU) 2024/1183 of the European Parliament and of the Council, amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework (known as eIDAS 2.0). Published in the Official Journal of the European Union. Available through EUR-Lex.
- The European Digital Identity Wallet Architecture and Reference Framework (ARF). Published by the European Commission and the eIDAS expert group. The framework changes between versions, so use the current one.
- Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation). Available through EUR-Lex. Read the principle of data minimisation and the rules on purpose limitation.
- ISO/IEC 18013-5, Personal identification, ISO-compliant driving licence, Part 5: Mobile driving licence (mDL) application. Published by the International Organization for Standardization. This is the source for the mdoc format and proximity presentation.
- SD-JWT and SD-JWT VC specifications. Developed in the Internet Engineering Task Force (IETF) OAuth working group. Check the current status of the documents on the IETF website.
- OpenID4VC specifications (OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations). Published by the OpenID Foundation. Check the current versions on the OpenID Foundation website.
- Verifiable Credentials Data Model and Data Integrity specifications. Published by the World Wide Web Consortium (W3C). Check which versions are current and which have reached Recommendation status.
- ICoBC Credentialing Skills Framework (ICSF). Published by the International Council on Badges and Credentials. Skill SECP "Security, privacy and data protection", level L4 "Assure", stage K "Knowledge".
- ICB-F06 Digital Identity and the EUDI Wallet: Essentials. The prerequisite course in the ICoBC Kursbibliothek.
Time-sensitive facts used in this course
- Member States must offer at least one wallet by 24 December 2026.
- Germany plans its state wallet ('d-you') for 2 January 2027, with basic functions first.
- Regulated private sectors must accept the wallet about one year after issuance starts.
- Readiness varies widely between Member States.
Status as of November 2026; check before publishing.