Why We Think Credentials Should Live Outside the LMS

For years, digital credentials have often been framed as an LMS feature.

That framing is understandable. Courses live in the LMS. Assignments are graded there. Completion is recorded there. If an institution starts thinking seriously about badges or verifiable credentials, it is natural to look first at the platform already sitting in the middle of teaching and learning and ask: can it do this too?

But the longer we have worked on CredTrail, the less satisfying that answer has felt.

A course has a lifecycle. 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 once used every day.

A credential is supposed to mean something more durable than all of that.

If a badge only works as long as a course shell exists, or as long as a learner can still sign into the LMS that first issued it, then it is hard to call that credential durable. The point of a credential is not just that it was issued. The point is that it can still be understood, shared, and verified later, outside the moment and outside the system that created it.

That is why we keep coming back to the same conclusion: the LMS can be part of the credential workflow, 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 be the place where issuance starts. It can supply roster data, course context, assessment signals, and the administrative workflows institutions already trust. But once something becomes a credential, it needs a different kind of home, one built for persistence, verification, portability, and learner control.

For a while, the market mostly moved in the opposite direction. Credentialing was often absorbed into larger platforms, either as a feature add-on or through acquisition. That made sense from a product perspective, but it also reinforced a habit of thinking: if the LMS can issue the badge, maybe the LMS should own the badge.

We do not think that assumption holds up very well anymore.

Part of the reason is architectural, and part of it is historical. A few years ago, it was fair to say that the standards landscape was still settling. Today, that is much less true. Open Badges 3.0, the Verifiable Credentials 2.0 family, and the emerging wallet exchange standards around OpenID4VP and OpenID4VCI have given this space a more serious foundation. We are no longer waiting for the basic pieces to exist. They exist now, and that changes what is reasonable to build.

That shift is what shaped CredTrail. We are building it as an API-first, open-source credential layer rather than as a closed feature tucked inside one platform. The public code is here: github.com/LongsightGroup/credtrail-app.

CredTrail public verification docs and export surface

CredTrail keeps the human-facing badge page and the verification/download surface connected through a public, standards-based credential model rather than burying them inside one LMS workflow.

The practical implication is simple: an LMS can still trigger issuance, but the credential does not have to stay trapped there. It can have a standards-based API surface, 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 edge cases may sound mundane, but they are exactly where a lot of credential systems reveal what they were really built to prioritize.

A public badge wall is a small but important architectural signal: credentials can stay visible, verifiable, and shareable without forcing the learner back through the LMS that first issued them.

Open source matters here for the same reason open standards matter. If institutions are going to treat digital credentials as part of a durable learner record, they should be able to inspect the system, run it themselves, and understand how the pieces fit together. They should not have to trust a black box simply because it is convenient in the short term.

That belief shows up in the rest of the architecture too. We chose technology that institutions can understand and carry forward: TypeScript for a shared codebase across runtime profiles, Postgres for operationally familiar relational data and queue state, S3-compatible object storage for signed credential records, and both Cloudflare-hosted and Node + Docker deployment paths so self-hosting does not depend on a single vendor’s infrastructure.

Maybe the clearest way to say all of this is the simplest: a credential is about the learner, not the platform.

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