Choosing a Credential Platform Without Lock-in

Vendor-neutral requirements, scoring and contracts.

Course ID: ICB-P09
Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill PLAT "Platforms and integration" (VRITE pillar: Trustworthiness), level L3 "Enable", stage A "Ability".

At this level you select platforms against requirements, integrate them with learning, HR and student systems, and plan exit and data portability. This course lets you practise that capability on realistic cases in a controlled setting.

Who this course is for

• L&D and corporate academy leads
• HR and learning technology owners
• Programme and micro-credential leads
• Education IT and credential operations staff

Prerequisite: ICB-F01 Digital Badges and Credentials Essentials. You should know what a digital badge, an issuer, an earner and a verifier are.

Learning outcomes

After this course you can:

1. Translate programme needs into platform requirements.
2. Evaluate platforms with a weighted, vendor-neutral scorecard.
3. Specify data portability, exit and standards conformance in contracts.
4. Estimate total cost of ownership.

Workload

This is a workshop course with 6 hours of notional learning. This file covers the self-paced part. Live or workshop elements appear as facilitator notes inside each module.

How you are assessed

You produce a requirements set, a scorecard and a recommendation memo for a real or case organisation. A person assesses them with the rubric in "Assessment and badge". The final knowledge check in this file is for your own feedback and is graded automatically. It does not replace the assessed task.

Badge

Successful completion leads to the badge "Choosing a Credential Platform Without Lock-in (Ability, L3)", alignment code ICSF-PLAT-L3-A. The badge records that you completed an assessed practice task. It does not prove competency in any job.

Where each outcome is taught and assessed

The path through the course

The course follows the order in which a real selection runs: needs first, then scoring, then proof, then contract, then cost.

Requirements first

Why needs come before products

Many platform selections start with a demonstration. A seller shows a polished interface, the team likes it, and the requirements are written afterwards to fit what was seen. The result is a list that favours one product and hides the needs the programme actually has.

Start from the programme. A credential platform exists to support decisions: who may earn a badge, who checks the evidence, who sees the result and what the holder can do with it. Every requirement should trace back to one of these needs, or to a duty such as data protection or accessibility.

Write requirements in three steps:

1. Describe the programme. Who earns credentials, how many, how often, from which learning activities, and who relies on them (employers, managers, admissions staff, other providers).
2. Name the jobs the platform must do. Typical jobs are: define credentials, collect and review evidence, issue, share, verify, revoke and reissue, report, and connect to other systems.
3. State each need as a testable requirement. A requirement must be something a person can check with a demonstration, a document or a test.

Good and weak requirements

A weak requirement says "The platform is easy to use." Nobody can fail it. A better requirement says "A programme administrator with no training can issue a badge to a cohort of 200 earners from a spreadsheet in under 30 minutes, using the written guide." You can run that test.

Each requirement needs:

• An identifier, such as R-12, so that the scorecard can refer to it.
• A statement, in one sentence, in plain language.
• A source, such as the programme lead, the data protection officer or the earners.
• A priority: must (the platform fails without it), should (important, with a workaround) or could (a bonus).
• A test: how you will check it.

Requirement families

Group requirements into families so that nothing is missed:

• Credential model: badge types, stacking, expiry, evidence, endorsement.
• Issuing and verification: bulk issue, revocation, public verification page, status checks.
• Integration: learning platform, HR system, student records, single sign-on, programming interfaces.
• Standards and portability: the specifications supported, export of all data, wallet and backpack sharing.
• Trust and governance: security, privacy, accessibility, audit logs, roles, AI features.
• Operations: support, uptime commitments, languages, reporting.
• Commercial: pricing model, term, exit.

Stakeholder interviews and the integration map

Requirements come from people. Talk to programme leads, administrators, earners, IT, data protection staff and the people who will verify credentials. Ask about the last time something went wrong, because failures reveal needs that nobody lists in a workshop.

Also draw an integration map: the systems around the platform, the data that moves between them and the direction of each flow. A badge platform that cannot receive course completions from the learning system, or send verified skills to the HR system, creates manual work for years.

Worked example: A corporate academy writes its requirements

All numbers are illustrative. A corporate academy at a mid-sized manufacturer wants to issue badges for internal safety and leadership programmes. The academy lead, Mira, interviews the safety manager, two team leaders, the HR learning technology owner and the data protection officer.

The safety manager says an expired forklift licence badge must disappear from the manager's dashboard on the expiry date. Mira writes:

• R-04 (must): The platform supports an expiry date per badge and shows expired badges as expired on the public verification page. Test: issue a test badge with an expiry date set to tomorrow and check the page the day after.
• R-11 (must): The platform receives course completions from the learning system without manual upload. Test: complete a test course and check that the badge is issued within one hour.
• R-17 (should): The platform sends earned badges to the HR system as skill records. Test: demonstration with test data.
• R-23 (must): The data protection officer can export and delete one person's data on request within the time set by the company policy. Test: run both actions on a test record.

Mira marks each requirement with its source and keeps a short rationale. When a manager later asks "why must we have R-23?", the answer is written down.

Worked example: A university lists its requirements for micro-credentials

All numbers are illustrative. A university continuing education unit offers short courses to about 3,000 learners a year. The programme lead, Tomás, works with student records, the registrar, the accessibility officer and two academics.

The registrar needs a badge to be linked to the learner's student number without exposing it publicly. Tomás writes:

• R-02 (must): Earners sign in with the university single sign-on and the platform stores a pseudonymous identifier, not the student number, on the public badge. Test: issue to a test account and inspect the public page.
• R-09 (must): Credentials describe the level, workload and assessment method in a structured field. Test: inspect an issued test credential.
• R-14 (must): All earner-facing pages meet the accessibility standard named in university policy. Test: evidence from the supplier plus a check by the accessibility officer.
• R-20 (should): Credentials can be shared to external wallets and professional networks. Test: share a test badge to two external services.

Practice activity: Write ten testable requirements

Choose your case organisation: the corporate academy above, the university above, or a real organisation you know well.

1. Write a three-sentence programme description: who earns, how many, who relies on the credentials.
2. Draw a simple integration map with at least three connected systems.
3. Write ten requirements in the format identifier, statement, source, priority and test. Cover at least five of the seven requirement families.
4. Mark at least three as must and at least two as should.
5. Swap with a partner. Each partner picks two requirements and tries to find a way a platform could "pass" without meeting the real need. Rewrite those requirements until they close the loophole.

Keep your requirements: they form part of your final assessed task.

Check your understanding

The scorecard

Why a weighted scorecard

A scorecard turns many opinions into one comparable result. It forces the team to say what matters most before they see prices or demonstrations. A weighted, vendor-neutral scorecard also leaves a record: you can show a board, an auditor or a bidder how the decision was reached.

A scorecard has four parts:

1. Gate criteria. The must requirements. A platform that fails a gate is not scored further.
2. Weighted criteria. The should and could requirements, grouped into families, each with a weight.
3. A scoring scale with written definitions for each level.
4. Evidence for each score, so that two people reading the same evidence give the same score.

Weights

Weights show relative importance. A simple method: give 100 points to share across the families, then split each family's points among its criteria. The team agrees the weights before any demonstration or price is seen. Changing weights after seeing the results is a common way of producing the answer someone already wanted.

Typical families for a credential platform are credential model, issuing and verification, integration, standards and portability, trust and governance, operations and cost. The weights depend on the organisation. A university with strict accessibility duties may weight governance higher. An academy with a complex HR landscape may weight integration higher.

The scoring scale

Use a short scale with written anchors, for example:

The anchors make the difference between "the seller said so" and "we saw it work". Never award a 3 on a seller's statement alone.

Weighted total and sensitivity

The weighted score for a family is the score divided by the maximum, multiplied by the family weight. Add the families to get a total out of 100.

Then run a sensitivity check: change the weights a little, or change two uncertain scores, and see whether the ranking changes. If the first and second platform swap places after a small change, the scorecard cannot separate them, and the decision should rest on risk, exit terms and cost instead. A scorecard that shows a clear gap under several weightings gives a stronger recommendation.

Keeping the scorecard vendor-neutral

Vendor-neutral means that the criteria describe needs, not features of one product. "Supports bulk issue from a file with at least 500 rows" is neutral. "Has the issuing wizard" is not. Check each criterion with the question: could two quite different products both meet this need in different ways? If not, the criterion probably copies one product.

Also use the same questions, the same data and the same scorers for every candidate. Record who scored what, and ask scorers to declare any contact with a supplier that could create bias.

Worked example: A corporate academy builds and runs its scorecard

All numbers are illustrative. Mira's academy shares 100 points: credential model 15, issuing and verification 15, integration 25, standards and portability 20, trust and governance 15, operations 10. Cost is handled separately in Module 5.

Three candidate platforms, A, B and C, are tested. All pass the gates. In the integration family, which has four criteria worth 6 points each (rounded for the example), platform A scores 3, 2, 2 and 3. Its integration result is (3+2+2+3) / 12 × 25 = 20.8 points. Platform B scores 2, 2, 1 and 1, giving 12.5 points.

Across all families the totals are A 78, B 71, C 74. The sensitivity check raises integration to 30 points and lowers operations to 5. The totals become A 81, B 69, C 73. A stays first, so Mira can say the lead is stable under that change. She also notes that C is only 4 points behind and that C's score for portability rests on seller statements, not tests. She marks it for further testing.

Worked example: A university scores with a panel

All numbers are illustrative. Tomás forms a panel of four: the programme lead, a student records analyst, the accessibility officer and an academic. They agree weights in a first meeting, before any demonstration. Governance receives 25 points because of accessibility and privacy duties.

Each panellist scores alone, in writing, then the panel meets. Where two scores differ by 2 or more points, the panel asks for the evidence. In one case, one scorer gave an accessibility criterion 3 because of a supplier statement, and another gave 1 because of a failed check. The panel records the failed check as the evidence and sets the score to 1. The panel keeps the minutes with the scorecard.

Practice activity: Build and test a scorecard

Use your requirements from Module 1.

1. Mark your gate criteria (must requirements).
2. Group the remaining requirements into families and distribute 100 points. Write one sentence per family explaining its weight.
3. Define your 0 to 3 scale with your own anchors for two of your criteria.
4. Score two imaginary platforms using the figures your facilitator provides, or invent plausible illustrative scores. Compute weighted totals.
5. Run a sensitivity check: move at least 10 points of weight from one family to another. Does the ranking change? Write two sentences on what this tells you.
6. Review each criterion with the question "could two different products meet this need?" Rewrite any criterion that describes one product's feature.

Check your understanding

Standards and portability tests

Why standards matter for lock-in

Lock-in means that leaving a platform costs so much, in money, time or lost data, that you stay even when the platform no longer fits. Standards reduce lock-in because they define how credentials and their data are structured, so another system can read them. They do not remove the risk. A platform may claim support for a standard while storing key data in a private format.

Two current specification families matter for this course.

Open Badges 3.0 and CLR 2.0 [Established]. These are current specifications for describing badges and richer learner records. Platform support is still uneven. Check conformance certification of tools instead of relying on a statement that a platform is "compatible".

W3C Verifiable Credentials Data Model 2.0 [Established]. This is a W3C Recommendation since 2025. Related specifications for status lists and securing mechanisms continue to evolve, so ask suppliers which versions and mechanisms they implement and what their update plans are.

Status: November 2026.

Claims, certification and your own tests

A supplier statement about standards has three possible levels of proof:

1. A claim. "We support the standard." Weakest.
2. A certification or conformance result from the standards body or a recognised test suite, for a named product and version. Stronger. Check the scope: a certification may cover issuing but not importing, or one version but not the current one.
3. Your own test. You issue a credential from the platform, validate it with an independent verifier, and import a credential made elsewhere. Strongest.

The portability tests

Run these tests during the selection, using a trial or sandbox account and test data. Do not use real earner data in a trial unless the contract and a data processing agreement permit it.

1. Export test. Export all credentials, earner records, evidence and issuing history in a bulk export. Check that the export is complete, readable without the supplier's software, and uses open formats.
2. Independent verification test. Take an issued credential and check it with a verifier you do not control, such as a public validator. Does it pass? Does a revoked credential show as revoked?
3. Import test. Import credentials issued by another system. Do they keep their identifiers, issuer information and dates?
4. Identifier test. Look at the credential identifiers and the issuer identity. Are they under your control, for example on your domain, or controlled by the supplier? Identifiers that depend on the supplier's domain can break when you leave.
5. Sharing test. Share a credential to an external wallet or profile. Does the recipient see the same information?
6. Interface test. Use the documented interface to read and write credentials. Is it documented, versioned and available at no extra licence cost?

Reading the AI features

Many platforms now offer AI features, such as suggested skill tags, generated badge descriptions, automated evidence checking or matching earners to jobs. Assess each AI feature against your own AI rules. Ask the supplier:

• Which parts of the process does the feature touch: description, evidence review, decisions about earners?
• Can you switch it off, per feature and per programme?
• Is a person responsible for any decision that affects an earner, and can they see and override the AI output?
• Are earner data or evidence used to train models, by the supplier or by third parties? Can you refuse this?
• Is AI-generated content marked as such?
• Where is data processed and which sub-processors are involved?

Write your own AI rules before the selection, even if they are short. A feature that conflicts with your rules is a gate failure, however attractive it looks.

Worked example: A corporate academy tests portability and an AI feature

All numbers are illustrative. Mira's HR learning technology owner, Daniel, requests a sandbox from the two leading platforms. He issues 20 test credentials from each, runs a bulk export and checks it.

Platform A exports credentials in an open format with evidence files and the issuance log. Daniel validates three of the exported credentials with an independent validator, and all three pass. Platform B exports a spreadsheet with credential names and dates but without the structured credential data. B receives a 1 on the export criterion and a note that a full export "can be requested from support, charged by the hour".

Daniel then checks AI features. Platform A proposes AI-written badge descriptions. The academy's AI rule says that any AI-generated text must be reviewed by a person before publication and that earner evidence must not be used for model training. Platform A allows switching the feature off and a review step, and its terms exclude earner data from training. Platform B's terms are silent on training use. Daniel marks this as an open question and a possible gate failure.

Worked example: A university checks conformance and identifiers

All numbers are illustrative. Tomás's panel asks each supplier for conformance evidence. One supplier supplies a certification entry naming the product version. Another supplies a general statement. The panel scores the first 2 and the second 1.

The student records analyst, Amara, examines the identifiers in the test credentials. In one platform, the issuer identity and credential identifiers sit on the supplier's domain. If the university leaves, old credentials would point to a domain it does not control. In another platform, the university can use its own domain. Amara records this as a high-weight portability criterion and gives the first platform a 0 on it.

Practice activity: Design a portability test plan

For your case organisation:

1. List the six portability tests from this module and write, for each, the exact steps you would run in a sandbox and the evidence you would keep (screenshot, file, log).
2. Add two tests specific to your organisation, for example an integration with your learning system or a language requirement.
3. Write five questions about AI features that match the AI rules you would apply. Write a one-sentence AI rule for each question.
4. Define pass and fail for each test, so that two testers would reach the same result.
5. Decide which tests are gates and which feed the weighted score.

Check your understanding

Contracts and exit

Contracts are part of the product

A platform can score well and still lock you in through its contract. Portability promises made in a demonstration have no force unless they are in the agreement. Exit terms are written while you still have negotiating power, before signature, because after signature the supplier knows that switching is costly.

Involve procurement, legal staff and the data protection officer early. This course does not give legal advice and it does not replace review by qualified legal staff. Clause wording must fit your jurisdiction and your policies.

Clause areas to specify

1. Data ownership and use. The contract states that the customer owns its credential data, earner data and evidence. It limits supplier use of the data to providing the service. It excludes use for model training or marketing unless the customer agrees in writing.

2. Data portability. The contract lists what can be exported (credentials, earner records, evidence files, issuing history, revocation lists, configuration), in which open formats, how often, at what cost and within what time. Self-service export at no extra charge during the term is a sensible requirement.

3. Standards conformance. The contract names the specifications and versions the platform must support, requires the supplier to maintain conformance as versions change and states remedies if it falls out of conformance. Reference the certification or test results shown in the selection.

4. Identifiers and domains. The contract states who controls the issuer identity and credential identifiers, and requires continued resolution or a migration path after the term ends.

5. Exit and transition. The contract defines an exit period, the help the supplier must provide, a full export at the end, a defined point at which the supplier deletes data and a certificate of deletion. It states what happens to the public verification service for previously issued credentials.

6. Service levels and change. The contract defines availability, support response, notice of changes to features, interfaces or pricing and the right to leave without penalty after a major unwelcome change.

7. Security, privacy and sub-processors. The contract names security measures, breach notification times, data locations and sub-processors, and requires notice of changes.

8. AI features. The contract lists AI features in scope, states that they can be switched off, ensures that people remain responsible for decisions about earners and states rules on training use of customer data.

9. Price protection. The contract fixes prices or caps increases for the term and states what happens to charges for volumes above and below the plan.

The exit plan

An exit plan is a short document, written at the start, not at the end. It answers:

• Which data and files must be exported, and who runs the export?
• Which formats and where are they stored?
• How do earners keep access to their credentials?
• Which verifications must keep working, and for how long?
• How do integrations switch to the new platform?
• What is the timeline and who decides?

Worked example: A corporate academy turns tests into clauses

All numbers are illustrative. Daniel's sandbox tests showed that platform B exports only a spreadsheet. The academy wants platform B's integration strengths, so it negotiates instead of rejecting it. Mira and procurement draft these requests:

• The supplier provides a self-service bulk export of credentials, evidence and issuing history in open formats at no extra charge during the term.
• The academy owns all credential and earner data. The supplier may not use it to train models.
• For 12 months after the contract ends, the supplier keeps the public verification pages for issued credentials online, or migrates them to a location named by the academy.
• On notice, the supplier completes a final export within 30 days and certifies deletion within 60 days.

Procurement and legal staff review the wording. If the supplier refuses the export and verification clauses, Mira records this on the scorecard as a major risk and informs the board.

Worked example: A university writes an exit plan

All numbers are illustrative. Tomás and the registrar write a one-page exit plan before signing. It states that the credential identifiers are on a university domain, that a full export is tested every year in a test run with 100 sample credentials and that the university will keep a copy of the public keys or equivalent verification material needed to check old credentials.

The plan names who runs the export (the credential operations analyst, Amara), where the export is stored (a university archive) and how earners are informed (a message and a help page). It adds a rule: earners can download their own credentials at any time during the term, so they never depend only on the platform.

Practice activity: Draft clauses and an exit plan

For your case organisation:

1. Choose five of the nine clause areas. For each, write a one or two sentence clause request in plain language. Link each to a test or a requirement ID.
2. Write a one-page exit plan using the six questions in this module.
3. Identify two clauses where you expect resistance. Write a fallback position for each (for example, an export fee cap instead of a free export) and the minimum you would accept.
4. Mark which clauses are non-negotiable and what you would do if the supplier refuses.
5. Exchange with a partner. The partner acts as the supplier's account manager and objects to two clauses. Practise a calm reply that explains the risk the clause addresses.

Check your understanding

Costing

Total cost of ownership

The licence price is only one part of cost. Total cost of ownership (TCO) is the full cost of running the platform over a chosen period, usually three to five years, including exit. Comparing licence prices alone favours platforms with low entry fees and high extras.

Cost categories

One-off costs

• Selection effort: staff time for requirements, scoring and tests.
• Implementation: configuration, design of credential templates, data migration.
• Integration: building and testing connections to learning, HR and student systems.
• Training: administrators, issuers and support staff.
• Legal and procurement review.

Recurring costs

• Licence or subscription, including volume tiers and extra modules.
• Support and hosting options.
• Interface usage or per-call charges.
• Staff time for operations: issuing, support requests, reporting, updates.
• Maintenance of integrations when connected systems change.
• Compliance work: privacy reviews, accessibility checks, audits.

Exit and risk costs

• Final export, data cleaning and migration to the next platform.
• Parallel running during the transition.
• Re-issuing credentials where identifiers cannot be kept.
• Reputation or trust costs if credentials stop verifying.

Write down which costs are known, which are estimated and which are guesses. Show ranges, not single figures, for uncertain items.

Building the estimate

1. Choose a period, for example five years.
2. Project volumes: earners, credentials issued and administrator numbers per year, with a low, expected and high case.
3. Ask each supplier for a full price sheet, including tiers, extras and increase caps, using the same volume scenarios.
4. Estimate internal staff time using realistic hourly cost, including overheads, set by your finance department.
5. Add exit costs. Platforms with poor portability have higher exit costs, which is the point.
6. Compute the cumulative cost per year and the average cost per credential issued.
7. Test sensitivity: what if volumes double, or prices rise at the contract cap?

Cost can enter the decision in two ways. Either treat it as a gate (a budget ceiling) and a separate comparison, or give it a weight in the scorecard. Whichever you choose, state the rule before you see the prices.

Worked example: A corporate academy compares five-year cost

All numbers are illustrative. Mira compares platforms A and B over five years with an expected volume of 4,000 credentials a year. Amounts are in euros.

Platform B's licence is lower, but its integration, staff time and exit costs are higher. Mira shows the exit estimate as a range: platform B 20,000 to 50,000, because the export is partial and re-issuing might be needed. She adds a sensitivity case where volumes double. Platform A's licence rises by a tier, B's does not, and A's total becomes 190,000 against B's 207,000. The ordering holds, so she includes both cases in her memo.

Worked example: A university costs a pilot and a scale-up

All numbers are illustrative. Tomás plans a pilot of 800 credentials in year one and growth to 3,000 in year three. He asks suppliers to price both scenarios and the price protection cap. One supplier has a low entry price but a steep tier at 2,000 credentials. At year three, its cost per credential is higher than that of a supplier with a flat tier.

Tomás also includes the accessibility officer's time for reviewing earner pages (a recurring cost) and Amara's time for the annual export test. He presents the results as cost per credential issued per year, so the board can compare the pilot and scale-up stages on the same basis. He notes that his estimate for staff time is uncertain and shows it as a range.

Practice activity: Build a five-year TCO comparison

For your case organisation:

1. Choose a period (three or five years) and write low, expected and high volume projections.
2. Create a cost table with at least the categories in this module. Use illustrative figures for two imaginary platforms, and label them as illustrative.
3. Mark each figure as known, estimated or guess. Give ranges for at least three uncertain figures.
4. Calculate the total and the cost per credential issued for the expected case.
5. Run two sensitivity cases: volumes double, and price rises at the contract cap.
6. Write three sentences for the memo: which platform is cheaper over the period, how stable the result is, and which cost item carries the most uncertainty.

Check your understanding

Assessment and badge

The assessed task

You produce three documents for a real or case organisation. A person assesses them with the rubric below. This file does not grade them.

Choose your organisation. Use a real organisation you know, or one of the two cases from the modules (the corporate academy or the university). If you use a real organisation, remove or change confidential details and do not include personal data.

Deliverables

1. Requirements set. At least 20 requirements with identifier, statement, source, priority and test. Include an integration map and at least one requirement each on standards conformance, portability, AI features and exit.
2. Scorecard. Gate criteria, weighted criteria with weights that sum to 100 and a stated reason for each family weight, a scoring scale with anchors, scores for at least three candidate platforms (real or illustrative, described without vendor names), evidence notes, a weighted total and a sensitivity check. Include your portability test plan and the results, real or illustrative.
3. Recommendation memo. Maximum two pages. It states the decision, the reasons, the main risks, the contract clauses you will require (at least five, including data export, standards conformance, identifiers and exit), the exit plan summary and a five-year TCO comparison with ranges and a sensitivity case.

Rules

• Platforms are described by their capabilities and labelled, for example Platform A, B and C, in line with vendor-neutral practice.
• Mark invented figures as illustrative.
• Do not include personal data of earners or staff.
• Do not claim legal accuracy for clauses. Mark the clause list for review by qualified staff.

Rubric

The assessor rates each criterion as Not yet, Meets or Strong.

Pass rule

To earn the badge, the assessor must rate Meets or Strong on all seven criteria, and Strong on at least two. A criterion rated Not yet can be revised once and resubmitted within the period set by the programme. The assessor gives written feedback on each criterion.

Badge evidence

Submit for the badge:

1. The requirements set.
2. The scorecard, including the portability test plan and results.
3. The recommendation memo, including the clause list, exit plan summary and TCO comparison.

The badge "Choosing a Credential Platform Without Lock-in (Ability, L3)", alignment code ICSF-PLAT-L3-A, records that the earner completed an assessed practice task against the rubric. It does not prove competency in any job.

Final knowledge check

This check gives you feedback on the knowledge behind the task. It is not the assessed task and does not decide the badge.

Sources and further reading

Status: November 2026.

The sources below are official texts, standards bodies and framework owners. Check the current versions and addresses before you use them, because specifications and programmes change.

• 1EdTech Consortium, the standards body that publishes the Open Badges and Comprehensive Learner Record (CLR) specifications. Look for Open Badges 3.0, CLR 2.0 and the information on conformance certification of products.
• World Wide Web Consortium (W3C), publisher of the Verifiable Credentials Data Model 2.0 Recommendation and related specifications on securing mechanisms and status lists.
• International Council on Badges and Credentials (ICoBC), publisher of the ICoBC Credentialing Skills Framework (ICSF) and the VRITE quality model, on which this course is aligned.

Time-sensitive facts in this course: the current versions of Open Badges and CLR, the state of conformance certification, the Recommendation status of Verifiable Credentials Data Model 2.0 and the maturity of related specifications. Status: November 2026.