Open Badges 3.0 and Verifiable Credentials: Hands-on Lab

Issue, inspect, verify and revoke standard credentials in a sandbox.

Course ID: ICB-P07
Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill STND "Standards and interoperability" (VRITE pillar: Trustworthiness), level L2 "Operate", stage A "Ability".

At this level you issue and verify standard credentials with existing tools, and you check conformance with test tools. This is an Ability course: you practise on realistic tasks in a controlled setting, a sandbox, using knowledge you already have from the prerequisite course.

Who this course is for

• HR and learning technology owners who commission or run credential programmes in a corporate academy or HR department.
• Education IT and credential operations staff at universities, colleges and training providers.
• Members of the standards and wallet community who want hands-on experience with the credential formats.

Prerequisite: ICB-F01 Digital Badges and Credentials Essentials.

Learning outcomes

After this course you can:

1. Issue an Open Badges 3.0 credential in a sandbox and inspect its structure.
2. Explain how Open Badges 3.0 relates to the W3C Verifiable Credentials data model.
3. Verify credentials, including status and expiry, with verification and conformance tools.
4. Diagnose common interoperability errors.

Workload and format

The notional workload is 8 hours. This file covers the self-paced part: six modules, each with a short tour of the topic, a worked example, a practice activity and a quiz. Live or workshop elements appear as facilitator notes. You work in a sandbox, so you never touch production keys, real learner data or live registries.

How the course is assessed

You keep a lab record while you work through the modules. The record contains the credential files you issue, export, verify and revoke, plus your diagnostic answers for three faulty samples. A person assesses the lab record with the rubric in the section "Assessment and badge". The final knowledge check in that section is a formative check of your understanding. The file does not grade your lab record.

Badge

When you pass, you receive the badge "Open Badges 3.0 and Verifiable Credentials: Hands-on Lab (Ability, L2)", alignment code ICSF-STND-L2-A. The badge records that you completed the assessed tasks in this course. It does not prove that you are competent in any particular job.

Outcomes, modules and assessment

The lab record

Create a folder called lab-record on your computer. Inside it, make these items as you go:

• issued/: credential files you issue.
• exports/: files you export from the sandbox.
• verification-log.md: your notes on each verification and conformance check.
• diagnostics.md: your answers for the three faulty samples.
• reflection.md: a short note on what you would check before using a tool in production.

Safety rule for the whole lab. Use only sandbox keys and fictional people. Never paste a private key, a real learner record or a production secret into any tool, including an AI assistant.

Data model tour

What you will do in this module

You will look at a credential as structured data. You will name its main parts, place Open Badges 3.0 on the W3C Verifiable Credentials data model, and read a small sample file line by line.

Time: about 75 minutes.

Credentials are data with a purpose

A credential is a set of statements that an issuer makes about a subject. The statements need a shape so that other systems can read them. A shared data model gives that shape. When two systems share a model, a verifier can read a credential from an issuer it has never met.

Open Badges 3.0 is a specification for credentials that describe achievements, such as completing a course, passing an assessment or holding a skill. Comprehensive Learner Record (CLR) 2.0 is a related specification that bundles several achievements into one record. Both are current specifications. Platform support is still uneven, so you should check the conformance certification of any tool before you rely on it.

How Open Badges 3.0 relates to Verifiable Credentials

The W3C Verifiable Credentials Data Model 2.0 is a W3C Recommendation, published in 2025. It defines a general way to express claims, who issued them, who they are about, and how to secure them. It does not say anything about badges, courses or skills. It is a general layer.

Open Badges 3.0 sits on top of that layer. It uses the Verifiable Credentials structure and adds terms that fit achievements: for example an achievement, its criteria, and the result a learner earned. In practice, an Open Badges 3.0 credential is a Verifiable Credential whose subject has an achievement.

The main parts of a credential

Most Open Badges 3.0 credentials contain these parts:

• Context: a list of links that tell a reader which vocabularies the terms come from.
• Type: the kind of credential. It includes a general Verifiable Credential type and an Open Badges type.
• Issuer: the organisation that makes the statement, with an identifier and a name.
• Valid from and valid until: the dates between which the credential is meant to be accepted. The validity end date is optional.
• Credential subject: the person or entity the statements are about, with the achievement they earned.
• Credential status: a pointer that tells a verifier where to check whether the credential is still valid.
• Proof: the digital signature that lets a verifier detect changes.

A short, simplified sample follows. It uses fictional names and shortened identifiers. Real files are longer.

``json
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
],
"type": ["VerifiableCredential", "OpenBadgeCredential"],
"issuer": {
"id": "https://example.org/issuers/1",
"type": ["Profile"],
"name": "Example Academy"
},
"validFrom": "2026-03-01T09:00:00Z",
"credentialSubject": {
"type": ["AchievementSubject"],
"achievement": {
"id": "https://example.org/achievements/42",
"type": ["Achievement"],
"name": "Safe Handling Basics",
"criteria": { "narrative": "Complete the module and pass the quiz." }
}
}
}
``

Worked example: Reading a corporate academy credential

Priya is a learning technology owner in a corporate academy. Her academy wants to issue a credential called "Safe Handling Basics" to staff who finish an internal course. She opens the sample above and annotates it:

1. The issuer is the academy. She checks that the issuer name matches the legal name used in HR records.
2. The subject is the staff member. She notes that a real credential needs a way to identify the person, and that her data protection lead must approve which identifier to use.
3. The achievement has a name and a short criteria statement. She rewrites the criteria in plain language so that a hiring manager in another company can understand it.
4. There is no credentialStatus field. She writes in her notes that production credentials need one, so the academy can revoke a credential if a certificate was issued by mistake.

The example shows that the data model gives her a checklist of decisions, not just a file format.

Worked example: Reading a university credential

Tomás works in credential operations at a university. A department wants to issue a micro-credential for a short course on laboratory safety. He compares the same sample with the department's course description:

1. The achievement name in the file must match the name in the course catalogue.
2. The criteria must state the real pass condition, for example "attend all sessions and pass the practical check".
3. The validity dates need a decision: the department says the safety training expires after three years, so he adds a validity end date.
4. He notes that the issuer identifier must be a stable address under the university's control, because verifiers will use it later.

Practice activity: Annotate the sample

1. Copy the sample JSON into a file called issued/sample-annotated.json in your lab record folder.
2. Add a separate file annotation.md. For each of the seven parts listed above, write one sentence: what it contains in the sample, and who is responsible for its content (the issuer, the platform or the earner).
3. List two fields that a real credential in your own context would need and that the sample leaves out. Give a reason for each.
4. Write a short paragraph (three to five sentences) that explains to a colleague how Open Badges 3.0 relates to the W3C Verifiable Credentials data model. Save it as explanation.md. This paragraph is evidence for outcome 2.

Self-check: your paragraph should mention that Verifiable Credentials is the general layer and Open Badges 3.0 adds achievement terms.

Check your understanding

Issuing in the sandbox

What you will do in this module

You will issue your first Open Badges 3.0 credential in a sandbox, export it and inspect the result. You will compare what you typed into a form with what appears in the file.

Time: about 90 minutes.

What a sandbox is for

A sandbox is a controlled copy of an issuing environment. It uses test keys, test issuers and fictional recipients. Mistakes in a sandbox do not reach real people. Your facilitator or course instructions tell you which sandbox to use. This course names no products, so the steps below are described in general terms that apply to any conforming tool.

Before you start, check three things:

• The sandbox shows that it is a test environment.
• You have a test issuer profile, not a real organisation account.
• You have a fictional recipient identity, such as a made-up email address on a reserved example domain.

The issuing flow

Issuing follows a sequence. Each step has a person or system responsible.

1. The issuer defines the achievement: name, description and criteria.
2. The issuer prepares the credential: it links the achievement to a recipient and sets the validity dates.
3. The issuing system signs the credential with the issuer's key.
4. The issuing system delivers the credential to the recipient, as a file, a link or into a wallet.
5. The recipient stores it and can later share it.

Fields to fill in

Whatever tool you use, expect to supply these items:

• Achievement name: short and specific.
• Description: one or two sentences.
• Criteria: what the earner had to do. Write it so a stranger can judge it.
• Recipient identifier: in the sandbox, a fictional one.
• Dates: valid from, and optionally valid until.
• Issuer details: name and a stable identifier.

Write the criteria with care. Weak criteria such as "Good participation" give a verifier nothing to check. Strong criteria such as "Attend four of five sessions and submit the final task" are checkable.

Inspecting what you issued

After issuing, export the credential as a file. Open it in a plain text editor. Do not trust the tool's preview alone, because the preview may hide fields. Check these points:

• The type list contains both a Verifiable Credential type and an Open Badges type.
• The issuer matches your test issuer.
• The credentialSubject contains the achievement you defined.
• The dates match what you entered, in a standard date and time format.
• A proof section exists, or the file is a signed token that carries the proof inside.

Worked example: A corporate academy issues a compliance credential

Lena is an HR specialist who runs a corporate academy. Each year, staff in the finance team complete an anti-fraud awareness module. Lena sets up a test achievement called "Fraud Awareness 2026" in the sandbox.

She enters criteria: "Complete the online module and score at least 80 per cent in the final check." The 80 per cent figure is illustrative. She sets a validity period of twelve months, because the content is reviewed every year. She issues a credential to a fictional employee, Test Person One, with an example email address.

Then she exports the file and opens it. She finds the validity end date and sees that the tool stored it in a standard format. She also finds that the criteria text appears under the achievement, exactly as she typed it. She adds both observations to her lab record.

Worked example: A training provider issues a course credential

Kofi works in credential operations at a vocational training provider. The provider offers a five-day course on workshop machinery safety. Kofi creates the achievement "Workshop Machinery Safety Certificate" in the sandbox. He sets no validity end date at first, then asks the course lead. The lead says the training should be repeated every two years, so Kofi edits the credential to add an end date.

When Kofi inspects the exported file, he notices that the recipient identifier he typed appears in the file. He raises a note for his data protection officer: in production, an email address in a shared file may reveal more than the earner intends.

Practice activity: Issue and export your first credential

1. In the sandbox, create a test achievement with a name, a description and checkable criteria for a short course in your own context (corporate or education).
2. Issue it to a fictional recipient. Set a valid from date and a valid until date.
3. Export the credential and save it as issued/first-credential.json (or the format your tool provides).
4. Open the file in a text editor. In annotation-issuing.md, list five fields in the file that you did not type into the form, and explain in one sentence what each one is for.
5. Compare the criteria text on screen with the criteria text in the file. Note any differences.

Add the credential file and your notes to the lab record.

Check your understanding

Proofs and keys

What you will do in this module

You will learn what a proof does, how keys relate to an issuer, and how to inspect a proof without exposing a private key. You will also meet the idea of an AI assistant as an optional reading aid, with a clear warning.

Time: about 75 minutes.

What a proof does

A proof is a digital signature attached to a credential. It answers two questions for a verifier:

• Did the issuer really sign this credential?
• Has anything changed since it was signed?

If someone edits a single character in a signed credential, verification fails. The signature is mathematical, so it does not rely on trust in the file's appearance.

Key pairs

Signing uses a pair of keys:

• The private key stays secret with the issuer. It creates signatures.
• The public key is shared openly. Verifiers use it to check signatures.

Anyone can use the public key to check a signature, but only the holder of the private key can make a valid one. This is why a private key must never leave the issuer's secure environment.

Securing mechanisms

The Verifiable Credentials data model separates the credential content from the way it is secured. Several securing mechanisms exist, and the specifications that define them continue to evolve. Two broad styles are common:

• Embedded proof: the signature is a block inside the credential JSON.
• Enveloping proof: the whole credential is wrapped in a signed token, and the verifier unwraps it.

Open Badges 3.0 allows more than one securing approach. A tool may support only some of them. When a verifier rejects a credential, an unsupported securing mechanism is one possible reason. You will meet this again in the Troubleshooting module.

Where the public key comes from

A verifier needs to find the issuer's public key. The credential usually names the key or points to a location, such as a document published by the issuer. If the issuer changes keys, publishes the wrong key or lets the location go offline, verification can fail even though the credential is genuine.

This links to trust. A valid signature shows that the holder of a particular key signed the credential. It does not by itself show that the key belongs to the real organisation. Verifiers therefore also look at how the issuer identifier and key are published, and may consult a registry or a trust list where one exists.

Optional: using an AI assistant to read JSON

An AI assistant can help you read a long JSON file. You may paste a credential into one to ask, "What does this field mean?" This is optional. If you do it, follow these rules:

• Paste only sandbox files with fictional data.
• Never paste a private key, a secret, a password or a token that gives access to an issuing system.
• Remember that an assistant may be wrong. Check its answer against the specification.
• Do not paste real learner records. Under your organisation's data protection rules, doing so may be a breach.

A public credential contains no private keys, but a configuration file, an export from an issuing system or a key file may. Always read a file yourself before sharing it.

Worked example: A corporate academy handles keys

Amira leads learning technology for a corporate academy. The academy's issuing system holds a signing key. A colleague asks Amira to send the "key file" to a contractor who wants to help debug a verification error. Amira refuses to send it. Instead she:

1. Exports a sample credential from the sandbox, which contains only the public parts.
2. Sends the contractor the public key location.
3. Asks the contractor to describe the error message.

The contractor can debug the problem with the public information. Amira records in the academy's procedure that private keys are never shared by email.

Worked example: A university rotates a key

Daniel is in IT at a university. The university plans to replace its signing key after a staff change. He lists the steps:

1. Create the new key pair in a secure environment.
2. Publish the new public key at the issuer's key location, keeping the old public key available so earlier credentials still verify.
3. Switch the issuing system to the new private key.
4. Test by issuing a sandbox credential and verifying it.
5. Record the date of change in the key log.

Daniel notes that removing the old public key would make all earlier credentials fail verification.

Practice activity: Inspect a proof

1. Open the credential file you exported in the previous module.
2. Find the proof, or the signed token if your tool uses an enveloping style. In proof-notes.md, write down: the securing style (embedded or enveloping), the type or algorithm named in the file, and the location or identifier of the public key.
3. Find where the public key is published in the sandbox. Note whether you can open it in a browser or text editor.
4. Write three sentences explaining why a private key must never appear in your lab record.
5. Optional: ask an AI assistant to explain one field of your sandbox credential. Check the answer against the specification. Record what the assistant said and whether it was correct. Include no keys or real data.

Check your understanding

Status, expiry and revocation

What you will do in this module

You will learn how credentials can lose validity: through expiry, revocation or suspension. You will set an expiry date, revoke a sandbox credential and observe how a verifier reports the change.

Time: about 90 minutes.

Why credentials need a life cycle

A signed credential cannot be edited after issue, because any change would break the signature. Yet real situations change. An employee's safety certificate lapses. A university finds that a credential was issued in error. A badge was issued to the wrong person. A credential needs a way to say, after the fact, "do not accept this any more".

Three ideas cover most cases:

• Expiry: the credential carries an end date. After that date, verifiers treat it as no longer valid. The end date is written into the signed credential at issue.
• Revocation: the issuer withdraws the credential. It is no longer valid from that moment, and the withdrawal is permanent.
• Suspension: the issuer pauses the credential. It may become valid again. Not every tool supports suspension.

Expiry in the credential

Valid from and valid until are part of the credential. A verifier compares them with the current date and time. If the current time is before the start or after the end, the verifier reports a problem. Dates therefore need correct formats and sensible time zones. A credential issued with a start date in the future, for example, will fail verification today.

Status lists

Revocation cannot be written into the signed credential, because the credential does not change. Instead, the credential points to a status entry. In a common approach, the issuer publishes a list in which each credential has a position, and each position holds a simple flag. A verifier fetches the list, looks up the credential's position and reads the flag.

The specifications for status lists and securing mechanisms continue to evolve, so tools may differ in what they support. A credential with a status pointer that a verifier cannot read may produce a warning or an error, depending on the tool.

Expiry and revocation together

A verifier may check several things in order:

1. Is the signature valid?
2. Is the current time inside the validity period?
3. What does the status entry say?

A credential can pass step 1 and fail step 2 or 3. A good verification report separates these results, so you can see which one failed. When you read a report, do not stop at "invalid". Find the reason.

Revocation in practice

An issuer revokes a credential when:

• the credential was issued in error;
• the earner no longer meets the conditions, for example after a finding of misconduct under the issuer's policy;
• the issuer's policy says that the credential is withdrawn after a specific event.

A revocation reason may be recorded for the issuer's own purposes. Be careful about what you expose. A public status list should not reveal why a particular person's credential was revoked.

Worked example: An HR department revokes a credential issued in error

Mei works in an HR department. A batch of "Forklift Operator Level 1" credentials was issued to twelve employees on a Monday. On Tuesday she learns that three of them had not passed the practical assessment. The scores are illustrative. She:

1. Identifies the three credentials from the issuing log.
2. Revokes them in the sandbox issuing system.
3. Asks a colleague to verify one of the revoked credentials with a verifier tool.
4. Confirms that the report says the credential is revoked, while the signature is still valid.
5. Writes a short note for the three employees, drafted with the HR lead, explaining the correction.

Mei sees that the signature stays valid after revocation. The status entry carries the withdrawal.

Worked example: A college sets expiry for a first aid certificate

Sofia in credential operations at a college issues first aid certificates. The college's policy states that the certificate is valid for three years. She sets the end date at issue. A year later, the college wants to extend the certificates to four years after a review. Sofia explains to the programme leader that existing credentials cannot be edited, because the end date is part of the signed content. The college can issue new credentials with the new end date, and revoke or let the old ones expire.

Practice activity: Expire and revoke

1. Issue two new sandbox credentials to fictional recipients. For the first, set a valid until date a few minutes in the past, if the sandbox allows it, or a date that your facilitator provides as an expired sample. For the second, set a normal future end date.
2. Export both. Verify both with the sandbox verifier. Record the results in verification-log.md: which checks passed, which failed and the exact message.
3. Revoke the second credential in the sandbox.
4. Verify it again. Record the new result, and the time between revocation and the change in the report.
5. In three to five sentences, explain how the verifier knew the credential was revoked, although the file did not change.

Save the exported files in exports/ and your notes in verification-log.md.

Check your understanding

Verification and conformance

What you will do in this module

You will verify credentials with a verification tool and check files against a conformance test tool. You will learn the difference between the two and how to read their reports.

Time: about 90 minutes.

Two different questions

Verification and conformance answer different questions.

• Verification asks: can I trust this credential now? It checks the signature, the issuer's key, the dates and the status.
• Conformance asks: does this file, or this tool, follow the specification? It checks structure, required fields and behaviour against a test suite.

A credential can pass verification and still be poorly structured. A tool can pass a conformance test and still fail to verify a particular credential, for example because the issuer's key location is offline. You need both views.

What a verifier checks

A typical verification run covers:

1. Structure: the file parses and has the expected types and context.
2. Issuer and key: the issuer identifier resolves and the key can be found.
3. Signature: the proof matches the content and the key.
4. Dates: the credential is within its validity period.
5. Status: the status entry, if present, does not indicate revocation or suspension.

Good tools report each check separately, with a clear message. Treat a single green "valid" tick with care, because it may hide checks that the tool skipped. Look for the details.

What a conformance test tool does

Conformance test tools take a credential, or exercise an issuing or verifying system, and compare behaviour with the specification. Results typically list tests that passed, failed or were skipped. Platform support is still uneven, so conformance certification matters. When you choose a tool, check whether it has been certified against the relevant specification, and read what the certification actually covers: which version, which features and which roles (issuer, verifier or wallet).

Reading a report

When you read a verification or conformance report:

• Note the tool name and version, and the date. Results change over time.
• Write down each check and its result, not only the overall result.
• Treat skipped or "not applicable" checks as open questions.
• Keep the report with your evidence.

Wallets and newer protocols

Wallet protocols and credential formats such as OpenID4VC, SD-JWT VC and ISO mdoc are specified for the EUDI Wallet. They are an emerging area, and tooling and education profiles are still maturing. In this lab you work with Open Badges 3.0 files in a sandbox. You do not need these protocols to complete the lab, but you should know that credentials may reach a wallet through different formats and exchange methods, and that support varies. When a wallet rejects a file that a verifier accepts, a format or protocol difference may be the cause.

Worked example: A corporate academy compares two tools

Jonas is a learning technology owner. His academy plans to buy a new issuing system. He tests two candidate tools in a sandbox with the same credential. For each tool he records:

1. The tool's conformance certification: which specification version and which role it covers.
2. The result of verifying the same exported credential in two independent verifiers.
3. Any differences in the reports.

One tool's credential passes in one verifier but shows a warning in the other, because the second verifier cannot read the status list format. Jonas records the warning and asks the supplier to explain. He does not treat the pass in the first verifier as proof that the credential is portable.

Worked example: A university checks a partner's credentials

Aisha works in credential operations at a university. A partner college sends sample credentials so that the university can accept them for credit transfer. Aisha runs each sample through a verifier and a conformance checker. She finds that all signatures are valid, but the conformance checker flags a missing criteria field on two samples. She reports this to the partner as a structural issue, not a trust issue, and agrees a fix before the university accepts the credentials for credit decisions.

Practice activity: Verify and test conformance

1. Take the two credentials you exported in the previous module: one valid and one revoked, plus the expired sample.
2. Verify each one in the sandbox verifier. If a second verifier is available, verify them there as well.
3. Run the valid credential through the conformance test tool provided for the lab. Record which tests passed, failed or were skipped.
4. In verification-log.md, create a table with the columns Credential, Tool, Check, Result and Message. Fill it in for every check you ran.
5. Write a short paragraph: if the verifier says "valid" and the conformance tool reports one failure, what would you do before accepting the credential in your organisation?

Check your understanding

Troubleshooting

What you will do in this module

You will learn the common reasons why credentials fail to verify or to import into other systems. You will practise a structured diagnostic method and apply it to three faulty samples supplied by your facilitator.

Time: about 90 minutes.

A method for diagnosing errors

Random fixes waste time. Follow the same order each time:

1. Read the message. Copy the exact error text.
2. Locate the layer. Is it the file structure, the proof, the key, the dates, the status or the receiving tool?
3. Check the simple things first. Are there typos, wrong date formats or broken links?
4. Compare with a known good sample. A working credential is a reference.
5. Change one thing at a time and test again.
6. Record the cause and the fix.

Common errors

The table lists frequent problems in the form of symptoms and likely causes. Treat it as a starting point, not a complete list.

Interoperability problems

Interoperability means that credentials work across tools from different makers. Problems appear when one tool supports a feature that another does not, or when one reads an optional field differently. Common patterns:

• A tool produces a valid credential that another tool imports without images or descriptions.
• A verifier does not support a securing mechanism that the issuer uses.
• A wallet expects a different format or exchange protocol from the one the issuer offers.
• Two tools use different versions of the specification or of its context files.

When you meet such a problem, avoid blaming one side. Note the versions, test with a third tool if you can, and report to the issuer or tool maker with the exact steps and the files.

Using an AI assistant when diagnosing

An AI assistant can help you spot a missing comma or explain an error message. Apply the same rules as before: use only sandbox files with fictional data, never share a private key or a secret, and check the answer against the specification or a tool report. An assistant can suggest a wrong fix with confidence. A verifier or conformance tool gives you the check that counts.

Worked example: A corporate academy diagnoses an import failure

Carlos is an HR systems owner. An employee tries to import a credential into a wallet, and the wallet says "unsupported file". Carlos follows the method:

1. He reads the message and records the wallet's version.
2. He verifies the same file in a verifier. It passes, so the file parses and the signature is valid.
3. He compares the securing style with the wallet's documentation and finds that the wallet accepts only one of the two styles that the issuing system can produce.
4. He reconfigures the sandbox issuer to use the supported style, reissues a test credential and imports it successfully.
5. He records the cause as "securing style not supported by receiving wallet" and the fix.

Worked example: A college diagnoses a status error

Nadia works in IT at a college. Verifiers report "status check failed" for new credentials. She checks the status address in a sample and tries to open it in a browser. It returns an error. She finds that the address contains a typo introduced during a recent server move. She corrects the address in the issuing system, reissues test credentials and verifies them. She records that already issued credentials with the wrong address need to be reissued, and flags this to her manager.

Practice activity: Diagnose three faulty samples

1. Open the three faulty sample files supplied by your facilitator (called sample A, sample B and sample C), plus the known good reference.
2. For each sample, run the verifier and, if available, the conformance tool. Copy the exact messages into diagnostics.md.
3. For each sample, answer in the following form:
4. Symptom: what the tool reported.
5. Layer: file structure, context and types, proof, key, dates or status, or receiving tool.
6. Cause: your best explanation, with evidence from the file or tool report.
7. Fix: what the issuer should change, and how you would confirm the fix.
8. Compare each sample with the known good reference to support your explanation.
9. If you use an AI assistant, record what you asked and whether its answer was right. Share no keys and no real data.
10. In reflection.md, write five sentences on what you would check before relying on a new tool in production.

Add diagnostics.md and reflection.md to your lab record.

Check your understanding

Assessment and badge

Overview

Assessment has two parts:

1. Lab record (assessed by a person). You submit the lab record you built through the six modules. An assessor reviews it with the rubric below. This file does not grade it.
2. Final knowledge check (formative). Ten questions in this section help you check your understanding before you submit. They do not replace the lab record.

The lab task

Submit your lab record as one folder or archive containing:

• issued/: the credential files you issued, including your annotated sample.
• exports/: the exported files, including the valid, expired and revoked examples.
• explanation.md: your paragraph on how Open Badges 3.0 relates to the W3C Verifiable Credentials data model.
• proof-notes.md: your notes on the proof, securing style and key location.
• verification-log.md: the table of verification and conformance results, including status and expiry results and the revocation observation.
• diagnostics.md: your answers for the three faulty samples (symptom, layer, cause, fix).
• reflection.md: your note on what to check before production use.

Your record must contain no private keys, no secrets and no real personal data.

Rubric

Each criterion is rated at one of three levels. The assessor records the level and a short comment.

Pass rule

• You pass the lab when every criterion is rated "Meets the standard" or higher, and no criterion is rated "Not yet".
• Criterion 6 is a requirement: if a private key, secret or real personal data appears in your record, the assessor returns it for correction before any other review.
• If you are rated "Not yet" on one or more criteria, you may revise and resubmit the relevant parts.

Evidence submitted for the badge

The lab record, with credential files and diagnostic answers, is the badge evidence. The assessor confirms the result against the rubric. On a pass, you receive the badge "Open Badges 3.0 and Verifiable Credentials: Hands-on Lab (Ability, L2)", alignment code ICSF-STND-L2-A. The badge records completion of the assessed tasks in this course. It does not prove that you are competent in any particular job.

Final knowledge check

Use these questions to check your understanding before you submit your lab record. They cover all four learning outcomes.

Sources and further reading

Status as of November 2026; check before publishing.

The sources below are official texts and bodies. Check each one for the current version and for any changes since this course was written. This file gives no web addresses; search for the exact title on the website of the named body.

• W3C: "Verifiable Credentials Data Model v2.0", W3C Recommendation. The general data model on which Open Badges 3.0 builds. Related W3C specifications for status lists and securing mechanisms continue to evolve; check the W3C technical reports page for the current list.
• 1EdTech Consortium: "Open Badges Specification, Version 3.0". The specification for achievement credentials expressed with the Verifiable Credentials data model. Also see the 1EdTech material on the Comprehensive Learner Record (CLR) Standard, Version 2.0.
• 1EdTech Consortium: the conformance certification information for Open Badges 3.0 and CLR 2.0. Check which versions, roles and products are listed and what each certification covers.
• OpenID Foundation: the OpenID for Verifiable Credentials specifications (OpenID4VC family). Emerging area; tooling and education profiles are still maturing.
• IETF: the SD-JWT and SD-JWT-based Verifiable Credentials specifications. Emerging area; check for the current status of each document.
• ISO/IEC: the standard for mobile driving licences and related mobile documents (ISO/IEC 18013 series), which defines the mdoc format. Emerging in education contexts.
• European Commission: the official pages on the European Digital Identity Wallet (EUDI Wallet) and its architecture and reference framework. Check the current version of the framework.
• ICoBC: "ICoBC Credentialing Skills Framework (ICSF)", for the definition of skill STND "Standards and interoperability" and the VRITE pillars.
• ICoBC: course ICB-F01 "Digital Badges and Credentials Essentials", the prerequisite for this course.