Why We Think Credentials Should Live Outside the LMS

For years, digital credentials have been treated like another LMS feature.

It makes sense. The LMS knows the course. It knows the roster. Teachers grade assignments there, and the system records completion there. When a school starts thinking seriously about badges or verifiable credentials, the first question is usually whether the LMS can do it.

It can. That does not mean it should own the credential.

A course shell has a short life. It opens, runs, closes, gets copied forward, and eventually disappears. Platforms change too. Contracts end. Institutions migrate. Authentication systems get replaced. 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 the old LMS.

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 durable. It is closer to a record trapped in a tool.

The LMS can still be part of the workflow. In many cases it should be. But it should not be the long-term home of the credential itself.

The LMS is a good place to observe learning activity. It can start issuance. It can supply roster data, course context, assessment signals, and the administrative workflows institutions already trust. Once something becomes a credential, though, it needs a home that can preserve it, verify it, export it, and give the learner some control.

For a while, the market mostly went the other way. Credentialing was absorbed into larger platforms, either as a feature add-on or through acquisition. That made sense for the vendors. It also encouraged a bad habit: if the LMS can issue the badge, maybe the LMS should own the badge.

We do not think that holds up anymore.

A few years ago, building the credential layer outside the LMS was harder to defend. The standards were still moving. Wallet support was immature. Verifiable credentials felt more like standards work than campus software.

That has changed. Open Badges 3.0 exists. The Verifiable Credentials 2.0 family exists. OpenID4VP and OpenID4VCI give issuers, holders, and verifiers a more concrete way to exchange credentials. We are not waiting for the basic pieces anymore.

That is where CredTrail fits. We are building it as an API-first, open-source credential service, not a closed badge tab tucked inside one platform. 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.

Those cases sound mundane until you are the person trying to verify an old credential after a migration. Then they matter a lot.

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

Open source matters for the same reason open standards matter. 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: 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. Hosted should be an option. Self-hosted should be an option too.

A credential is about the learner, not the platform.

The LMS may be where the record starts. It should not be where the record ends.