This page is generated from the same table our build gates on. Nobody types it, so it cannot fall behind the product — which is exactly how the previous version of this site became inaccurate without anyone deciding to exaggerate.
A profile is a format, a protocol, an issuer identity and a revocation mechanism that go together. We list one external counterpart per profile, by name and version, because a test in which our issuer and our wallet agree proves only that our code agrees with itself.
Proven against ACA-Py + acapy-plugins webvh (py3.12-1.4.0 / plugin 1.4.0), last green 2026-08-12.
SD-JWT VC issuance is not built (WP-D1) and mdoc is Phase 8, so nothing can be issued on this profile yet. It also requires a qualified signing certificate (WP-D0), which is a procurement task with weeks of lead time.
Everything on our side of this profile is built, and no foreign software has accepted a credential from it (WP-F1 and WP-D5, 2026-08-14). An Open Badges 3.0 AchievementCredential is issued, signed as a W3C VC 2.0 JWT under the tenant's did:web, validated against 1EdTech's own published JSON Schema, served at a URL a verifier can fetch, and revocable through a Bitstring Status List that the spec editors' own library reads correctly. What is missing is the acceptance gate itself: the counterpart below has never been handed one. Delivery over OpenID4VCI is separately blocked upstream — OpenID4VCI defines no format profile for W3C VC 2.0, proven in openid4vci-format-gap.test.ts rather than asserted — so hosted delivery, which Open Badges 3.0 also defines, is the route that exists.
The build fails if a profile is marked as supported without a green conformance run. That gate was verified by flipping one to supported and watching the build go red.