Different services need different proof thresholds. A restaurant only needs age verification, while a prescription workflow may need stronger identity proofing, address validation, and issuance confidence. Flexible assurance lets organisations request only the attributes needed for the transaction, reducing privacy exposure while still meeting risk, compliance, and trust requirements.
Why Flexible Assurance Matters When One Wallet Serves Many Services
A single wallet may be used to prove very different things: age at a venue, eligibility for a benefit, or identity for a high-risk regulated workflow. Fixed assurance turns every request into the same transaction, which creates unnecessary friction at low risk and insufficient trust at high risk. Current guidance suggests identity assurance should match the sensitivity of the action, not the existence of the wallet itself, as reflected in NIST SP 800-63 Digital Identity Guidelines.
This is why flexible assurance matters in practice. It lets a verifier ask only for the attributes and proof strength needed for that moment, which reduces data sharing, lowers privacy exposure, and supports risk-based access decisions. That same principle aligns with the governance concerns highlighted in Ultimate Guide to NHIs, where over-privilege and poor visibility are recurring identity failures. In practice, many security teams discover that a wallet is overtrusted only after a downstream service accepts more identity assurance than the transaction actually required.
How Assurance Levels Are Applied in Real Transactions
Flexible assurance works by separating the wallet from the proof required by the relying service. The wallet can hold multiple credentials or claims, while the service requests a specific level of identity assurance based on policy, transaction risk, and regulatory need. A low-risk service may request only a minimal proof, while a high-risk service may require stronger identity proofing, device binding, or re-verification at presentation time.
Practically, this usually involves policy-driven disclosure and verification. The verifier defines the assurance threshold, the wallet presents only the necessary attributes, and the trust decision is evaluated at runtime. That is consistent with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasizes tailoring controls to system risk. It also supports the direction of travel in eIDAS 2.0, where wallet-based identity is meant to be reusable without becoming indiscriminate.
- Low-risk access: request only the attribute needed, such as age over a threshold.
- Moderate-risk access: request verified attributes plus contextual checks, such as residence or membership.
- High-risk access: require stronger proofing, recent issuance confidence, and tighter presentation controls.
This approach is especially valuable when wallets are reused across sectors, because the verifier should not inherit trust from the wallet alone. It should inherit only the assurance level needed for the specific transaction, and nothing more. These controls tend to break down when one verifier tries to reuse a low-assurance proof for a regulated workflow because the wallet presentation layer cannot compensate for weak initial proofing.
Common Variations, Tradeoffs, and Failure Modes
Tighter assurance often increases user friction and operational cost, requiring organisations to balance convenience against fraud resistance and compliance obligations. That tradeoff is real, and current guidance suggests there is no universal standard for every service class yet. The right level depends on the value of the action, the sensitivity of the attributes, and the consequences of a false acceptance.
One common edge case is progressive assurance, where a wallet starts with minimal disclosure and steps up only when the service risk increases. Another is cross-border use, where different legal regimes may define proofing and attribute validation differently. A third is delegated use, where a wallet represents someone else or supports a family, employee, or proxy relationship; in those cases, the verifier must distinguish holder assurance from subject assurance.
Practitioners should also watch for ecosystem gaps. Some services over-rely on possession of the wallet, while others over-collect personal data because they cannot express a finer-grained policy. The most effective implementations align policy, disclosure, and auditability so that each service gets the assurance it needs and no more. For background on the identity failure patterns this helps prevent, compare the breach patterns in 52 NHI Breaches Analysis and the recurring control gaps in Top 10 NHI Issues.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Defines identity assurance levels and transaction-specific proofing expectations. | |
| NIST CSF 2.0 | PR.AA | Supports attribute-based access and identity verification proportional to risk. |
| NIST AI RMF | GOV | Governance is needed to decide what assurance level each service may request. |
| NIST Zero Trust (SP 800-207) | PA | Zero trust requires continuous, context-aware trust decisions instead of static wallet trust. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Overtrusted identities and excessive privilege mirror wallet over-assertion risks. |
Match wallet proof strength to the transaction's required assurance level, not the wallet's existence.
