oodamaticbadge service — verifiable organization badges (Cyber AB demo)

The Certification Badge, Made Live

Today, a certification is a PDF and a row in a directory someone has to go look up. This platform turns it into a live object: one badge record at the issuer, projected onto every surface that matters — the holder's website, a verification page, and a cryptographically signed credential. Change the record once, and every surface changes with it. Revoke it, and the badge disappears from the holder's site.

Walk the demo — four personas, four pages

1 · The Certified Organization

Dana — operations lead at Meridian Defense Solutions (recipient)

Dana passed a CMMC assessment and wants the world to know — especially the primes running supplier diligence. She pasted one line of HTML into the company site. Done forever.

  • Visit her site: the client demo page
  • Notice: the badge isn't a saved image — it renders live from the issuer on every page load
  • Click the badge — it links straight to its own verification page

2 · The Third-Party Verifier

A supplier-risk analyst at a prime contractor

Someone claims to be certified. The analyst doesn't call anyone, request a PDF, or trust a screenshot — she asks the issuer of record and gets a live answer.

  • Look up any org or badge ID: the verification page
  • Notice: a revoked badge shows REVOKED — truth, not a dead link
  • For automated diligence, her systems fetch the signed credential instead (persona 4)

3 · The Accreditation Body

A program administrator at the issuer (Cyber AB)

The admin holds the one record every surface derives from. Suspension and revocation are not letters that get filed — they are switches that propagate.

  • Open the admin console — sign in with Cloudflare Access, no token needed
  • Issue by EIN + CAGE alone — the legal org name auto-resolves (local registry → SAM.gov by CAGE); set a validity window with the date pickers; suspend, reinstate, revoke on an enforced state machine, not free-form edits
  • Every action is Cedar-authorized and lands in the audit log — including refusals
  • Click Suspend (repeatable) or Revoke (terminal), then reload Dana's site: the badge is gone

4 · The Machine

Any system that needs proof without a phone call (integrator)

Everything above is also an API. A wallet, GRC platform, or procurement system verifies a badge without ever asking the issuer's permission — the cryptography answers.

  • GET /credentials/{id} — signed Open Badges 3.0 / W3C VC 2.0 credential
  • GET /.well-known/did.json — the issuer's public key (did:web)
  • GET /status/list — signed Bitstring Status List: one bit per badge
  • GET /api/badges/{id} — plain JSON status for simple integrations

The five-minute walkthrough

  1. Open Dana's company site — see the badge advertising the certification.
  2. Click the badge → the verification page: live status, EIN/CAGE, level, dates, C3PAO of record.
  3. From the verify page, open the signed credential (JSON) — this is what machines consume.
  4. In the admin console, Suspend the badge (repeatable — revoke is terminal, so suspend/reinstate lets you run the demo again).
  5. Reload Dana's site: the badge has disappeared. Reload the verify page: SUSPENDED. Re-fetch the status list: the bit is set. One record changed; three surfaces told the truth. Reinstate to bring it back.

Admin access — sign in, or get a token

The admin console and every /api/admin/* endpoint accept two kinds of principal — humans sign in, machines present a token. Nothing secret is stored in code or on disk:

Humans — no token at allCloudflare Access now fronts /admin: open it and Cloudflare sends a one-time PIN to your email (@oodamatic.com / @aiwars.ai are allowed). The Worker independently verifies the Access JWT, and your email becomes the audit actor. No shared secret exists for humans anymore
Root token (break-glass only)A root bearer still exists as a Cloudflare Worker secret for two cases only: recovery if Access is ever misconfigured, and local wrangler dev (where Access isn't in the request path). It is not a normal access path — humans sign in, machines use named tokens
Cloudflare-native (production)The running Worker reads the token from a Cloudflare Worker secret. Provision or rotate it entirely inside Cloudflare: wrangler secret put ADMIN_TOKEN, or dashboard → Workers & Pages → cyberab-badge-demo → Settings → Variables and Secrets. Secrets are write-only by design — nobody can read a token back out of Cloudflare, so the administrator who sets it is the one who distributes it, and rotating it instantly revokes every copy in circulation
Named tokens + auditThe console and the API share the same bearer surface — the console is just an API client. The root token can mint named API tokens (POST /api/admin/tokens) for each person or system; only a hash is stored, and every change is attributed in the audit log (GET /api/admin/audit): who, what, which badge, when. Rotating or revoking a named token never disturbs the others

Don't have the token? This is what authorized administrators see — token accepted, issuance form, and full lifecycle control per badge:

Admin console with a valid token: issue form plus Suspend/Revoke/Reinstate controls and live status per badge

Every admin decision is policy-as-code (Cedar)

Authorization here is not if-statements — the Worker asks the Cedar policy engine (AWS's open-source authorization language, running as WASM inside the Worker) for a PERMIT/DENY on every admin action. Who can do what is a policy file, not application code — reviewable, diffable, and provably enforced:

// Named API tokens (machines: CI, billing, assessment platforms) —
// day-to-day automation only. Deliberately NOT permitted:
//   badge.revoke  — terminal certification death is a human decision
//   token.*       — a machine must never mint or revoke credentials
permit (
  principal is BadgeAdmin::Token,
  action in [
    BadgeAdmin::Action::"badge.issue",
    BadgeAdmin::Action::"badge.suspend",
    BadgeAdmin::Action::"badge.reinstate",
    BadgeAdmin::Action::"audit.read"
  ],
  resource
);
root tokenAccess humannamed API token
issue / suspend / reinstate✓✓✓
revoke (terminal)✓✓✗ denied by policy
mint / revoke tokens✓✓✗ denied by policy
read audit log✓✓✓

Denials are themselves audit events (authz.deny) — the log shows not just what happened but what was refused. For an accreditation body this is the trajectory that matters: the same engine can compile compliance controls (NIST/OSCAL → Cedar) so that "who may touch a certification" is continuously, mathematically enforceable — not a paragraph in an SOP.

How APIs drive the whole lifecycle

Nothing here requires a human at a keyboard. Every lifecycle event is an API call, which means the badge can be wired directly into the systems where certification events actually happen:

Assessment close-outC3PAO or assessment platform calls POST /api/admin/badges with just EIN + CAGE (the legal org name auto-resolves via SAM.gov) — the badge (and everything downstream: registry proof, the holder's embed) exists the moment certification does
Non-payment / lapseBilling system calls POST …/suspend — badge goes dark on the holder's site until …/reinstate
Adjudicated violationCase-management system calls POST …/revoke — terminal, propagates everywhere within the cache TTL (5 minutes)
Supplier onboardingProcurement/GRC systems pull GET /credentials/{id} once, then watch GET /status/list — continuous monitoring of an entire supplier base from one signed document
Independent auditAnyone verifies offline: check the Ed25519 proof against the published did:web key. The issuer never knows the check happened

Why this matters

For the accreditation body

  • Your registry becomes the product. Every badge is a live projection of your database — all trust flows back to your platform, not to screenshots of it.
  • Enforcement with teeth. Today, revoking a certification changes a database row nobody looks at. Here it visibly removes the mark from the violator's website — within minutes, automatically.
  • First-mover whitespace. No accreditation body offers an organization-level verifiable badge. ANAB, A2LA, PCI SSC all stop at directories for orgs and Credly for individuals.
  • Standards, not lock-in. W3C Verifiable Credentials 2.0 + Open Badges 3.0 + Bitstring Status List — the stack that superseded blockchain credentialing. No ledger, no vendor dependency, auditable by anyone.
  • A new class of service. The status list turns one-time certification into continuous assurance — something primes and insurers will pay to consume.

For the certified organization

  • One paste, true forever. A single HTML snippet; no files to update, no expired logos, no compliance-marketing maintenance.
  • Proof competitors can't fake. A copied image fails verification; a screenshot isn't a signature. Your badge is backed by the issuer's cryptographic key.
  • Shortens diligence. When a prime's supplier-risk system can verify you in one API call, you clear onboarding gates faster than the vendor sending PDFs.
  • Portable credential. The signed OB 3.0 credential is yours — present it in supplier portals, wallets, or bid packages, verifiable anywhere, no issuer round-trip.
  • Fairness cuts both ways. The same mechanism that removes a revoked competitor's badge is what makes yours worth displaying.

All surfaces

Client demo sitea certified company advertising its badge (persona 1)
Verification lookupthird-party attestation of any badge (persona 2)
Admin consoleissue · suspend · revoke · reinstate (persona 3)
Status listsigned W3C Bitstring Status List (persona 4)
Issuer DIDdid:web document with the Ed25519 public key (persona 4)

Under the hood: one Cloudflare Worker, one D1 row per badge, Ed25519 eddsa-jcs-2022 proofs, and an embed that returns HTTP 410 the moment a badge stops being true.