Verifiable credential wallets need conformance testing to prove they implement the required data formats, cryptographic checks, and protocol steps consistently. It catches failures in DID handling, presentation verification, selective disclosure, and issuer or verifier interoperability before production, where mismatched implementations can break authentication or acceptance of credentials.
What conformance testing proves for verifiable credential wallets
Conformance testing shows that a wallet does more than “support” verifiable credentials in theory. It confirms the wallet can parse the expected credential and presentation structures, execute the right cryptographic validation steps, and follow the protocol sequence that issuers and verifiers expect. That matters because wallet behaviour has to be deterministic enough to work across independent implementations.
A wallet can look functional in a single vendor demo and still fail in real usage if it handles DID resolution, proof verification, or presentation assembly differently from the ecosystem profile. Conformance testing reduces that gap by checking the wallet against the shared rules, not just against its own implementation assumptions. It is a compatibility test as much as a security test.
For wallet ecosystems built around selective disclosure, presentation exchange, and verifier checks, Verifiable Credentials Guide is the broader reference point for the credential and presentation model that conformance work is trying to validate.
Why interoperability failures show up as authentication problems
The practical reason to test conformance early is that a wallet does not fail in an abstract way, it fails at the point where a verifier decides whether to trust the credential or the presentation. If the wallet signs, packages, discloses, or routes data in a slightly different way from the profile, the result can be rejection even when the underlying credential is valid.
That is especially important where DID handling, issuer metadata lookup, status checks, and proof verification all need to line up. A mismatch in any one of those steps can break the trust chain and create a false negative, or worse, create acceptance behaviour that differs between verifiers. Conformance testing exposes those mismatches before they become production incidents.
Wallet teams that are working through selective disclosure mechanics should compare their implementation against SD-JWT and SD-JWT VC Guide, because that is where disclosure handling, key binding, issuer discovery, and verifier checks become operationally specific.
What conformance testing should cover before release
Good wallet conformance testing should cover more than one happy path. It should verify that the wallet handles required data formats, validates signatures and proofs consistently, processes issuer and verifier metadata correctly, and rejects malformed or incomplete inputs in the same way the profile expects.
- Credential parsing and schema handling, so the wallet interprets credential content consistently.
- Cryptographic checks, so signatures, bindings, and proofs are validated rather than assumed.
- Presentation generation and verification flow, so the wallet follows the right protocol steps end to end.
- Selective disclosure behaviour, so hidden and revealed claims are handled predictably.
- Interoperability cases across issuers and verifiers, so one implementation does not mask another’s edge-case behaviour.
For teams evaluating platforms or building against a profile, the most useful test plan is one that exercises both normal issuance and cross-vendor verification. Digital Identity, eID and Identity Wallets Guide and Verifiable Credentials Platform Buyer’s Guide both support that broader implementation view.
Risk and Threat Considerations
Without conformance testing, wallet failures often surface only when trust decisions are already live. That creates two distinct risks: valid credentials may be rejected because implementations diverge, and invalid or incomplete presentations may behave unpredictably across different verifiers. Both outcomes damage confidence in the wallet and in the ecosystem profile it is meant to follow.
Failure mechanism: A wallet implements the right standards in name but diverges in format handling, proof validation, or presentation sequencing, so interoperability breaks at the trust boundary and verification results become inconsistent.
Impact: Users lose the ability to present credentials reliably, issuers and verifiers absorb support and rollback cost, and any weakness in proof handling or disclosure logic can create acceptance failures or trust erosion across the ecosystem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, OWASP ASVS, NIST SP 800-63 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OpenID Connect | Wallets depend on interoperable credential and presentation flows. |
| Recommendation — Verify protocol handling, token checks, and cross-system auth steps before deployment. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Credential wallets rely on digital identity proofing and verifier trust rules. |
| Recommendation — Align wallet verification behaviour to digital identity assurance and federation expectations. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Conformance testing checks whether wallets enforce the access and proof rules expected by verifiers. |
| Recommendation — Test identity and authentication behaviour against the expected profile before production. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Wallet protocol failures can cause authentication and verification mismatches. |
| Recommendation — Validate wallet authentication steps so verification does not fail or drift across systems. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Wallets must perform cryptographic checks consistently to support trusted verification. |
| Recommendation — Confirm cryptographic verification behaviour is implemented and tested consistently. | ||
Practitioner Guidance
What to verify: Test against the exact profile your ecosystem uses, not a generic “VC compatible” claim. A wallet should prove that it can issue, store, present, and verify under the same rules that production verifiers will enforce.
Common mistake: Treating one successful demo as evidence of interoperability. One issuer and one verifier can hide format drift, weak DID handling, or edge-case failures that will appear as soon as the wallet meets another implementation.
What practitioners underestimate: Conformance testing is not just about correctness at release, it is also a regression control. Any change to DID resolution, proof libraries, disclosure logic, or presentation packaging should trigger revalidation before deployment.
Practitioner takeaway: The real value of wallet conformance testing is ecosystem trust, because the wallet only works when independent issuers and verifiers can validate the same credential the same way.
Related resources from NHI Mgmt Group
- How should scheme operators use conformance testing for verifiable credentials?
- Why do verifiable credential ecosystems need independent testing if the standard already exists?
- What breaks when verifiable credential conformance is left to self-certification?
- What is the difference between a verifiable credential and a trust registry?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org