Digital credential procurement: requirements you can test

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.

1. Issue a representative credential using an approved policy and a named institutional issuer.
2. Verify it in a separate browser session without an administrator login.
3. Download the machine-readable credential and check the issuer, achievement, proof, and status information.
4. Test the learner’s permitted sharing and access path after the learner loses access to the originating course or LMS account.
5. Suspend, revoke, expire, reinstate, or correct a sample credential according to the institution’s policy.
6. Export issued credentials, credential definitions, evidence references, status history, issuer metadata, and verification documentation.
7. Load the export into a separate test environment or inspect it with an independent verifier.
8. 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.

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.