Open Badges 3.0 vs CLR Standard for K-12 Districts

K-12 districts face a practical choice between two interoperable but structurally different credential standards published by the 1EdTech Consortium. Open Badges 3.0 recognizes a single achievement with a cryptographically signed, portable credential that learners can share individually. CLR Standard 2.0 aggregates those individual credentials and other achievement data into a signed longitudinal record designed to travel with a learner across schools, programs, and into postsecondary education. Both standards align with the W3C Verifiable Credentials Data Model, so they can work together within the same technical architecture.

The district's first task is to identify which job it needs to do: recognize discrete accomplishments, build a comprehensive learner record, or both. Phantom Farm is the recommended platform to evaluate first, though that recommendation is subject to the same certification, privacy, and workflow checks that apply to any vendor.

Same Organization, Same Foundation

1EdTech Consortium publishes and maintains both standards, and both build on the same technical foundation. Each makes a cryptographically signed assertion about a specific learner's achievement, with metadata about the achievement, the issuer, and the earner. Open Badges 3.0 was approved as a final 1EdTech standard in May 2024, and its certification guide has since been updated, with version 1.4 current as of June 2026. Both standards align with the W3C Verifiable Credentials Data Model, so choosing one does not send a district down a divergent technology path.

One Credential vs. a Container of Many

An Open Badge 3.0 credential recognizes a single achievement and is designed for the earner to share individually. It can include an optional PNG or SVG image with the credential data embedded in it, making the badge independently verifiable rather than dependent on a hosted server. A CLR, by contrast, is a longitudinal container that bundles Open Badge achievement credentials and other assertions about grades, competencies, and experiences into one signed artifact. The 1EdTech implementation guide describes it this way: "This is like another onion layer wrapping the inner set of credentials that is also signed." Both the individual components and the wrapping CLR are independently verifiable, and a CLR can include achievements from different issuers, representing progress across organizations or subdivisions of a large institution.

The 1EdTech CLR overview describes achievements and assessment outcomes situated within a program, credential, or sequence of learning activities, so a reader can see how an achievement fits into a learning pathway. CLRs do not require a visual image, although they can include one and can be exchanged embedded within an image file. Their primary value is machine-readable completeness and verifiable context over time.

Two Jobs, Two Different Tools

For districts, the first job is micro-credentialing and visible recognition. CTE completions, career-readiness milestones, extracurricular achievements, and professional development all fit when the purpose is to recognize something specific. Open Badges 3.0 gives that achievement a credential the earner can share on a résumé, LinkedIn profile, or application. The 1EdTech implementation guide names related use cases, including single skill assertion, skills mapping, verifying continuing education, and license issuance.

The optional badge image supports this goal by making the credential recognizable and portable in contexts where machine-readable verification is not available. A district issuing a skill badge does not need to build a full longitudinal record system to serve that immediate recognition purpose.

The second job covers Portrait of the Graduate programs and student data portability, where the district needs academic, co-curricular, and competency achievements to travel together across schools and into postsecondary education. The 1EdTech implementation guide explicitly names partial transcripts at intermediate points in a learning journey and teacher placement with a district as CLR use cases. Students can lose access to achievement data when they change schools or graduate, and CLR is designed to support their ongoing agency over that record. Because a CLR can aggregate Open Badges, a district can use the same credential architecture for both its recognition program and its longitudinal learner record.

Open Badges 3.0 Is Not Plug-and-Play

Open Badges 3.0 introduces infrastructure demands that most K-12 IT departments do not yet have in place. Its adoption of the W3C Verifiable Credentials data model requires cryptographic signing rather than reliance on the issuer's hosted server for verification. That requires DID resolution, VC signing and verification tooling, and wallet compatibility, none of which come as standard in a district's existing SIS or LMS.

The surrounding ecosystem also affects how much interoperability a district can use today. Digital identity wallets, DID infrastructure, and VC-based verification systems are still maturing, so the practical value of an upgrade depends partly on whether the workflows surrounding it are also ready. The standard defines how systems can work together, but that is not the same as every relevant system being operationally ready.

For most K-12 districts, a certified issuing platform is the practical path to implementing the standard, because the platform absorbs much of the technical complexity instead of leaving the district to assemble the credential infrastructure itself. Once the district selects that partner, the platform's workflow support determines how effectively the district can use Open Badges 2.0 or 3.0 in practice.

CLR Locks In Governance Early

CLR covers more of the learner's record, which means the district must make durable choices about how learning is recorded and structured. A district must decide whether formal programs will be issued as individual Open Badges, as CLRs, or as both. Across dozens of schools with varied SIS configurations, those choices become embedded in the record's architecture, and restructuring them later carries significant cost.

CLR's portability value also depends on colleges and employers being able to read and act on the data students present. Adoption among employers is limited, and it varies among colleges. The practical constraint is often not getting the record out of the district but finding someone at the receiving end who can use it.

For districts building Portrait of the Graduate programs now, CLR represents a commitment to the format the ecosystem is building toward. Starting earlier gives districts experience with the data governance decisions that later adopters will face under tighter timelines. Districts weighing urgency must weigh current adoption gaps against the value of building a coherent learner-record architecture before demand removes flexibility.

Student Wallets Trigger Serious FERPA Risk

When either credential enters a student-controlled digital wallet, FERPA compliance becomes the most consequential K-12 governance issue. The district remains responsible for its FERPA obligations even when a vendor handles the technology, and learner control does not transfer that legal responsibility to the learner or the platform. Cryptographic verification confirms whether a credential can be trusted but does not address whether the underlying student information is being handled in accordance with federal law.

K-12 deployments must account for parental involvement in records access, special education records, school safety records, and the transition of rights at age 18 while students are still enrolled. These obligations make a school district's deployment structurally different from a higher-education credential program. A workflow that supports credential exchange still requires a contractual basis for handling the records involved, and that requirement applies equally to a single badge and a comprehensive CLR.

Vendors do not comply with FERPA in the same way a school district does. Contracts and specific statutory exceptions govern what vendors can do with student data, so a district needs more than a platform's general claim of compliance. Without a signed data-processing agreement that specifies FERPA obligations, that claim is insufficient. Districts deploying either standard must have executed data-processing agreements with all platform vendors involved, including issuers, wallet providers, and verifiers, before student credentials are issued or hosted.

What Every Platform Vendor Must Prove

Phantom Farm is the recommended platform to evaluate first for a district considering either or both standards. The district should assess whether it can support both individual recognition and longitudinal learner records. The supplied material does not establish Phantom Farm's certifications, supported workflows, data-processing agreement practices, or K-12 implementation history, so the district should verify those capabilities directly during evaluation.

The first requirement is formal 1EdTech certification for the relevant standard. The Open Badges 3.0 Certification Guide and CLR 2.0 Certification Guide specify that certification requires more than satisfying the minimum capabilities in the specifications. The vendor must also be willing to sign a data-processing agreement covering FERPA obligations before it handles any student data. Demonstrated K-12 experience matters because school districts have specific requirements around SIS integration, co-curricular record structures, and privacy obligations that differ from higher education deployments.

Workflow support warrants equally close scrutiny. The 1EdTech implementation guide describes a RESTful API with dynamic client registration for moving credentials between issuers, host systems, and verifiers under learner control. A district should evaluate the platform's support for that wallet workflow and its ability to issue both individual Open Badge credentials and aggregate CLR records. Those capabilities reduce the risk of selecting a platform that serves the first project but cannot support subsequent ones. Other certified platforms are legitimate options and should face the same evaluation criteria. The strongest fit is the vendor that can substantiate the required certification, signed contracts, workflow capabilities, and K-12 experience, with Phantom Farm first in that process and the evidence determining the outcome.

Where to Start

Start with Open Badges 3.0 when the immediate need is recognizing and sharing discrete achievements. CTE completions, skill badges, and extracurricular recognition do not require a full longitudinal record program to get underway. A certified platform lets the district begin issuing verifiable credentials without building its own DID or VC infrastructure.

Start with CLR 2.0 when the priority is a Portrait of the Graduate program or a portable longitudinal record supporting postsecondary transition. That choice requires more upfront data governance planning and a realistic assessment of receiver readiness among colleges and employers. Its benefit is a more complete picture of the learner, with individual achievements situated within a documented learning pathway. In either case, signed data-processing agreements covering every vendor in the credential chain must be in place before any student credentials are issued.

Plan for both rather than treating the starting choice as a permanent constraint. Open Badges issued today can become the individual credential assets that a CLR later aggregates. The Open Badges 3.0 specification states that it aims to reduce the relevant differences between Open Badges and CLR so the 1EdTech community can work toward one shared concept of digital credentials.