Credentials Should Live Outside the LMS
Digital credentials need an institution-controlled service that preserves issuer identity, proof, status, and portability after a course ends.
Why credentials need a separate system of record
Digital credentials should live in an institution-controlled service outside the learning management system (LMS). An LMS can trigger issuance from course, roster, and grade data. The credential itself needs a service designed for long-term retention and verification.
Course shells are often active for one term. Institutions copy them forward, restrict access, or retire them. They also change platforms, replace authentication systems, and sometimes run several LMSes at once. Learners graduate and lose access to their campus accounts.
A learner may need to share a credential years later with an employer, licensing body, another institution, or public profile. That use should not depend on an LMS account from a decade earlier.
A badge tied to an old course shell or LMS account inherits the platform’s access and retention limits.
For the institutional policy behind that boundary, use the Open Badges 3 governance guide. It covers issuer control, verification, status decisions, privacy, retention, and exit tests.
The LMS can supply the roster data, course context, assessment signals, and administrative workflow that determine when to issue a credential. After issuance, a credential service must preserve the record, verify it, export it, and give the learner durable control.
The credential lifecycle
A separate credential service must manage the lifecycle from issuance onward. It must preserve the issuer’s authority, the signed record, and later status decisions when courses, accounts, and platforms change. CredTrail assigns those responsibilities as follows:
| Lifecycle stage | Institutional requirement | CredTrail implementation |
|---|---|---|
| Issuer identity | Keep the issuer’s identity and public keys independent of LMS accounts. | Tenant issuer identity uses did:web documents and tenant key material. |
| Proof | Give verifiers a signed artifact they can check independently. | Open Badges 3.0 JSON-LD credentials use W3C Data Integrity proofs. |
| Verification | Let people and systems inspect the same authoritative record. | Public badge pages and verification JSON expose issuer details, evidence, proof checks, and lifecycle state. |
| Revocation and status | Record suspension, revocation, expiration, and reinstatement without deleting the issuance history. | Assertion lifecycle records track state changes and event history. |
| Retention | Preserve the issued artifact and its operational history under institutional policy. | CredTrail separates the immutable signed credential from the assertion lifecycle record. |
| Migration | Move credential records without reconstructing them from an old LMS. | JSON-LD downloads preserve the signed artifact. Wallet exchange supports learner-controlled storage. |
Open Badges 3.0 defines the credential model. The W3C Verifiable Credentials 2.0 family defines the underlying data and proof model. OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) define how issuers, holders, and verifiers exchange credentials.
CredTrail implementation
CredTrail exposes this model through an open-source credential service and API. Institutions can inspect the CredTrail source code.
The public badge page, verification route, and export options use the same credential record.
An LMS can trigger issuance. CredTrail then maintains the credential through a standards-based API, a stable verification route, portable credential data, and learner-controlled wallet and profile options. This keeps the record available through course deletion, LMS migration, domain changes, and identity remapping.
A public badge wall keeps credentials visible and verifiable without forcing the learner back through the LMS that first issued them.
Institutions can inspect CredTrail’s code, run the service, and trace how it verifies credentials. The credential remains portable because its meaning and proof follow open standards rather than private vendor behavior.
CredTrail uses TypeScript across runtime profiles, Postgres for relational data and queue state, and S3-compatible object storage for signed credential records. Institutions can use a Cloudflare-hosted deployment or run CredTrail with Node and Docker.
