A Presentation Definition tells a wallet which credentials or claims a verifier wants to receive. It expresses the required format, fields and constraints, and the wallet uses it to select suitable credentials for presentation. Security teams should check that the definition asks only for necessary data, since overbroad requests expand disclosure and privacy risk.
What Presentation Definition actually does in a credential exchange
presentation definition is the verifier’s request language in a verifiable credential flow. It tells a wallet what kind of presentation is being requested, which claim sets or formats are acceptable, and which constraints must be satisfied before a credential is selected. The practical effect is that the verifier can ask for a precise presentation without naming every credential by hand.
That precision matters because the definition is not just a filter, it is also a privacy boundary. If the request is narrowly written, the wallet can satisfy the verifier with the smallest necessary set of credentials or claims. If it is broad, the same flow can disclose more personal data than the verification task actually needs.
A good way to think about it is that the definition sets the rules for selection, while the wallet performs the selection. In many implementations, the wallet evaluates which stored credentials match the requested structure, subject, field constraints, and optional presentation requirements, then returns one or more credentials that fit. The verifier receives a presentation that should satisfy the stated request without exposing unrelated data.
Why the structure and constraints matter
The value of Presentation Definition is that it makes selective disclosure operational rather than aspirational. It can express what the verifier needs in terms of schema, field paths, predicates, and other constraints so the wallet can assemble the smallest compliant response. That is especially important when a single wallet holds many credentials from different issuers or for different use cases.
This is also where mistakes tend to show up. A definition that is too permissive can accept weak or irrelevant credentials, while one that is too rigid can cause unnecessary verification failures even when the wallet holds a suitable credential. The design problem is to ask for enough structure to verify the requirement, but no more than that.
For readers working with verifiable credential flows, the Verifiable Credentials Guide is the most useful broader reference because it places presentation definitions alongside the surrounding VC concepts, including holder-verifier interaction and selective disclosure patterns.
How to evaluate a Presentation Definition for privacy and interoperability
A practical evaluation starts with the verifier’s purpose. If the presentation is being used to prove one attribute, one status condition, or one eligibility check, the definition should request only the minimum claims required for that check. Security and privacy review should focus on whether the request is proportional to the decision being made.
Interoperability also depends on whether the definition matches the wallet and credential formats you actually support. A definition can be syntactically valid and still fail in practice if it assumes claim shapes, credential types, or presentation formats that the wallet ecosystem does not handle consistently. In other words, the request has to be both precise and implementable.
On the control side, organisations should review the definition as they would any data request. A verifier that routinely asks for full credential contents, broad profile data, or multiple unrelated attributes is creating avoidable disclosure risk even if the exchange is technically secure. The issue is not only whether the credential can be verified, but whether the request is justified.
Risk and Threat Considerations
Overbroad Presentation Definitions increase disclosure surface, create unnecessary correlation opportunities, and can push wallets to reveal more identity data than the verification use case needs. The same pattern can also weaken user trust if request scope is not clearly bounded.
Failure mechanism: A verifier defines a request that is broader than the business decision requires, so the wallet returns more claims, more identifiers, or more linkable data than necessary.
Impact: Excess disclosure can expose sensitive attributes, enlarge privacy risk, and make repeated presentations easier to correlate across services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Presentation Definition supports selective credential presentation in identity flows. |
| Recommendation — Constrain requested claims to the minimum needed for the verification outcome. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The subject is a digital identity presentation request that affects assurance and disclosure. |
| Recommendation — Align presentation requests with the assurance level and data minimisation needed for the transaction. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Requested claims determine how sensitive the disclosed information is and how it should be handled. |
| Recommendation — Classify requested attributes before allowing them into a presentation flow. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | The flow concerns controlled disclosure of credential data to a verifier. |
| Recommendation — Limit disclosed data to the minimum necessary for the transaction. | ||
Practitioner Guidance
What to verify: Check that every requested field maps to a concrete decision the verifier must make. If a claim does not change the outcome, remove it from the definition or make it optional only when the wallet flow still works correctly.
What good looks like: A well-formed definition asks for the minimum set of credentials or claims, supports the intended wallet population, and avoids requesting full credential payloads when a narrower proof is enough.
Decision rule: If the same verification outcome can be achieved with a narrower request, prefer the narrower definition and treat any broader request as a privacy exception that needs explicit justification.
Practitioner takeaway: Presentation Definition should be treated as a privacy-sensitive request policy, not just a technical filter, because its wording directly determines how much data the wallet may disclose.