Digital Credential
Transport Mechanisms
Survey Report

At this time we are totally waiting for demand from our client institutions. Our CLR use case is being adopted by some of our client institutions and at least one is talking to employers. We will decide based on demand.

We deal with a lot of systems but not often with employer systems

Greater standardization and clearer implementation guidance around credential exchange and verification would significantly improve interoperability with employer systems. In particular, it would help to have: Widely adopted, well-specified APIs and profiles for credential sharing, retrieval, and verification between issuer platforms, wallets, and employer systems. Clear, interoperable patterns for consent, authorization, and trust frameworks between institutions, learners, and employers. Better alignment on how different credential formats (e.g., Open Badges, Verifiable Credentials, CLRs) are packaged, transported, and consumed in real-world. More reference implementations, conformance testing tools, and real-world adoption by major HR platforms and employer-facing systems. Today, many employer systems still rely on custom integrations or manual processes. Reducing ambiguity in standards, improving developer tooling, and increasing adoption on the employer side would make end-to-end interoperability much easier to achieve at scale.

Implementation of OB/CLR API from their end

We should seek interoperability across all systems. Open Badges 3.0 should work like W3C VCs with the only differences being the data properties specific to LER use cases. The further Open Badges and CLR stray from how W3C VCs work, the more challenging it will be to achieve adoption. More than APIs, we need more open source software and web browser based tools that can make it easier to verify and consume credentials. We also need testing and certification of technical providers that is more aligned with expected use of the credentials; that mimics actual use scenarios,

`DID` centered architecture with passkey

Standardised employer ingestion from credential verification systems.

Most government agencies and universities in Korea tend to require 1EdTech Open Badges certification when adopting badge systems. However, due to network and organizational constraints, they often operate Open Badges–based systems that are not actually open, which creates a somewhat ironic situation. While I am not fully aware of how other organizations handle this, this has been my personal experience so far. From our perspective as a company developing a badge system, we would like to see more flexible and interoperable network connections between these institutions than what currently exists, but realistically, achieving this does not seem easy.

a stanadard adopted by all the leading credential providers

If employer platforms used more standards

The up stream or platforms which are trying to centralize and track credentials need to adopt. Without this there is no point in platforms down stream trying to adopt or share data between themselves. All of your effort should be focused on getting their adoption.

Having employer systems adopt a standard and place for credentials - that is needed prior to integration ability with APIs

clear alignment of trusted/verifiable data

Assessment that leads to credential imbedded into the LMS or an integration to connect.

Employer adoption of both open standards for system-to-system transfer and internet-based open standards based on credential wallet APIs would be a huge benefit to the credential community.

The ease of data transfer

Greater employer familiarity with credentials

If employer systems could consume VCs in any way. Additionally -- parity on data receipt. System interoperability should be a 2 way exchange.

Employer systems ready to collaborate. I don't get the impression Employer systems are interested in collaborating.

Why does all of this need to be so complicated? Doesn't an OB 3.0 claim contain enough information within itself to be shared as a file? A learner can store, transfer, deliver this claim in a tamper-proof way as a file or a url to the file. Isn't this the ultimate simplicity? Where we have certain vendors asking each other and us to implement specific API connections, it seems to be too complicated and undermine the entire ecosystem. I really feel like less is more -- instead of focusing on new specs, can we just keep the spec simple and motivate/educate on the user of file-based transfter?

Unified language and commitment. Agreement to move away from proprietary systems (bridges, not moats) to the benefit of the learner/earner.

Employer systems being present and adopting the technology we're implementing. This is what we've (as a community) have been chasing for years. It's good to see state-based initiatives looking to OB and CLR as requirements for their wallet implementations, but it still needs employers and the systems they use to come to the table.

・発行や検証機能は我々のプラットフォーム側で対応し、連携先のシステム側では表示のみを行えばいいようなAPI連携機能を実装している。

(Issuance and verification functions are handled on our platform side, and we have implemented an API integration function so that the linked system only needs to display the data.)

Better interoperability requires moving past simple 'data portability' and toward actualised 'data utility.' For our platform, the primary catalyst for seamless integration would be the broad industry adoption of standardized, machine-readable schemas. This includes but is not limited to CLR and W3C VCs. By leveraging CLRs to provide a multi-faceted, competency-based view of a learner's achievements alongside real-time API webhooks (to manage events), we can bridge the gap between regional credentialing and global employer systems. The aim herev would be to replace manual verification with an automated, high-trust 'scaffold' that protects learner privacy while providing down-stream systems/services/employers/other with the data-dense insights required for modern planning.

I think we need a unified global protocol, just like the USB standard. It's not just about having the protocol; everyone needs to strictly adhere to the rules.

For us this is not a common requirement

A standard issuer-to-wallet

1) We need employer systems at the table to design these standards - that's noticeably missing other than in limited doses through HR Open's work. 2) Trusted Career Profile support. 3) Employer education on LER data value

open source standards

If they accepted badges.

Interoperability would be accelerated by standardized APIs and shared data schemas that allow verified credentials to flow directly into ATS and HRIS fields (skills, certifications, qualifications) without custom mapping. Clear employer-side verification workflow standards covering authentication, authorization, and response formats would ensure compatibility across systems like Workday, SAP, Oracle, Greenhouse, and Lever. Co-marketing and employer-funded pilot would significantly accelerate adoption, jointly introducing the platform to employers, running real-world pilots, and demonstrating measurable impact models around skills validation and hiring efficiency. Joint employer education backed by outcome data would help shift hiring practices toward verified, skills-based approaches by proving reductions in time-to-hire, improved quality-of-hire, and lower credential fraud. Stronger ecosystem collaboration through standards bodies like 1EdTech combined with introductions to employer innovation teams, would help align product roadmaps and scale interoperable implementations faster.

We do not generally interoperate with employer systems. Mostly we did not encounter this requirement with our current clients.

compatibility with skills based credential metadata with employer needs

A strong off-the-shelf solution for the employers so they can trust and transition from existing models.

Employer systems are still largely optimized around traditional HR data (job titles, requisitions, binary "degree / no degree" fields) rather than rich, machine-readable credentials. To interoperate more easily, we need: 1. Standard employer-facing profiles for credentials Widely adopted profiles that define how Open Badges 3.0, CLR 2.0, and W3C VC should look from an ATS/HRIS standpoint (core fields, skills, levels, expiry, revocation, verification endpoints) would reduce custom mappings for every integration. 2. Simple ingest APIs and reference implementations for major HR platforms Off‑the‑shelf connectors or conformance-tested APIs for Workday, Oracle, SAP, SuccessFactors, and leading ATS platforms would dramatically cut implementation time. Ideally, these would support both real‑time and batch ingestion of standardized credentials. 3. Clear trust and verification models that employers can operationalize Employers need straightforward answers to "Can I trust this?" and "Is it still valid?". Standardized trust registries, status lists, and verification endpoints—abstracted behind simple SDKs—would help HR teams adopt verifiable credentials without becoming crypto or PKI experts. 4. Skills and competency alignment to common taxonomies Credentials that map to widely used skills frameworks (e.g., ESCO, Lightcast, regional frameworks) are much easier for employers to consume. Shared guidance on how to embed and maintain these mappings within OB3/CLR/VC would improve match quality for hiring and internal mobility. 5. Implementation playbooks and governance templates Many employer teams are still at the exploratory stage. Practical playbooks—covering data privacy, consent, retention, AI usage, and bias considerations—would lower risk perceptions and make it easier for HR and legal teams to approve integrations. Brightspace's role is to ensure that learning data, outcomes, and credentials can flow out in these employer‑friendly formats via open standards and well-documented APIs, while allowing institutions and partners to choose the employer systems that work best for them.

Reduce the number of standards—there are too many standards, data models, and schemas

If employer systems adopted a recommended wallet-to-verifier request and presentation protocol. The platforms that do this first will be the easiest to work with.