Skip to content
emergent engineering

OB 3.0 — conformance status

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

Denominator: pinned Coverage Map docs/conformance/maps/open-badges-v3.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 9 9 0 0 ████████████████ 100%

Conformance requirements

Section titled “Conformance requirements”

displayer

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

host

Section titled “host”
Req Level Status Evidence Statement
OB-HST-1 MUST ✅ done ob:3.0:conf:host/OB-HST-1 The getCredentials response MUST return OpenBadgeCredentials, each independently verifiable; credentials signed with the VC-JWT proof format MUST be carried in the compactJwsString list.
OB-HST-2 MUST ✅ done ob:3.0:conf:host/OB-HST-2 A Badge Connect 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
OB-ISS-1 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-1 The @context MUST begin with the VC 2.0 context URI (https://www.w3.org/ns/credentials/v2) followed by the OB 3.0 context URI.
OB-ISS-2 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-2 The type MUST be an unordered set containing ‘VerifiableCredential’ and one of ‘AchievementCredential’ or ‘OpenBadgeCredential’.
OB-ISS-3 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-3 A verifiable AchievementCredential MUST carry at least one proof mechanism (embedded data-integrity proof) or be issued as an external JWT proof.
OB-ISS-4 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-4 The issuer MUST be a Profile identified by an IRI in the issuer.id property.
OB-ISS-5 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-5 credentialSubject MUST be an AchievementSubject that identifies the achievement being awarded.
OB-ISS-6 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-6 The type sets MUST be unordered sets whose required IRIs are present: an AchievementCredential’s type MUST include ‘AchievementCredential’, and an Achievement’s type MUST include ‘Achievement’.
OB-ISS-7 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-7 An issued credential MUST be signed with a supported proof mechanism — a Data Integrity proof (the eddsa-rdfc-2022 or ecdsa-sd-2023 cryptosuite) or an external VC-JWT proof — and an embedded proof’s proofPurpose MUST be ‘assertionMethod’.
OB-ISS-8 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-8 The issued AchievementCredential MUST contain all required fields (id, @context, issuer, validFrom, credentialSubject) and be valid: it MUST pass JSON-LD validation in safe mode (every term resolved by an associated context).
OB-ISS-9 MUST ✅ done ob:3.0:conf:issuer/OB-ISS-9 The recipient MUST be identified in the AchievementSubject by either an id or at least one identifier (an IdentityObject, hashed or plaintext).

Information-model coverage (vs conform-ed model)

Section titled “Information-model coverage (vs conform-ed model)”
  • 340 literal items — 241 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”
  • ob:3.0:conf:displayer/OB-DSP-1
    • emergent verifies a third-party OB credential through the conform-ed engine wired to its JWKS / did:key / did:web key resolvers, reporting a structured verdict. Proven offline by driving the real verifyCredentialDocument service against a signed credential + in-memory JWKS.
  • ob:3.0:conf:displayer/OB-DSP-2
    • The admin-console displayer (apps/admin-console/…/CredentialVerifierPanel) renders the verdict and its axes (signature / validity / revocation / schema) plus the verified credential’s fields — achievement name + description, issuer, type, validity dates — extracted by summarizeCredential. Proven offline by the field-extraction test (the data the panel renders); the panel itself is covered by a dashboard render test.
  • ob:3.0:conf:displayer/OB-DSP-3
    • The verifier determines the validity-window state (valid / expired / not-yet-valid) from validFrom/validUntil and surfaces it as a distinct axis. Proven offline against an authentic but expired credential (signature valid, verdict invalid, window expired).
  • ob:3.0:conf:displayer/OB-DSP-4
    • The verifier evaluates the credential’s credentialStatus against its BitstringStatusList (fetch + gunzip + bit lookup), reporting active / revoked / suspended. Fail-safe: an uncheckable status is unknown (→ unverifiable), never a false pass. Proven offline against a revoked and an active entry.
  • ob:3.0:conf:displayer/OB-DSP-5
    • The verifier supports BOTH OB 3.0 securing mechanisms — enveloping VC-JOSE (EdDSA/Ed25519) and embedded eddsa-rdfc-2022 Data Integrity (JSON-LD/URDNA2015 canonicalization + raw Ed25519) — the full proof-suite scope locked for v1. Proven offline by verifying both a VC-JOSE and a did:key eddsa-rdfc-2022 Open Badge.
  • ob:3.0:conf:host/OB-HST-1
    • emergent now operates a Badge Connect API host (capability-b; ADR-0038). The OAuth2 authorization server (authorization-code + PKCE on @jmondi/oauth2-server) gates the getCredentials aggregation endpoint (GET /ims/ob/v3p0/credentials), which returns the learner’s owned, currently-valid credentials as the getOpenBadgeCredentialsResponse envelope — VC-JOSE enveloped credentials in compactJwsString, embedded-proof JSON-LD in credential. Proven offline: the real assembler partitions both forms and the envelope validates against conform-ed’s GetOpenBadgeCredentialsResponseSchema.
  • ob:3.0:conf:host/OB-HST-2
    • On any getCredentials failure (missing/invalid bearer → 401, insufficient scope → 403, host unconfigured → 503) the host returns the imsx_statusInfo service-error envelope (imsx_codeMajor=failure / imsx_severity=error) instead of the success envelope. Proven offline against conform-ed’s ImsxStatusInfoSchema.
  • ob:3.0:conf:issuer/OB-ISS-1
    • @context ordering (VC 2.0 then OB 3.0) is enforced by the export assembler and validated against the official 1EdTech OB 3.0 JSON Schema in the conformance lane.
  • ob:3.0:conf:issuer/OB-ISS-3
    • ⚠️ Proofs are VC-JOSE (compact JWS, EdDSA/Ed25519), not embedded data-integrity proofs. Issuer keys are platform-custodial in Supabase Vault behind the KeySigner seam (ADR-0015/0016/0017); verification is external via JWKS in v1.
  • ob:3.0:conf:issuer/OB-ISS-4
    • issuer is a per-org Profile resolved through a published JWKS endpoint. The Profile is now spec-complete: beyond id/type/name + the canonical image (ADR-0035), an org/platform admin authors the descriptive fields (url/email/description/phone/address/otherIdentifier/official) into issuer_profile.profile_meta, and parentOrg is derived from the org tree (ADR-0036). All are optional and additive, threaded through buildIssuerProfileNode into every emitted Profile (the single export, each CLR inner body, and the public, dereferenceable issuer Profile document); the totality guard against the official OB 3.0 schema still passes.
  • ob:3.0:conf:issuer/OB-ISS-5
    • Achievement.alignment binds to durable CASE node URIs (ADR-0018).
  • ob:3.0:conf:issuer/OB-ISS-6
    • The required type-set IRIs (AchievementCredential.type ⊇ {AchievementCredential}; Achievement.type ⊇ {Achievement}) are enforced by the export assembler and validated against the official 1EdTech OB 3.0 JSON Schema in the conformance lane.
  • ob:3.0:conf:issuer/OB-ISS-7
    • The credential is signed via the VC-JWT proof path (compact JWS, EdDSA/Ed25519) behind the KeySigner seam and is JWKS-verifiable; the conformance lane asserts the signature verifies. (The embedded-proof proofPurpose=‘assertionMethod’ clause applies only to the Data Integrity path, which emergent does not use.)
  • ob:3.0:conf:issuer/OB-ISS-8
    • The exported AchievementCredential carries all required fields and validates against the official 1EdTech OB 3.0 JSON Schema in the conformance lane (the safe-mode / required-field validity check). It now also carries the optional canonical Achievement.image (and the issuer Profile.image) as OB 3.0 Image nodes (ADR-0035) — a stable /img/{achievement,organization}/:id URL that always resolves (uploaded → external → generated title-card) so wallets always have badge art; the assembler asserts both Image nodes and the totality guard still passes.
  • ob:3.0:conf:issuer/OB-ISS-9
    • The recipient is identified by credentialSubject.id; the exported credential is schema-valid.