A Presentation Definition is the verifier’s request that describes which credentials, claims, and proof constraints a holder must satisfy. It controls what a wallet should present and how the response is matched. Security teams review it for overbroad requests, weak constraints, and policy gaps that could allow the wrong credential or an insufficient proof to be accepted.
What Presentation Definition Governs
A Presentation Definition is the verifier’s request structure for a verifiable presentation. It tells the holder which credentials, claims, and proof conditions to satisfy, so the verifier can match the response to a specific policy or transaction need.
Its security value comes from precision. If the definition is too broad, the verifier may accept a credential that is valid but insufficient for the purpose. If it is too narrow or ambiguous, users may disclose more than necessary or fail to present the right evidence on the first try.
How It Shapes Wallet and Verifier Behaviour
The Presentation Definition sits between policy intent and wallet output. It expresses which credential formats are acceptable, which claims matter, and which constraints must be met before a presentation is considered usable by the verifier.
That makes it a control surface, not just a data template. It influences what a wallet searches for, how it selects among available credentials, and how it packages the resulting proof for evaluation.
For teams working with OpenID for Verifiable Presentations and related credential flows, NHIMG’s Verifiable Credentials Guide is a useful reference for the surrounding model, including presentation flows and selective disclosure mechanisms.
Common Security and Interoperability Failure Modes
Most problems appear when the request is underspecified or over-permissive. A weak definition can allow the wrong credential type, an unintended issuer, or a presentation that technically matches the schema but does not satisfy the real trust requirement.
Interoperability also depends on how tightly the definition is written. Different wallet implementations may support different constraint expressions, so poorly formed requests can produce confusing failures, inconsistent selection, or silent fallbacks that weaken assurance.
In practice, teams should review how the request handles issuer trust, required claims, and disclosure minimisation. Those choices determine whether the verifier receives a meaningful assertion or only a syntactic match.
Why It Matters in Credential Assurance
A Presentation Definition matters because it is one of the few places where verification policy becomes machine-readable. If the policy is weak, the verifier may approve a presentation that meets the format but not the assurance goal; if it is too rigid, it can create unnecessary friction and disclosure.
That balance is especially important in privacy-sensitive systems, where the goal is to request only what is needed and no more. The definition should therefore express minimum necessary evidence while still being strict enough to reject incomplete or mismatched proofs.
Risk and Threat Considerations
Weak Presentation Definitions can create acceptance risk, privacy leakage, and policy bypass. The main danger is not a broken credential itself, but a verifier request that is broad enough to admit an unintended credential or too loose to enforce the intended proof constraints.
Failure mechanism: An attacker, misconfigured wallet, or sloppy integration can exploit ambiguous claim requirements, weak issuer constraints, or overly permissive matching logic to satisfy the request with the wrong credential or an insufficient proof.
Impact: The verifier may grant access, approve onboarding, or accept an assertion that does not actually meet the trust standard, while the holder may disclose more information than the transaction requires.
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-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Presentation Definition constrains what proof is accepted for access decisions. |
| V14 — Data Protection | The request can force excessive disclosure or support minimisation in credential presentation. | |
| Recommendation — Tighten acceptance rules so only presentations that satisfy the intended authorization policy are accepted. Specify only the minimum claims needed and reject requests that over-collect data. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The verifier should request only the minimum evidence needed for the decision. |
| IA-5 — Authenticator Management | Credential and proof acceptance depends on controlled handling of the asserting material. | |
| Recommendation — Limit requested claims and proof conditions to the minimum necessary for the transaction. Validate the credential and proof requirements before trusting the presentation. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Presentation requests sit within digital identity proofing and verifier assurance flows. |
| Recommendation — Align presentation requirements with the assurance level and verification needs of the transaction. | ||
Practitioner Guidance
Why practitioners should care: The Presentation Definition is where policy becomes enforceable, so errors here usually show up later as bad acceptance decisions rather than obvious parsing failures. Treat it as a security control surface, not a formatting detail.
What to watch for: Look for requests that accept too many credential types, lack meaningful constraints on claims or issuer trust, or depend on wallet behaviour that has not been tested across implementations. Those are the cases most likely to create silent assurance gaps.
Practitioner takeaway: The best Presentation Definitions are specific enough to enforce trust, but narrow enough to avoid unnecessary disclosure or brittle interoperability.