Issuance, Badging & Verification

6.1 Open Badges 3.0 Model & Assertions

Model. Nexus uses Open Badges for every credential (NB/MB/MC and program awards).
Objects (minimum):

Issuer Profile → organization metadata (GCRI), public keys, contact.
BadgeClass → what the badge represents (title, description, outcomes, standards/competencies, stable course code or program code, rev).
Assertion → who earned it (recipient), issuedOn, evidence, verification, status.

Normative fields (Assertion): id, type, recipient (hashed), badge (BadgeClass URI), issuedOn, verification, evidence[], revocationList/status.
Policy: One BadgeClass per course code with version = rev. New MAJOR/MINOR creates a new BadgeClass version; PATCH updates metadata only.

6.2 W3C Verifiable Credentials (VC) Envelopes

Every OB3 assertion is also packaged as a W3C VC for interoperability with wallets/HR systems.

VC Type: ["VerifiableCredential","OpenBadgeCredential"]
Issuer DID: did:web:nexus.gcri (primary) with migration plan to DID method supporting key rotation.
Proof: Linked Data Proof (Ed25519Signature2020) or JWS (ES256) — algorithm agility supported.
Status: VC references the same status list (revocation/expiration) as OB3.

6.3 Issuer DID & Key Management

Primary DID: did:web:nexus.gcri published under /.well-known/did.json.
Keys: HSM/KMS-backed; key rotation every 12 months or upon incident; previous keys retained for verification.
Verification methods: #keys-1 (active), #keys-0 (legacy).
Separation of duties: issuance keys (signing) ≠ registry keys (status list).
Backups & escrow: offline backup of seed material; dual-control access; audit logged.

6.4 Recipient Identity & Privacy (Hashing, Salts)

Recipient: email or DID; if email, hash with per-assertion random salt. Store only hash + salt in the assertion (never clear email).
PII: kept off-chain; OB3/VC contains non-identifying data.
Proof of possession (optional): challenge/response using recipient DID key or one-time email link during verification.
Data minimization: include only necessary fields; evidence pages redact sensitive info.

6.5 Evidence Links & Portfolio Attachments

Evidence array: links to portfolio artifacts (dashboards, clause packs, GIS matrices), assessor feedback, and rubric outcomes.
Provenance: each artifact page shows data lineage, model cards, license (SPDX), checksums, and (if public) DOI.
Integrity: immutable evidence URL with content hash; updates recorded as new versions with dated changelogs.

6.6 Revocation, Suspension & Expiry Policies

Status types:
- Valid (default)
- Suspended (temporary; investigation)
- Revoked (permanent; reasons below)
- Expired (end of validity window for program awards if requirements change)
Revocation reasons (enumerated): identity error, academic integrity breach, policy violation, credential superseded, legal/ethics determination.
Renewal/expiry: NB/MB do not expire; MC renews only after MAJOR update via delta exam; program awards follow their component MC currency.
Status lists: machine-readable (OB3 Status List, VC Status List 2021); published at stable URIs.

6.7 On-Chain Proofs (Hash-Only) & Registry Ops

Design: write hash-only proofs (Merkle root or direct hash) of assertion IDs to an auditable ledger via NXS-NSF.
No PII on-chain. Only non-reversible hashes and timestamps.
Operations: daily anchoring batches; on revocation, publish status change first, then include in next anchoring.
Disaster recovery: off-chain registry is canonical; on-chain is an integrity witness.

6.8 Verification Flows (Public Verify, PoP optional)

Public Verify (no login):

User enters badge URL or uploads VC.
Service fetches Assertion/VC.
Checks signature (issuer keys), status (valid/suspended/revoked/expired), and schema.
Displays BadgeClass metadata, code + rev, standards/competencies, and evidence links.

Proof of Possession (optional):

DID flow: Verifier issues challenge → learner signs with DID key → verify signature.
Email flow: one-time link to the recipient address; purely convenience, not stored.

API: /verify/{assertionId} and /vc/verify endpoints; rate-limited; returns machine-readable verdict + human summary.

6.9 Wallets, Passes & HRMS/ATS Integrations

Wallets: export/import as VC/OB3; compatible with common credential wallets; optional Apple/Google Wallet pass (convenience, not authoritative).
HRMS/ATS: JSON-LD fields expose ESCO/O*NET, standards, and competencies; endpoints support employer queries.
Transcripts: machine-readable transcript API exposes completions (code + rev) and statuses (Current/Grace/Renewal Due).
Standards: optional support for 1EdTech CLR (Comprehensive Learner Record) where required.

6.10 Branding, Co-Badging & Partner Issuance

Branding: GCRI/Nexus as issuer of record; visual co-branding allowed with partner logos per MoU.
Co-badging models:
- Co-issued: partner appears as endorsement with ROR ID; single Assertion.
- Dual issuance: GCRI and partner issue separate Assertions referring to the same evidence.
Partner namespaces: distinct BadgeClass URIs per issuer; clear “recognition vs. accreditation” language (no implied licensure).
Quality control: co-badged offerings MUST pass the same QA gates (WCAG, psychometrics, provenance).
Marketing use: badge image files are derivative; credential truth resides in the Assertion/VC/Status.

Acceptance Checklist (Issuance & Verification)

BadgeClass references stable course/program code and rev.
Assertion uses hashed recipient with random salt.
VC signed with current issuer DID key; previous keys remain verifiable.
Status endpoint returns machine-readable result; suspension/revocation reasons recorded.
Evidence links resolve; artifacts show provenance and license.
On-chain anchoring batch includes latest assertions/revocations (hash-only).
Public verify flow passes; PoP optional flow works.
Co-badged entries include partner ROR and endorsement metadata.
All documents pass schema validation (OB3/VC) and rate-limit rules.
DR test: cold-restore verification from backups within RTO/RPO targets.