Skip to content
emergent engineering

CLR 2.0 — conformance status

Generated by bun run conformance:render — do not edit by hand.

Denominator: pinned Coverage Map docs/conformance/maps/clr-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
displayer 5 5 0 0 ████████████████ 100%
host 2 2 0 0 ████████████████ 100%
issuer 7 7 0 0 ████████████████ 100%

Conformance requirements

Section titled “Conformance requirements”

displayer

Section titled “displayer”
Req Level Status Evidence Statement
CLR-DSP-1 MUST ✅ done clr:2.0:conf:displayer/CLR-DSP-1 A displayer MUST verify a presented ClrCredential and correctly determine its state — valid, expired or revoked — before display, and MUST allow a viewer to trigger verification and retrieve the result.
CLR-DSP-2 MUST ✅ done clr:2.0:conf:displayer/CLR-DSP-2 A displayer MUST present the record’s name, description, issuer name, issue date (validFrom), verification status, and the image when present.
CLR-DSP-3 MUST ✅ done clr:2.0:conf:displayer/CLR-DSP-3 A ClrCredential MUST be treated as expired when the current date-time is after its validUntil.
CLR-DSP-4 MUST ✅ done clr:2.0:conf:displayer/CLR-DSP-4 A ClrCredential MUST be treated as revoked when credentialStatus is present with type ‘1EdTechRevocationList’; credentialStatus.id MUST be the URL of the issuer’s credential status method.
CLR-DSP-5 MUST ✅ done clr:2.0:conf:displayer/CLR-DSP-5 A displayer MUST support the Data Integrity proof cryptosuites and MUST verify credentials expressed against the W3C VC Data Model 2.0 context.

host

Section titled “host”
Req Level Status Evidence Statement
CLR-HST-1 MUST ✅ done clr:2.0:conf:host/CLR-HST-1 The getCredentials response MUST return ClrCredentials, each independently verifiable; VC-JWT-signed credentials MUST be carried in compactJwsString. A host MUST import and re-export a ClrCredential with no data loss.
CLR-HST-2 MUST ✅ done clr:2.0:conf:host/CLR-HST-2 A CLR API service error/status response MUST be reported through the imsx_statusInfo structure, carrying at least an imsx_codeMajor and imsx_severity.

issuer

Section titled “issuer”
Req Level Status Evidence Statement
CLR-ISS-1 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-1 The @context MUST begin with the VC 2.0 context URI (https://www.w3.org/ns/credentials/v2) followed by the CLR 2.0 context URI.
CLR-ISS-2 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-2 The type MUST be an unordered set containing ‘VerifiableCredential’ and ‘ClrCredential’.
CLR-ISS-3 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-3 credentialSubject MUST be a ClrSubject that carries the learner’s achievements and the verifiable AchievementCredentials.
CLR-ISS-4 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-4 The issuer MUST be a Profile identified by an IRI in the issuer.id property.
CLR-ISS-5 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-5 An issued ClrCredential MUST be signed with a supported proof mechanism — a Data Integrity proof (eddsa-rdfc-2022 or ecdsa-sd-2023) or an external VC-JWT proof — and an embedded proof’s proofPurpose MUST be ‘assertionMethod’.
CLR-ISS-6 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-6 The issued ClrCredential MUST contain all required fields (id, @context, issuer, validFrom, credentialSubject) and be valid: it MUST pass JSON-LD validation in safe mode.
CLR-ISS-7 MUST ✅ done clr:2.0:conf:issuer/CLR-ISS-7 The ClrSubject MUST aggregate the learner’s record as a set of verifiable credentials (verifiableCredential), each itself a VerifiableCredential, alongside the achievements they evidence.

Information-model coverage (vs conform-ed model)

Section titled “Information-model coverage (vs conform-ed model)”
  • 409 literal items — 299 modelled ✅, 39 partial 🟡, 0 gaps ❌
  • Silent gaps (in spec, not modelled): none
  • conform-ed extensions (modelled, not in spec): none

Gotchas & notes

Section titled “Gotchas & notes”
  • clr:2.0:conf:displayer/CLR-DSP-1
    • emergent verifies a third-party ClrCredential through the same conform-ed engine + host resolvers as Open Badges. Proven offline by driving the real verifyCredentialDocument service against a signed CLR + in-memory JWKS.
  • clr:2.0:conf:displayer/CLR-DSP-2
    • The admin-console displayer renders the verdict, its axes, and the verified record’s fields (name, issuer, type, validity dates) via summarizeCredential — the same panel that renders Open Badges. Proven offline by the field-extraction test; the panel is covered by a render test.
  • clr:2.0:conf:displayer/CLR-DSP-3
    • The verifier determines the validity-window state of a CLR (valid / expired / not-yet-valid). Proven offline against an authentic but expired ClrCredential.
  • clr:2.0:conf:displayer/CLR-DSP-4
    • The verifier evaluates a CLR’s credentialStatus against its BitstringStatusList (active / revoked / suspended), fail-safe on an uncheckable status. Proven offline against a revoked CLR.
  • clr:2.0:conf:displayer/CLR-DSP-5
    • The verifier supports both securing mechanisms — VC-JOSE and embedded eddsa-rdfc-2022 Data Integrity — for a ClrCredential, the same engine proven for Open Badges. Proven offline.
  • clr:2.0:conf:host/CLR-HST-1
    • emergent now operates a CLR API host (capability-b; ADR-0038), sharing the OAuth2 authorization server with the Open Badges host. The getCredentials aggregation endpoint (GET /ims/clr/v2p0/credentials, scope-gated on the CLR credential.readonly) returns the learner’s owned, currently-valid ClrCredentials as the getClrCredentialsResponse envelope (compactJwsString for VC-JOSE, credential for embedded-proof). Proven offline: the shared assembler validates against conform-ed’s GetClrCredentialsResponseSchema.
  • clr:2.0:conf:host/CLR-HST-2
    • The CLR host returns the imsx_statusInfo service-error envelope on any getCredentials failure (bad token, insufficient scope, unconfigured host), shared with the Open Badges host. Proven offline against conform-ed’s ImsxStatusInfoSchema.
  • clr:2.0:conf:issuer/CLR-ISS-1
    • @context ordering (VC 2.0, then CLR 2.0, then OB 3.0) is enforced by the export assembler and asserted in the conformance lane against the official 1EdTech CLR JSON Schema.
  • clr:2.0:conf:issuer/CLR-ISS-2
    • type is the unordered set { VerifiableCredential, ClrCredential }, asserted in the lane.
  • clr:2.0:conf:issuer/CLR-ISS-3
    • credentialSubject is a ClrSubject carrying the learner identifier and the inner AchievementCredentials, each keeping its own per-org issuer; asserted in the lane. Each inner AchievementCredential now carries the canonical Achievement.image + its issuer Profile.image (ADR-0035) — the same always-resolving /img URLs the standalone OB export emits — so a CLR verifier renders badge art. Each inner issuer Profile is also spec-complete with the authored descriptive fields + derived parentOrg (ADR-0036). The platform-level CLR envelope issuer (null-org) stays deliberately minimal (name only) — the rich per-org Profiles ride on the inner achievements.
  • clr:2.0:conf:issuer/CLR-ISS-4
    • ⚠️ The transcript issuer is the platform-default (null-org) Profile + signer; inner achievements keep their own org issuers. Proofs are VC-JOSE (compact JWS, EdDSA/Ed25519), verified externally via the published JWKS — not embedded data-integrity proofs.
  • clr:2.0:conf:issuer/CLR-ISS-5
    • The ClrCredential is signed via the VC-JWT path (compact JWS, EdDSA/Ed25519) behind the KeySigner seam and is JWKS-verifiable; the lane asserts the signature verifies.
  • clr:2.0:conf:issuer/CLR-ISS-6
    • The exported ClrCredential carries all required fields and validates against the official 1EdTech CLR 2.0 schema.
  • clr:2.0:conf:issuer/CLR-ISS-7
    • The ClrSubject aggregates the learner’s inner AchievementCredentials in verifiableCredential; the lane asserts two inner credentials with their deterministic ids.