You're building a digital identity system that needs to work across multiple sectors, integrate with government frameworks, and remain viable as standards evolve. The shift from prescriptive architectural mandates to principles-based design changes what "deployment ready" means.
This checklist helps you verify that your identity system can adapt to diverse requirements without needing a rebuild every time policies change. It's based on the approach outlined in the OpenID Foundation's Australian Digital Trust Community Group submission to Australia's Digital ID Act 2024 review, which prioritizes interoperability and economy-wide participation over rigid compliance with specific architectures.
Prerequisites
Before you start, confirm:
- You have authority to make architectural decisions affecting credential acceptance and issuance.
- Your team understands the difference between federation standards (OpenID Connect, OAuth 2.0) and credential formats (verifiable credentials, SAML assertions).
- You can identify which of your systems currently issue credentials users need to present elsewhere.
- You've mapped which external credentials your systems need to accept.
Checklist Items
1. Design Decisions Are Reversible Without Breaking Integrations
Done when: You can change your credential issuance format or authentication protocol without requiring downstream relying parties to redeploy.
Use protocol abstraction layers. If you're issuing credentials today via SAML and need to support OpenID for Verifiable Credential Issuance tomorrow, your decision to change shouldn't force 40 partner organizations to update their code.
Good looks like: A partner consuming your identity assertions can continue operating while you migrate from one standard to another, because you've built translation layers that maintain backward compatibility during transitions.
2. Success Metrics Measure Adoption, Not Just Accreditation
Done when: Your dashboard tracks how many users actually present credentials and how many organizations accept them, not just how many entities passed conformance testing.
Count real transactions. The OpenID Foundation's ADT CG submission emphasizes that success should be measured by public value and actual usage, not transaction counts or accreditation tallies.
Good looks like: You can answer "How many users chose our credential over alternatives this month?" and "Which credential types have acceptance rates below 60%?"
3. Credential Issuance Roadmap Prioritizes High-Reuse Cases
Done when: You've identified and scheduled issuance for credentials that users need to present across multiple sectors, not just within your organization.
Focus on supply side. If you're a government agency, prioritize credentials proving qualifications, licenses, permits, and delegated authority. These drive ecosystem productivity more than basic identity assertions.
Good looks like: Your Q1 roadmap includes issuing professional licenses as verifiable credentials because you've confirmed that 12 private-sector relying parties are ready to accept them.
4. Integration Barriers Are Documented and Quantified
Done when: You know exactly what an organization needs to do (technically, legally, operationally) to accept credentials you issue.
Map the friction points. If accepting your credential requires legal review, procurement approval, and custom integration work, you've created adoption barriers. Document them, then work to eliminate them.
Good looks like: A relying party can integrate your credential acceptance in under two weeks using standard OpenID Connect libraries, with clear documentation and test environments available.
5. Standards Alignment Is Verifiable Through Conformance Testing
Done when: Your implementation has passed conformance tests for the OpenID standards you claim to support.
Use existing certification. The OpenID Foundation provides conformance and certification services for OpenID for Verifiable Presentation, OpenID for Verifiable Credential Issuance, OpenID Connect, FAPI 2.0, OpenID Federation, and Shared Signals. These prove your deployment meets security, privacy, and interoperability requirements.
Good looks like: You can point to a certification badge or test report showing your implementation passed the relevant OpenID conformance suite.
6. Cross-Sector Interoperability Is Tested, Not Assumed
Done when: You've successfully exchanged credentials with organizations in at least two different sectors (government, private sector, education).
Test with real partners. Interoperability on paper doesn't equal interoperability in production. Run pilot exchanges with partners who have different technology stacks and different legal constraints.
Good looks like: A university credential you issue can be verified by a private employer and a government licensing board without custom integration work for each relying party.
7. International Standards Prevent Lock-In
Done when: Your architecture uses standards that work globally, not just within your jurisdiction.
Avoid proprietary dependencies. If your system relies on country-specific protocols that have no international equivalent, you've created a future migration problem.
Good looks like: A credential issued by your system could theoretically be verified by a relying party in another country using standard OpenID for Verifiable Presentation, even if legal frameworks currently prevent that use case.
Common Mistakes
Optimizing for edge cases over volume. Focusing government effort on low-frequency, high-security scenarios (diplomat credentials, witness protection) creates systems that don't serve the majority. Design for high-volume, high-value use cases first.
Measuring accreditation instead of adoption. Getting 50 organizations through your accreditation process means nothing if only three of them actually accept credentials in production.
Building before confirming demand. Issuing credentials that no relying party is ready to accept wastes resources. Coordinate supply and demand.
Treating interoperability as a Phase 2 feature. Retrofitting standards compliance is expensive. Build with OpenID standards from day one.
Next Steps
After completing this checklist, you should have:
- A credential issuance roadmap prioritizing high-reuse cases.
- Documented integration requirements for relying parties.
- Conformance test results for your standards implementation.
- Cross-sector pilot results proving real interoperability.
If you can't check off items 1, 5, and 6, you're not ready for production deployment. Your system might work within your organization, but it won't drive ecosystem-wide adoption.
The full OpenID Foundation ADT CG submission to Australia's Digital ID Act review is available at openid.net. It provides additional context on the four-pillar framework (commonwealth government, state and territory governments, private sector, international interoperability) and how these pillars need to operate together for long-term success.
