Open Badges 3 governance: a university guide to issuer control and verification

Treat the credential as an institutional record

An Open Badges 3.0 credential is a signed institutional claim. A learner, employer, another institution, or licensing body may need to check it after the original course, LMS account, or vendor contract has ended.

The Open Badges 3.0 specification aligns an OpenBadgeCredential with the W3C Verifiable Credentials model. The record can identify the issuer, recipient, achievement, evidence, issuance date, expiration, proof, and credential status. This shared model helps systems exchange a credential. Your institution must still define what the credential means and how long people can verify it.

Before you issue a credential, assign each responsibility to a named owner with authority to make the required decisions.

Responsibility	Decision to record
Achievement definition	Who approves the criteria, evidence, alignment, and changes to a badge template?
Issuance	Which system supplies eligibility data, and who can approve or automate issuance?
Issuer identity	Which institutional domain, public identifier, and signing keys represent the issuer?
Status	Who can suspend, revoke, expire, reinstate, or correct a credential, and under which policy?
Verification	Which public route supplies the current artifact and status, and who operates it after a platform change?
Retention and exit	What records must be retained, exported, transferred, or deleted when a program or supplier changes?

Record the answers in the program charter, operating agreement, and procurement documents. A badge platform can enforce the workflow. Your institution must define who has authority to use it.

Keep issuer identity and signing authority under institutional control

A verifier needs to know who made the claim and how to validate it. In the W3C model, the credential identifies an issuer and can carry a cryptographic proof. The proof lets a verifier check whether the credential has changed and whether the stated verification method produced the signature. The W3C Verifiable Credentials Data Model treats the proof, current credential status, and descriptive achievement data as separate concerns.

Give the institutional issuer a stable identifier that your institution can maintain. Document these controls before launch:

• The institutional domain and public issuer identifier.
• The owner of the DNS, decentralized identifier (DID) document, or other public-key discovery mechanism.
• Where signing keys live, who can use them, and how access is reviewed.
• How you rotate, retire, recover, and publish replacement keys without breaking the ability to verify older credentials.
• The response plan if a signing key is lost, compromised, or used incorrectly.

Do not rely on a vendor account, an individual staff member, or an LMS user account as the only path to the issuer identity. During a migration, preserve the issuer’s public identity and the information needed to validate credentials that were already issued.

CredTrail documents one inspectable implementation path in its Open Badges 3.0 reference: issuer did:web identifiers, Ed25519 signing, and W3C Data Integrity proofs. The public source repository lets institutions inspect or run that implementation. Use the example as implementation evidence, then apply your own issuer-governance policy.

Separate issuance history from current status

An issued credential can remain a valid historical record even when it is no longer active for a particular purpose. An institution may suspend a credential during a review, revoke it after a finding, or let it expire at the end of a license or certification period. Do not delete the original record to represent those decisions.

The W3C data model defines credentialStatus for discovering information about a credential’s status, including suspension and revocation. The Open Badges 3.0 conformance guide also distinguishes revoked credentials from credentials that have passed their validUntil date.

Before you issue credentials, define a status policy that answers these questions:

• What event can cause suspension, revocation, expiration, reinstatement, or correction?
• Who can approve each decision, and what notice does the learner receive?
• What reason, evidence, timestamp, and actor must the institution retain?
• Which status information is public, and which information is restricted to the learner or staff?
• How current must the status information be when someone verifies a credential?

Require your verification process to check status as well as the proof. A signature can still validate after a credential is revoked. A successful status check does not establish authenticity unless the verifier also identifies the issuer and validates the proof.

Design verification for people and systems

Provide a stable public verification service. Give recruiters and reviewers a human-readable record. Give software a machine-readable artifact it can validate.

Test these actions with an independent verifier:

1. Open the public verification URL without an LMS or campus login.
2. Identify the issuer, achievement, recipient information that is intentionally public, evidence, issuance date, and current status.
3. Download or retrieve the signed Open Badges 3.0 credential.
4. Validate the proof against the published verification method.
5. Check the live credential-status information and confirm the result agrees with the public page.
6. Repeat the test after a key rotation, a status change, and a platform migration rehearsal.

The Open Badges conformance guide requires viewer-initiated badge verification for certified platforms. Extend your acceptance test to cover the records, privacy settings, accessibility needs, and verifier journeys that matter to your institution.

CredTrail’s public verification documentation documents a shareable badge page, verification JSON, a JSON-LD export, and a status-list route. Use this as implementation evidence when evaluating the software. Test your deployment against your own policy.

Protect learner identity and evidence

Recipients can share open credentials beyond the system that issued them. Define how your program handles identity, evidence, and public display before you issue a credential.

Decide which fields are public by default. A public badge does not need to disclose every assessment artifact, grade detail, accommodation, roster attribute, or internal identifier. Make consent and correction paths clear. If a learner loses an institutional account, define how they regain credential access without weakening identity assurance.

Review the following areas with privacy, accessibility, and records-management teams:

• The recipient identifier and any alternate or learner-controlled identifier.
• Evidence links, their access controls, retention, and redaction process.
• Whether public pages appear in search engines and how a learner can request a change.
• The accessibility of the issuance, consent, viewing, download, and correction processes.
• Jurisdictional retention, deletion, disclosure, and legal-hold requirements.

Keep the credential record separate from the LMS account where practical. The LMS can supply course and eligibility information. A learner may need to verify a credential after graduation, an identity change, or an LMS migration. Longsight’s credential-system-of-record article explains why that boundary matters operationally.

Require a usable export and transition path

Open Badges 3.0 defines a portable credential format. Your exit plan must also cover the issued artifacts, status history, issuer metadata, and verification information needed after you leave a platform.

Test an export with representative credentials. Include active, suspended, revoked, expired, and corrected cases. Confirm that the export preserves the following information:

• The signed credential and its proof.
• Achievement templates, criteria, alignments, and evidence references.
• Issuer identifiers, verification methods, and key-rotation history needed to validate older records.
• Complete status history, including dates, reasons, and authorized actors.
• Recipient identity mappings and the documented process for privacy-preserving recovery.
• Public verification URLs, API documentation, and redirect requirements.

Import the export into an independent inspection environment or the intended replacement service. Record which fields transfer without change, which must be transformed, and what remains under the former provider’s control. An export file that no verifier can validate is not an exit plan.

Run governance acceptance tests before launch

Use a controlled pilot to test the complete governance process. Include the people who own academic policy, registrar records, privacy, accessibility, security, learner support, and operations.

1. Approve a small set of achievements and issuance rules.
2. Issue representative credentials to test learners with the intended privacy settings.
3. Verify each credential from a device and account outside the institution.
4. Suspend, revoke, expire, reinstate, and correct test records under the documented policy.
5. Rotate a test signing key and confirm that previously issued credentials remain verifiable as designed.
6. Export the pilot records and validate them in a separate environment.
7. Record defects, policy gaps, owner, remediation date, and retest result.

Keep the test evidence under institutional control. Use it to approve the program, assess a hosted or self-hosted deployment, and prepare for a future transition.