The OpenID Foundation has launched self-certification for OpenID4VP and OpenID4VCI conformance tests. Some teams will certify quickly, while others will face delays due to preventable errors.
The key isn't technical skill. It's understanding what conformance testing actually validates and where implementation gaps might exist.
Why These Mistakes Keep Happening
Many teams treat conformance testing like a last-minute exam. They build their implementation, run the tests once, fix any issues, and submit. This works only if your interpretation of the specification matches the test suite's exactly.
It rarely does.
The OpenID4VP and OpenID4VCI specifications outline protocols for presenting and issuing verifiable credentials. The High Assurance Interoperability Profile (HAIP) adds security and interoperability requirements. Together, they create opportunities for misalignment between your understanding of the spec and what conformant behavior actually requires.
The test suites include both positive tests (valid flows) and negative tests (rejecting invalid inputs). Most teams pass the positive tests easily. The negative tests reveal where you've been lenient with validation or made unsupported assumptions.
Mistake 1: Testing Against Other Implementations Instead of the Specification
Why it happens: Before these conformance tests, validating your OpenID4VP or OpenID4VCI implementation meant testing against another implementation. If your wallet presented credentials successfully, you assumed both implementations were correct.
The consequence: You've confirmed that two implementations share the same interpretation, not that either is correct. At the May 2025 OpenID4VP interoperability event, 90% of 153 pairwise tests passed. However, 10% failed between implementations believed to be working.
The fix: Run the conformance tests before pairwise testing with partners. The test suite represents the specification's requirements as interpreted by the Digital Credentials Protocols Working Group. It catches edge cases that informal testing might miss. Use pairwise testing for real-world integration concerns like network latency and error handling. Use conformance testing to ensure protocol correctness.
Mistake 2: Implementing Optional Features Without Testing Failure Modes
Why it happens: Teams implement optional features to differentiate their product or meet specific needs. They test that the feature works correctly but not what happens when it's used incorrectly.
The consequence: Your implementation might accept malformed requests or crash on unexpected inputs. The conformance tests include negative test cases to ensure optional features fail safely. If you didn't implement error handling for an optional feature, you'll fail certification.
The fix: For every optional feature, write test cases for three scenarios: correct use, incorrect use (malformed requests, missing parameters, invalid values), and no use. Your implementation should handle all three gracefully. If you can't test all scenarios, don't implement the feature.
Mistake 3: Hardcoding Test Data Into Your Implementation
Why it happens: During development, teams use fixed test credentials and static configurations for easier debugging. These shortcuts often end up in production.
The consequence: Your implementation passes tests with your specific data but fails with different valid inputs. This is common in credential format handling and cryptographic operations.
The fix: Audit your implementation for hardcoded assumptions. Replace fixed test data with dynamic handling based on the specification's requirements. For example, if the spec requires a valid JWT, your code should validate JWT structure and signatures, not check for a known test credential.
Mistake 4: Treating Certification as a One-Time Milestone
Why it happens: Teams see self-certification as a project deliverable. Pass the tests, pay the fee, get the logo, and move on. This works only if specifications and implementations never change.
The consequence: Specifications like OpenID4VP 1.0 and OpenID4VCI 1.0 are stable, but implementations evolve. Changes can introduce regressions that break conformance. If you only test once, you won't catch these until problems arise.
The fix: Integrate the conformance test suite into your continuous integration pipeline. Run tests on every significant code change. Track results over time. Treat new failures as blocking issues. Some teams at the July 2025 OpenID4VCI event maintained high pass rates by running tests continuously.
Mistake 5: Certifying the Wrong Role or Configuration
Why it happens: OpenID4VP certification covers two roles (wallet and verifier), and OpenID4VCI covers two roles (issuer and wallet). Some implementations perform multiple roles. Teams certify one role and assume it covers everything.
The consequence: You're certified as an OpenID4VCI issuer, but your wallet implementation hasn't been tested. Or you're certified for OpenID4VP presentation without the W3C Browser API appendix, but your deployment uses it. Certification doesn't match your deployment, causing integration issues.
The fix: Map your deployment architecture to certification roles. Certify each role separately if you operate as both an issuer and a wallet provider. If you support the W3C Browser API appendix for OpenID4VP, certify that configuration explicitly. Each role has distinct requirements. Budget for multiple certifications if needed.
Prevention Checklist
Before starting conformance testing:
- Run the test suite during development, not just before certification.
- Test all optional features for both success and failure cases.
- Remove hardcoded test data and ensure dynamic input handling.
- Identify which certification roles match your deployment (wallet, verifier, issuer).
- Set up continuous testing infrastructure for code changes.
- Document the specification version and profile you're certifying against.
- Review negative test cases to understand required input rejections.
- Verify error handling returns appropriate error codes.
Self-certification is open now. Teams that certify first will be recognized on the OpenID Foundation website. More importantly, they'll be trusted by partners and accepted by regulatory frameworks. The difference isn't talent. It's avoiding these mistakes before they become blockers.
