Your organization is deploying a digital wallet or credential issuance system. Your counterparty's implementation claims to support OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) with the High Assurance Interoperability Profile (HAIP). How do you know their implementation actually works? How do they know yours does?
Until August, you couldn't. You'd spin up test environments, attempt integration, and when connections failed, you'd spend days debugging to figure out which side broke the spec. The OpenID Foundation's conformance tests changed that equation. Fourteen organizations have already self-certified their implementations, putting their test results on public record. If you're building wallets, issuing credentials, or accepting verifiable presentations, you need to join them.
The Problem: Integration Shouldn't Be Detective Work
Before conformance tests existed, implementers could only test against each other. When two systems failed to connect, neither party knew who was at fault. You'd check your OAuth 2.0 flows, verify your JSON Web Token (JWT) signatures, review your OpenID4VP presentation definitions, and still end up in multi-party troubleshooting calls.
The real damage wasn't the debugging time. It was the security and interoperability gaps that emerged when implementations passed happy-path tests but failed edge cases. An implementation might correctly handle valid credential presentations but fail to reject malformed ones. It might work with one wallet provider but break with another. These gaps matter when governments in Europe, the UK, Switzerland, India, and California are selecting OpenID4VP and OpenID4VCI for their digital identity programs.
What You Need Before Starting
Before you run conformance tests, verify you have:
A complete implementation of either:
- OpenID4VP with HAIP (for verifiers accepting presentations)
- OpenID4VCI with HAIP (for issuers providing credentials)
Test infrastructure that can:
- Expose your implementation to the OpenID Foundation's test servers, or
- Run the conformance test suite on your own infrastructure
Documentation of your configuration, including:
- Your authorization endpoint URLs
- Your token endpoint configurations
- Your supported credential formats (SD-JWT VC, ISO mDL, W3C VC)
- Your cryptographic key management approach
Internal stakeholder alignment on publishing results. Self-certification puts your test outcomes on public record. Your engineering, legal, and product teams should understand what that means for partner expectations.
Step-by-Step Implementation
1. Access the Conformance Test Suite
Navigate to the OpenID Foundation's certification portal. You'll find separate test suites for OpenID4VP and OpenID4VCI with HAIP. Create an account if you haven't already.
The tests are free to run. You can execute them against the Foundation's hosted servers or deploy the test suite in your own environment if your security requirements prohibit external exposure.
2. Configure Your Test Plan
Select the profile you're certifying against. For HAIP implementations, choose:
- OpenID4VP with HAIP if you're building a verifier
- OpenID4VCI with HAIP if you're building an issuer
Provide your implementation's configuration:
Authorization endpoint: https://your-[domain](/glossary/domain).com/authorize
Token endpoint: https://your-domain.com/token
Supported credential formats: ["vc+sd-jwt", "mso_mdoc"]
3. Run the Conformance Tests
The test suite will execute both positive and negative test cases. Positive tests verify your implementation handles valid flows correctly. Negative tests verify you reject invalid inputs.
Pay attention to the negative tests. They check whether your implementation properly rejects:
- Malformed presentation requests
- Invalid cryptographic proofs
- Expired credentials
- Tampered credential data
- Missing required claims
These rejection scenarios are where security vulnerabilities typically hide. An implementation that accepts everything will pass positive tests but fail in production when attackers send crafted inputs.
4. Review and Fix Failures
When tests fail, the suite provides detailed logs. You'll see:
- Which specification requirement failed
- The exact request/response that triggered the failure
- Expected vs. actual behavior
Common failure points include:
- Incorrect JWT signature validation
- Missing Proof Key for Code Exchange (PKCE) enforcement
- Improper handling of presentation definition matching
- Incorrect credential format validation
Fix each failure, then re-run the affected test cases. The tests are deterministic; same input produces same output, so you can iterate quickly.
5. Submit for Certification
Once all tests pass, export your test results. The conformance suite generates a certification package containing:
- Complete test logs
- Your implementation's configuration
- Timestamp and version information
Submit this package to [email protected] along with the certification fee. The OpenID Foundation will review your submission and publish your results to the public certification registry.
Validation: How to Verify It Works
After certification, verify your implementation's listing appears in the public registries:
- OpenID4VP certifications: Check the Foundation's OpenID4VP certification page
- OpenID4VCI certifications: Check the Foundation's OpenID4VCI certification page
Your entry should display:
- Your organization name
- Implementation name and version
- Certification date
- Link to detailed test results
Test integration with another certified implementation. The shared conformance baseline means you should achieve interoperability without custom debugging. If you encounter issues, both parties can reference their certification results to isolate the problem.
Maintenance: Ongoing Tasks
Re-certify after major updates. If you modify your authorization flows, credential format handling, or cryptographic operations, re-run the conformance tests. Your certification applies to a specific implementation version.
Monitor specification updates. The OpenID Foundation updates HAIP and the underlying OpenID4VP/OpenID4VCI specifications. When new versions release, plan recertification within your normal release cycle.
Track counterparty certifications. When onboarding new wallet providers, credential issuers, or relying parties, check their certification status first. If they're certified, integration should be straightforward. If they're not, expect additional integration testing.
Use certification in procurement. When evaluating vendors for digital identity components, require OpenID4VP and OpenID4VCI certification with HAIP. This shifts conformance verification from your team to the vendor and creates a competitive incentive for vendors to maintain compliance.
Self-certification doesn't eliminate all integration work, but it eliminates the most time-consuming part: proving both parties correctly implement the specification. When governments and enterprises deploy digital identity at scale, that shared baseline is what makes interoperability possible.
