Set the decision boundary
A digital credential platform can support issuance, verification, and exchange. Your institution still owns the decision to award the credential and the responsibility to preserve its meaning over time.
Before you compare product features, name the people who can approve a credential, operate the issuer identity, use signing keys, change credential status, answer privacy requests, and approve an export or transition. The institution-owned digital credentials hub explains these controls.
An Open Badges 3.0 credential is a signed claim about one earner and one achievement. The Open Badges technical overview describes the issuer, achievement, earner, evidence, and signed credential model. Test the institutional controls around that model during procurement.
Review the controls in one representative credential
During evaluation, use a real credential policy. Include an achievement definition, approval path, learner information, evidence references, an issuer, and a planned retention period.
| Control | Question to test | Evidence to request |
|---|
| Issuer identity | Can the institution maintain the public issuer identifier and recover it after a staff, domain, or supplier change? | Issuer profile, domain ownership, key-discovery method, recovery procedure, and test record |
| Signing authority | Who can use, rotate, retire, or recover signing keys? | Key-management responsibilities, access review, rotation procedure, and incident response |
| Verification and status | Can an independent verifier retrieve the credential, validate its proof, and identify its current status? | Public verification route, machine-readable credential, status response, and test results |
| Credential records | Can the institution trace the criteria, evidence, approval, issuance, correction, and status history? | Data model, audit record, retention schedule, and export sample |
| Privacy and accessibility | Can the institution control what becomes public and make public verification usable? | Public-display settings, consent flow, correction process, accessibility documentation, and test scope |
| Exit control | Can the institution move records and continue to verify already issued credentials after a platform change? | Export specification, sample export, transition procedure, and verification-continuity plan |
Do not accept a feature list as proof. Ask the supplier to demonstrate each control with the same representative credential.
Test the lifecycle before contract award
Run the following tests in a sandbox or evaluation tenant. Record the product version, configuration, participants, date, result, and any limitation for each test.
- Issue a representative credential using an approved policy and a named institutional issuer.
- Verify it in a separate browser session without an administrator login.
- Download the machine-readable credential and check the issuer, achievement, proof, and status information.
- Test the learner’s permitted sharing and access path after the learner loses access to the originating course or LMS account.
- Suspend, revoke, expire, reinstate, or correct a sample credential according to the institution’s policy.
- Export issued credentials, credential definitions, evidence references, status history, issuer metadata, and verification documentation.
- Load the export into a separate test environment or inspect it with an independent verifier.
- Record which public URLs, keys, records, and operational responsibilities must persist after a platform change.
Use the digital credential evaluation worksheet to record each result.
Separate certification from other evidence
Ask each supplier to separate implementation claims from current certification status. When a supplier claims 1EdTech certification, verify the certification number and applicable role in the current product directory. 1EdTech’s procurement guidance separately calls for recipient portability, public verification, accessibility, and an exit strategy.
A certification claim does not answer every institutional question. Your review still needs evidence for privacy, accessibility, service operations, support, incident response, retention, and transition responsibilities.
Assign responsibilities for the operating model
Hosted and self-hosted deployments can both support institutional control. They assign operational work differently. Put the responsibilities in the agreement before launch.
| Operational area | Institution must decide | Supplier or operator must demonstrate |
|---|
| Credential policy | Criteria, evidence rules, approvals, public-display policy, retention, and corrections | How the system records and enforces the approved policy |
| Identity and keys | Issuer identity owner, acceptable proof methods, key-recovery authority, and access-review policy | Key storage, access controls, rotation, revocation, recovery, and incident handling |
| Verification | Public verification domain, status policy, accessibility scope, and continuity period | Verification behavior, uptime responsibilities, monitoring, and change management |
| Records and privacy | Data classification, retention, consent, correction, deletion, and post-graduation access | Data locations, export format, backup and restore process, subprocessors, and privacy controls |
| Exit | Required records, receiving environment, acceptance tests, and transition owner | Export process, documentation, support period, and limits or costs |
For a self-hosted service, assign the operational owner for infrastructure, patching, backups, monitoring, key custody, and incident response. Open source provides access to the code. It does not assign those responsibilities.
Evaluate the self-hosting evidence
CredTrail provides one product example. Its self-hosting runbook describes a Docker API and queue worker, Postgres, and an existing private S3 or R2 bucket. It also documents verified database connections, SMTP or SES email, upgrades, backups, and rollback. Review the deployment instructions against your institution’s operating model.
Name an owner and require evidence for each dependency:
| Dependency | Responsibility to assign | Acceptance evidence |
|---|
| Database and queue | Migrations, access control, backups, restore, and job processing | A restored database with credential, approval, audit, and status records reconciled |
| Object storage | Private bucket access, stored credentials and artwork, retention, and backup | A separate restored bucket with object counts and checksums reconciled |
| Signing and authentication | Key custody, recovery authority, operator secrets, and access review | A recovery procedure that preserves verification of existing credentials without exposing private keys |
| Public domain | Issuer identity, verification URLs, certificates, routing, and continuity after exit | Existing public URLs and issuer-key discovery still work after the transition |
| Email and operations | Sender configuration, delivery monitoring, failed notifications, patching, and incident response | A test receipt, a failed-notification procedure, and named support owners |
A database backup alone does not recover a service that also needs stored credential objects and operator-held settings. Keep signing material and authentication secrets in an access-controlled recovery process. Record how the team will maintain the public issuer identity and verification domain through a hosting or supplier change.
For the exit rehearsal, restore into a separate database and bucket. Retrieve an already issued credential, check its signature, confirm its current status, and reconcile the restored records and objects. Then test the public routes under the domain your institution plans to retain. Avoid overwriting the operating service during an evaluation.
Longsight ran this rehearsal locally on October 5, 2026. CredTrail issued a credential, verified its active proof, and revoked it. After restoring the database, stored objects, and test operator settings, the same credential passed an independent signature check, its public page remained available, and verification still reported it as revoked. The execution record describes the tested revision and recovery procedure. This exercise used local storage and email fixtures, not an institution’s cloud account, domain, or production keys. It does not establish production readiness or cross-product interoperability.
Make privacy and accessibility requirements testable
Public verification may expose a learner’s name, achievement, evidence, issue date, or status. Define which information is public by default, how learner consent works, how corrections are handled, and what remains available after graduation. Test the public page with the assistive technologies and browsers your institution supports.
Ask for an accessibility conformance report that states the evaluated product version, public verification pages, authoring and administrative functions in scope, known exceptions, and remediation owner. A report is a starting point. Test the workflows that a learner, verifier, issuer, and administrator must complete.
Define the exit evidence
An export is useful only if the institution can identify its contents, retain them, and use them after a supplier change. Require an export of the following records:
- Issued credentials and their machine-readable representations.
- Credential definitions, criteria, alignments, and evidence references.
- Issuer profiles, proof and verification metadata, and relevant public-key material.
- Status history, corrections, approvals, and audit records.
- Public verification documentation, API documentation, and implementation limits.
Use the Open Badges 3 governance guide for the ongoing policy and control decisions. If you need help mapping an institutional requirement to an operating model, contact Longsight.
