Survey questions & data

Full question text, aggregated response data in table form, and write-in responses. Use the summary report for charts and narrative.

Section 1: Platform Context & Role

Q1 Show in report

Which best describes your platform's primary role?

Select all that apply

Response Count %
Credential issuer 35 81%
Credential wallet 21 49%
Credential verifier 17 40%
Credential repository 16 37%
Talent / employer-facing platform 15 35%
Learning platform (LMS, LXP, SIS) 6 14%

Write-in responses (5)

  • "Ecosystem"
  • "Working platform"
  • "College and Career Readiness Platform"
  • "Assessment platform"
  • "Upskilling, End-to-end LER Ecosystem"

Section 1: Platform Context & Role

Q2 Show in report

Which credential formats does your platform currently support?

Select all that apply

Response Count %
Open Badges (v3.0) 32 74%
Open Badges (v2.0) 30 70%
PDF / document-based credentials 20 47%
W3C Verifiable Credentials 19 44%
Comprehensive Learner Record (CLR) Standard™ 13 30%
Proprietary credential formats 8 19%
European Digital Credentials for Learning (EDC) 4 9%

Write-in responses (4)

  • "Blockcerts"
  • "LER-RS"
  • "https://docs.learncard.com/introduction/interoperability"
  • "blockcerts"

Section 1: Platform Context & Role

Q3 Show in report

Which sectors do you primarily serve?

Select all that apply

Response Count %
Higher education 35 81%
Workforce development 31 72%
Corporate training / L&D 22 51%
Employers 22 51%
Learner-facing / consumer 21 49%
K–12 19 44%
Talent management / HR tech 17 40%
Government / licensing 15 35%

Write-in responses (3)

  • "FURTHER EDUCATION"
  • "General purpose W3C VC platform."
  • "Current and Former Military Service Members"

Section 2: Credential Inbound APIs

Q4 Show in report

How does your platform receive credentials from external systems?

Select all that apply

Response Count %
File upload (JSON, PDF, ZIP, etc.) 26 60%
API-based transfer 23 53%
URL-based retrieval 18 42%
Credential wallet connection 16 37%
Manual entry 14 33%
We do not ingest external credentials 9 21%

Write-in responses (5)

  • "DID services"
  • "https://docs.learncard.com/how-to-guides/connect-systems"
  • "One-click Import"
  • "Today Brightspace is more often the source or trigger of credentials, but we do have and expect the above selected methods."
  • "Streamset, batch--whatever is happening in an IHE"

Section 2: Credential Inbound APIs

Q5 Show in report

Which APIs or protocols do you currently use to ingest credentials?

Select all that apply

Response Count %
Open Badges / CLR API 20 47%
W3C Verifiable Credentials API (VC-API / VCALM) 13 30%
Proprietary API (please describe in Other) 11 26%
Credential Handler API (CHAPI) 9 21%
OpenID for Verifiable Presentations (OID4VP) 8 19%
OpenID for Verifiable Credential Issuance (OID4VCI) 5 12%
W3C Digital Credentials API 5 12%
DIDComm 4 9%
Not sure 4 9%

Write-in responses (12)

  • "We don't ingest credentials."
  • "We don't ingest credentials currently"
  • "DID services"
  • "Velocity Networ API"
  • "For DIDComm the ingestion side is handled by https://didcomm.org/issue-credential/3.0/ but you've combined the ingestion with presentation here. For presentation DIDComm uses https://didcomm.org/present-proof/3.0/ I'd have kept the two as different questions."
  • "Our own API generator and that of our assessment vendor CTECS"
  • "Interfacing credential document upload APIs"
  • "NA"
  • "SmartResume Credential Connect API"
  • "We don't ingest credentials"
  • "We do not ingest external credentials"
  • "Partner-specific inbound payloads where they push credential state back into Brightspace."

Section 2: Credential Inbound APIs

Q6 Show in report

If you use an open API or standard for inbound credentials, why did you choose it?

Select up to 3

Response Count %
Alignment with existing standards (e.g., Open Badges, VC) 30 70%
Market adoption / ecosystem support 24 56%
Security and trust model 17 40%
Developer familiarity / ease of implementation 12 28%
Customer or partner requirement 12 28%
Future extensibility 11 26%
Regulatory or compliance reasons 7 16%

Section 2: Credential Inbound APIs

Q7 Show in report

If you use a proprietary API for inbound credentials, what were the primary reasons?

Select all that apply

Response Count %
No suitable open API met our requirements 12 28%
Immature or incomplete standards 11 26%
Customer-specific requirements 10 23%
Speed to market 10 23%
Legacy architecture 5 12%
Performance or scalability concerns 4 9%

Section 3: Credential Outbound APIs

Q8 Show in report

How does your platform enable credentials to be shared externally?

Select all that apply

Response Count %
Downloadable files (JSON, PDF, SVG, PNG, etc.) 36 84%
Shareable links / URLs 34 79%
Social platforms (e.g., LinkedIn) 29 67%
API-based transfer to another platform 25 58%
Direct employer / ATS integration 8 19%

Write-in responses (3)

  • "DID services"
  • "we are just working on direct employer ATS consumption from a web wallet."
  • "API-based transfer and Direct ATS integration are in the works"

Section 3: Credential Outbound APIs

Q9 Show in report

Which APIs or protocols do you use for outbound credential sharing?

Select all that apply

Response Count %
Open Badges API 22 51%
Proprietary API 18 42%
W3C Verifiable Credentials API (VC-API / VCALM) 16 37%
Direct partner integrations (custom) 12 28%
CHAPI 10 23%
OpenID for Verifiable Credential Issuance (OID4VCI) 7 16%
OpenID for Verifiable Presentations (OID4VP) 5 12%

Write-in responses (3)

  • "DID services"
  • "Surprised you didn't include DIDComm here as you did in #5, specifically, https://didcomm.org/present-proof/3.0/"
  • "LER_RS"

Section 3: Credential Outbound APIs

Q10 Show in report

Which downstream systems do you most commonly integrate with?

Select all that apply

Response Count %
Learner wallets 30 70%
Learning platforms 22 51%
Employer platforms 18 42%
Other credential platforms 16 37%
ATS / HRIS systems 15 35%
Government or licensing systems 10 23%
Job boards 8 19%

Write-in responses (5)

  • "Datawarehouses, CRMs, print orgs, ipass"
  • "Unclear, want to share with ATS for higher ed and higher ed wallet systems, but not happening at scale yet"
  • "Gaming systems"
  • "General VC supporting Wallets"
  • "SmartResume"

Section 4: API Decision Drivers & Tradeoffs

Q11 Show in report

What factors most influence your API and transport decisions?

Ranked 1-8, with 1 = most influential

Response Avg rank n
Market demand / customer requests 2.9 43
Interoperability with other platforms 3.3 43
Security and verification requirements 3.7 43
Alignment with existing standards (Open Badges, VC, CLR) 4 43
Ease of implementation 4.8 43
Maturity and stability of the specification 5 43
Employer or HR tech compatibility 6.1 43
Performance / scalability 6.1 43

Section 4: API Decision Drivers & Tradeoffs

Q12 Show in report

What are the biggest challenges you face when exchanging credentials?

Select all that apply

Response Count %
Employer systems not ready to consume credentials 31 72%
Inconsistent data models 26 60%
Lack of agreed-upon APIs 24 56%
Authentication / trust establishment 14 33%
Metadata loss or mismatch 14 33%
Versioning differences across standards 11 26%
Legal or privacy constraints 10 23%

Write-in responses (4)

  • "Limited scope and missing usecase support"
  • "Too much optionality or choice without guidance for implementers. We need to simply choices with patterns based on use case 'families'."
  • "Business need/competitive dynamics. Fundamentally don't understand how/why we get asked to implement other systems' APIs if the FILE/JSON itself contains all the information needed to share the credential"
  • "Slight differences of approach in implementation that create blockers"

Section 4: API Decision Drivers & Tradeoffs

Q13 Show in report

Where do you currently rely on workarounds instead of standards-based APIs?

Select all that apply

Response Count %
Employer integrations 16 37%
We do not rely on workarounds 12 28%
Credential verification 11 26%
Cross-vendor credential exchange 11 26%
ATS / HRIS ingestion 8 19%
Wallet-to-wallet transfer 5 12%

Write-in responses (8)

  • "DID"
  • "Everyone just does or doesn't do their own custom systems"
  • "unsure"
  • "Data normalization"
  • "Different API versioning"
  • "A propietary API is not a workaround. It's an enhancement over the existing solutions. So we don't workaround these issues - we solved for them."
  • "SmartResume"
  • "Issuance/delivery to wallets"

Section 5: Market Sufficiency & Gaps

Q14 Show in report

Are existing credential transport APIs sufficient for today's real-world use cases?

Response Count %
Yes, existing APIs are sufficient 2 5%
Mostly sufficient, with minor gaps 14 33%
Partially sufficient, significant gaps remain 10 23%
No, current APIs do not meet market needs 4 9%
Existing APIs may be sufficient, but market penetration is insufficient 10 23%
Not sure 3 7%

Section 5: Market Sufficiency & Gaps

Q15 Show in report

Which use cases are not well supported by existing APIs today?

Select all that apply

Response Count %
Wallet-to-employer transfer 19 44%
Platform-to-platform exchange 17 40%
Employer verification workflows 16 37%
Trust registry discovery 15 35%
Wallet-to-wallet transfer 13 30%
Issuer-to-wallet transfer 13 30%
Learner-controlled sharing 13 30%
Bulk credential exchange 9 21%
Not applicable 6 14%

Section 5: Market Sufficiency & Gaps

Q16 Show in report

If a new API were created or existing API modified, what should it prioritize?

Select up to 5

Response Count %
Simplicity / ease of adoption 31 72%
Alignment with Open Badges and CLR 23 53%
Strong verification and trust signaling 20 47%
Employer system compatibility 19 44%
Backward compatibility with existing systems 15 35%
Support for selective disclosure 11 26%
Clear conformance profiles 9 21%

Write-in responses (10)

  • "learner choice of identifier"
  • "passkey"
  • "Clear justification why a badge/CLR specific API is required. I feel the correct forums are elsewhere W3C, TrustOverIp, DIF,OpenID"
  • "Adoption. Standards don't matter at all unless big players adopt which will cause little players to adopt."
  • "New APIs should not exist"
  • "I'd be very careful about yet another API or protocol and first emphasize where existing protocols/APIs might be extended to address new use cases or weaknesses in the current systems."
  • "n/a"
  • "But also why do you need another API?"
  • "1) Seamless, positive, easy to use user experiences. 2) Alignment with Open Badges, CLR, and TCP (if TCP isn't a factor we won't use it) 3) Strong verificaton and trust signaling 4) Employer system compatability"
  • "Don't create a new one--use VCALM or OpenID"

Section 5: Market Sufficiency & Gaps

Q17 Show in report

Would your organization adopt a community-recommended standard for OB/CLR consistency?

Response Count %
Yes, immediately 10 23%
Yes, within 12-24 months 1 2%
Possibly, depending on adoption 18 42%
Unlikely 2 5%
No 1 2%
Yes, within 12–24 months 11 26%

Section 6: Forward-Looking Signals

Q18 Show in report

Which emerging standards or approaches are you actively monitoring?

Select all that apply

Response Count %
Open Badges 3.0 38 88%
W3C VC Data Model 28 65%
W3C Verifiable Credentials API (VC-API / VCALM) 22 51%
CLR 2.0 21 49%
Trust registries 18 42%
OpenID for VC 17 40%
Skills graph / competency frameworks 16 37%
Open Badges API 14 33%
OpenID for Verifiable Credential Issuance (OID4VCI) 13 30%
OpenID for Verifiable Presentations (OID4VP) 12 28%
AI-mediated credential interpretation 11 26%
Proprietary API 10 23%
Direct partner integrations (custom) 8 19%
CHAPI 8 19%

Write-in responses (7)

  • "passkey"
  • "Edu API"
  • "KERI ACDCs, KERI, Guardianship Credentials, First Person Credentials, MyTerms, SEDI, renderMethod, Digital Fiduciaries, Personhood Credentials, Privacy Obligation Documents (PODs)"
  • "Trusted Career Profile, many "web3 protocols""
  • "Trusted Career Profile"
  • "European digital Credentials"
  • "DC API"

Section 6: Forward-Looking Signals

Q19 Show in report

What would make it easier for your platform to interoperate with employer systems?

Open response

Open responses (43)

  • "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."
  • "NOT SURE"
  • "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連携機能を実装している。"
  • "VCALM"
  • "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"
  • "N/A"
  • "n/a"
  • "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."
  • "dont know"
  • "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."
  • "n/a"