QFlowLearn: QTI 3.0 authoring
Credentials Should Live Outside the LMS
February 12, 2026 badges

Credentials Should Live Outside the LMS

CredTrail keeps badge issuing, verification, and portability outside the LMS.

Credentials Should Live Outside the LMS

Higher-ed RFPs have pushed digital credentials into another LMS checkbox. The LMS knows the course, the roster, and the grades, so certificates and badges often start there. But LMS-centered credentials have several limits.

A course shell has a short life, usually 12 to 14 weeks. It opens, runs, closes, gets copied forward, and eventually disappears. Platforms change, contracts end, and institutions often run multiple LMSes. Authentication systems get replaced. Most importantly, students graduate and lose access to the accounts they used every day.

A credential has a different job. A student may need to share it years later, with an employer, a licensing body, another school, or a public profile that has nothing to do with their LMS from a decade ago.

If a badge only works while the old course shell exists, or while the learner can still sign into the LMS account that first issued it, it is not a durable object: it’s just an RFP checkbox for an LMS.

The LMS is a good place to observe learning activity and is often the right place to start issuance. The LMS can supply roster data, course context, assessment signals, and the administrative workflows institutions already trust. But once the rules are passed and it becomes a credential, it needs a home that can preserve it, verify it, export it, and provide the learner some (durable) control.

A few years ago, building the credential layer outside the LMS was harder to defend. The standards continued changing and wallet support was immature. Verifiable credentials felt more like standards work than usable campus software.

Now Open Badges 3.0 and the Verifiable Credentials 2.0 family exist. OpenID4VP and OpenID4VCI give issuers, holders, and verifiers a defined way to exchange credentials.

CredTrail is an API-first, open-source credential service, not an LMS RFP checkbox. The public code is here: github.com/LongsightGroup/credtrail-app.

CredTrail public verification docs and export surface

CredTrail keeps the badge page, verification route, and export options tied to the same public credential record.

The LMS can still trigger issuance; the credential just does not have to stay there. It can have a standards-based API, a stable verification route, portable credential data, and a path into learner-controlled wallets and profiles. It can survive course deletion, LMS migration, domain changes, and identity remapping.

CredTrail public badge wall with copyable credential links

A public badge wall keeps credentials visible and verifiable without forcing the learner back through the LMS that first issued them.

Open source and open standards are both important: if a school is going to treat digital credentials as durable learner records, staff should be able to inspect the code, run the system, and trace how verification works. A black box is a bad place to keep records that are supposed to outlast a vendor contract.

We picked boring pieces on purpose for the tech stack: TypeScript for a shared codebase across runtime profiles, Postgres for relational data and queue state, S3-compatible object storage for signed credential records, and both Cloudflare-hosted and Node + Docker deployment paths.

References

Related Articles

Automating Accessibility with Playwright and axe
January 21, 2026 Accessibility

Automating Accessibility with Playwright and axe

Our newer Sakai end-to-end suite lives in Playwright, so accessibility checks belong there too. Here is how we pair keyboard-first workflow tests with axe scans in a Java-based Playwright harness.

Work with Longsight

Bring us the problems that cross your LMS, identity, and compliance systems.

We can host the service, help you run it on campus, answer security review, integrate with your LMS, and work through accessibility requirements.