VC 2.0 — conformance status
Generated by bun run conformance:render — do not edit by hand.
Denominator: pinned Coverage Map docs/conformance/maps/vc-data-model-v2.0.json (generated 2026-06-22). See conform-ed ADR-0013 (map) and emergent ADR-0028 (overlay).
Certification readiness (by profile)
Section titled “Certification readiness (by profile)”| Profile | Requirements | Done | Partial | Other | Progress |
|---|---|---|---|---|---|
| credential | 4 | 2 | 0 | 2 | ████████░░░░░░░░ 50% |
| presentation | 1 | 1 | 0 | 0 | ████████████████ 100% |
Conformance requirements
Section titled “Conformance requirements”credential
Section titled “credential”| Req | Level | Status | Evidence | Statement |
|---|---|---|---|---|
| VC-1 | MUST | ✅ done | vc:2.0:conf:credential/VC-1 |
A verifiable credential MUST have a @context whose first value is https://www.w3.org/ns/credentials/v2, a type that includes VerifiableCredential, an issuer, a validFrom, and a credentialSubject. |
| VC-2 | MUST | ✅ done | vc:2.0:conf:credential/VC-2 |
An id, when present, MUST be a single URL; validUntil, when present, MUST be an XMLSchema dateTime; a credentialSubject identifies the subject via an optional id. |
| VC-3 | MUST | ➖ not-applicable | — | Each credentialSchema, credentialStatus, refreshService, termsOfUse and evidence entry MUST carry a type (and an id where the property requires one). |
| VC-4 | MUST | ➖ not-applicable | — | A credential secured with an embedded proof MUST carry a proof with a type (the Data Integrity / Data Model securing mechanism). |
presentation
Section titled “presentation”| Req | Level | Status | Evidence | Statement |
|---|---|---|---|---|
| VP-1 | MUST | ✅ done | vc:2.0:conf:presentation/VP-1 |
A verifiable presentation MUST have a @context whose first value is https://www.w3.org/ns/credentials/v2 and a type that includes VerifiablePresentation; it MAY declare a holder and enclose verifiableCredential(s). |
Information-model coverage (vs conform-ed model)
Section titled “Information-model coverage (vs conform-ed model)”- 68 literal items — 53 modelled ✅, 0 partial 🟡, 0 gaps ❌
- Silent gaps (in spec, not modelled): none
- conform-ed extensions (modelled, not in spec): none
Gotchas & notes
Section titled “Gotchas & notes”vc:2.0:conf:credential/VC-1- Both the OB 3.0 AchievementCredential and the CLR 2.0 ClrCredential emergent assembles carry a @context whose first value is https://www.w3.org/ns/credentials/v2, a type that includes VerifiableCredential, an issuer (the per-org Profile), a validFrom, and a credentialSubject — validated against conform-ed’s base VerifiableCredentialSchema in the offline conformance test.
vc:2.0:conf:credential/VC-2- The credential id is a single urn:uuid URL (deterministicCredentialId / deterministicClrId), validUntil — when emitted — is an XMLSchema dateTime, and credentialSubject identifies the subject by id. The base schema accepts the emitted credential on all three.
vc:2.0:conf:presentation/VP-1- With Capability B (ADR-0038) emergent is a credential HOLDER: a learner mints a holder-signed Verifiable Presentation enclosing a curated selection of their held credentials. The assembled envelope carries a @context whose first value is https://www.w3.org/ns/credentials/v2, a type that includes VerifiablePresentation, the holder URI, and the enclosed verifiableCredential(s) — each in its own securing form (verbatim VC-JOSE compact JWS, or embedded-proof JSON-LD). The offline conformance test validates the real assembleVerifiablePresentation output against conform-ed’s VerifiablePresentationSchema. (The envelope itself is secured by an enveloping VC-JOSE holder signature, like the issuer path — not an embedded proof.)