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 defines a shared credential format that different systems can exchange. It records who issued the credential, who earned it, what they achieved, and supporting evidence. It can also include expiration and status information. Your institution must 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	Where can people check the credential and its current status, and who maintains that service 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. Use them to configure the platform’s permissions and approval workflow.

Keep issuer identity and signing authority under institutional control

A verification service needs to check who issued the credential and whether anyone has altered it. A digital signature provides evidence for that check. It does not show whether the credential has since expired or been revoked. The W3C Verifiable Credentials Data Model treats these as separate checks.

Give your issuer a stable identifier that your institution can maintain. Before launch, document the following:

• The institutional domain and public issuer identifier.
• Who maintains the public information that verification services use to identify your institution and check its signatures.
• 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.

If you are evaluating CredTrail, ask your technical team to review its issuer and signing documentation against these requirements. Its public source code is available for a detailed review.

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 Open Badges 3.0 conformance guide distinguishes revocation from expiration. Revocation records a decision to withdraw the credential; expiration means it has reached its stated end date. Your verification service must report the difference.

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 identify the issuer and check both the digital signature and current status. A signature can still validate after a credential is revoked.

Have your technical team check the credential format

Ask your technical team to check a sample credential against the Open Badges certification requirements. One required check for issuers, called JSON-LD safe-mode validation, rejects field names that the credential’s format does not define.

Ask the supplier to demonstrate that a correctly formatted sample passes and a sample with an undefined field name fails. Have your technical team retain the test settings and results so it can repeat the check after an update.

Keep this format check separate from checks of required information and the digital signature. Changing a signed credential can also invalidate its signature. Passing these tests does not establish 1EdTech certification.

Check that revoked credentials are reported correctly

After revoking a test credential, check it through an independent verification service. Save the signed credential and the verification result, including the time of the check. The result must identify the issuer, confirm the signature, and report that the credential is revoked. An absent page or deleted badge record does not prove revocation.

The certification tests for systems that display badges distinguish active, expired, and revoked credentials. They also require viewers to be able to request a verification check.

A link to status information does not itself prove revocation. The verification service must retrieve and check the issuer’s published status, then check the expiration date separately. Your technical team can use the W3C status-list checks to review how the service does this.

Use test credentials without real learner data. Issue each with a valid digital signature. To test expiration, let a credential reach its expiration time. To test revocation, revoke one through the issuer’s normal process. Keep the original signed credential in both cases.

Test case	Expected result
Active credential	The signature is valid, the credential is within its validity period, and the revocation check reports not revoked.
Expired, not revoked	The signature can remain valid. The service reports that the credential has expired and has not been revoked.
Revoked, not expired	The signature can remain valid. The service reports that the issuer has revoked the credential, even though its expiration date has not passed.
Credential altered after signing	The signature check fails. The page must not present the credential as successfully verified.
Current status cannot be checked	The service explains that it could not check status. It must not report the credential as active.

Save each test credential, the verification service used, the result, and the time of the check. Have your technical team keep the detailed signature and status reports, including how recent the status information was. Confirm that the public page and downloaded verification result agree, including when a viewer requests a fresh check. Repeat after replacing a signing key and when rehearsing a move to another platform.

If you are evaluating CredTrail, use its public verification documentation to plan these tests. Request results from the system you would use before marking a requirement as met.

Design verification for people and systems

Provide a stable public verification service with a page that recruiters and reviewers can read and a machine-readable credential that software 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. Check the digital signature using the issuer’s published verification information.
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.

Include your institution’s records, privacy settings, accessibility needs, and verification workflows in the tests.

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 credential and its digital signature.
• 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 test environment or the intended replacement service. Record which fields transfer without change, which require conversion, and what remains under the former provider’s control. Confirm that an independent verifier can validate the exported credentials.

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.