Credential class matters because QEAA, EAA and public attestations carry different assurance levels, legal effects and dispute burdens. If teams collapse them into one policy bucket, they can make onboarding and compliance decisions that do not match the real evidentiary strength of the credential.
When wallet credentials are treated as interchangeable
The failure starts at the trust decision. QEAA, EAA and public attestations do not all answer the same question, so a relying party that collapses them into one bucket loses the ability to distinguish strong proof from weaker or differently scoped evidence. That usually shows up first as bad policy design: the system accepts too little assurance for a high-stakes action, or demands too much for a low-risk one.
Assurance class also shapes the downstream legal and operational posture. A wallet presentation may be technically valid yet still carry a different evidentiary burden, dispute path, or liability profile depending on how it was issued and what it is meant to prove. Treating every credential as equivalent turns a trust policy into a generic allow list, which is rarely defensible when onboarding, regulated workflows, or high-impact approvals are involved.
For teams building around digital identity wallets, the relevant distinction is not just whether a credential exists, but what assurance, provenance and verifier expectations attach to it. The wallet can present multiple credential types, and the relying party must preserve those differences in policy rather than flatten them into one acceptance rule. See the broader wallet model in Digital Identity, eID and Identity Wallets Guide, which explains how wallet-based presentations fit into identity verification and trust frameworks.
Why the wrong equivalence breaks onboarding and compliance
Onboarding fails when the verifier uses the same acceptance rule for credentials that were issued for different purposes. A public attestation can be useful as a signal, but it is not the same as a credential with stronger assurance and legal backing. If the relying party cannot express that difference, it either rejects acceptable users unnecessarily or accepts users whose proof is insufficient for the decision being made.
Compliance problems follow the same pattern. The decision maker may believe it has satisfied a verification requirement, but later discover that the credential used does not support the required evidentiary standard. That creates avoidable rework, audit friction, and possible challenge over whether the relying party relied on the right class of credential. For practical identity wallet design, the verifier should preserve credential class in policy and in records, not just in the user interface.
The distinction is especially important when a workflow mixes low-friction access with regulated or high-impact actions. The credential class that is acceptable for proof of attribute or basic onboarding may not be acceptable for signing, eligibility, or other decisions where the relying party needs a stronger assurance basis. In those cases, the policy must evaluate class, not just wallet possession.
Wallet architectures also tend to create a false sense of uniformity because the presentation looks similar even when the trust semantics differ. The operational test is simple: if two credentials would lead to different dispute handling, different legal reliance, or different onboarding consequences, they are not equivalent for policy purposes.
How relying parties should separate trust rules by credential class
A relying party needs a policy model that distinguishes credential class before it evaluates access, approval, or acceptance. That means mapping QEAA, EAA and public attestations to separate rules, then tying each rule to a specific business use case and evidentiary threshold. The goal is not to make policy more complicated for its own sake, but to prevent a single generic rule from silently widening trust.
That separation should extend into verification logic, recordkeeping, and exception handling. If the system accepts a lower-assurance presentation in a high-assurance path, it should do so deliberately, with an explicit exception and a clear reason. If the relying party needs stronger evidence, the response should be to require the stronger class of credential, not to reinterpret a weaker one as equivalent.
For implementation teams, the safest pattern is to make credential class visible to the policy engine and to the human reviewer. The identity wallet may present multiple forms of evidence, but the verifier should still know what it is relying on. The eIDAS 2.0 EU Digital Identity Framework is the clearest reference point for treating wallet-based trust as a structured assurance problem rather than a generic token check.
Risk and Threat Considerations
When assurance classes are collapsed, the main risk is trust inflation: a weaker credential is allowed to stand in for a stronger one. That can produce unauthorized onboarding, weakly supported compliance decisions, and later disputes about whether the relying party had enough evidence to rely on the credential.
Failure mechanism: The policy engine or reviewer ignores the difference between credential classes, so a presentation is accepted because it is wallet-based rather than because it satisfies the required assurance level and evidentiary standard.
Impact: The relying party may grant access, approve onboarding, or satisfy an audit step on the basis of insufficient proof, which increases legal exposure, operational rework, and the chance of accepting the wrong person or attribute claim.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Wallet credential assurance and verifier trust levels are identity assurance questions. |
| Recommendation — Apply the appropriate assurance and verification requirements to each credential class before accepting it. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Policy must distinguish which credential class is sufficient for each trust decision. |
| Recommendation — Define separate acceptance rules for each credential class and decision type. | ||
| EU AI Act | European Digital Identity Framework | Wallet-based trust and credential use are governed by the EU digital identity framework. |
| Recommendation — Align wallet acceptance rules to the assurance model required by the framework. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | External relying-party decisions depend on the authenticity and assurance of presented credentials. |
| Recommendation — Require the credential class that matches the trust level of the transaction. | ||
Practitioner Guidance
What to verify: Confirm that the trust policy records credential class separately from wallet possession and that each high-impact workflow names the minimum acceptable class. If a decision would change under dispute, the policy should be explicit enough to explain why that class was sufficient.
Decision rule: If the action depends on evidence quality, use the strongest acceptable credential class for that action and treat lower-class presentations as insufficient unless the business owner has formally accepted the downgrade. Do not let user convenience quietly redefine the assurance requirement.
Practitioner takeaway: The critical control is not “accept wallet credentials”, it is “accept the right credential class for the right decision”, because equivalence errors turn trust frameworks into guesswork.
Related resources from NHI Mgmt Group
- What breaks when an organisation cannot recognise EUDI Wallet credentials at the relying party?
- How do organisations reduce the dwell time of exposed credentials at scale?
- How should organisations stop auto-sync from turning desktops into repositories of credentials?
- What breaks when third-party credentials are published in source code?