Competency Validation: Credential Technologist

Proof that you run standard-conformant credential technology in live work.

This is a candidate guide for a work-based validation. It is not a course that teaches the topic from the start. It tells you what evidence from live work to collect, how to structure your portfolio, how the manager attestation works and how to prepare for the 45-minute technical discussion.

Who it is for

• HR and learning technology owners (audience C3) who run credential tooling in a corporate academy, an HR department or a learning organisation.
• Education IT and credential operations staff (audience E4) in universities, colleges and training providers.

Framework alignment

The validation sits in the ICoBC Credentialing Skills Framework (ICSF), skill STND "Standards and interoperability", under the VRITE pillar Trustworthiness. The level is L3 "Enable" and the stage is C "Competency".

• Skill at this level: you select standards and profiles for a programme, map data models and resolve interoperability issues.
• Stage definition: you apply the capability in a real context, usually work, with the responsibility of the stated level, over time and with observable effect.

Learning outcomes

1. Show that systems you run issue and verify standard-conformant credentials.
2. Show how you handle status, revocation and incidents.
3. Show integration and data portability decisions you made.

Workload

About 15 hours of candidate preparation and assessment. Most of this time goes into selecting, checking and describing evidence that already exists in your work. You should not need to create new systems for the validation.

Prerequisites

• ICB-P07 Open Badges 3.0 and Verifiable Credentials: Hands-on Lab
• ICB-P09 Choosing a Credential Platform Without Lock-in
• ICB-P11 Running Credential Operations

How it is assessed

• A technical portfolio with conformance results and operations records.
• A manager attestation.
• A 45-minute technical discussion.

Badge

"Competency Validation: Credential Technologist (Competency, L3)". Badge evidence is the portfolio, the attestation and the discussion record. The badge is valid for 3 years.

Focus of this guide

The quality focus is VRITE Trustworthiness. The AI focus is the disclosure of AI use in technical artefacts: if AI tools helped you write a mapping, a script, a policy or a report in your portfolio, you say so.

Completing this guide or passing the validation does not by itself prove competency in a job. The badge records that a panel reviewed your evidence from live work against stated criteria at a point in time.

How the guide is built

Each of the three modules has three parts: guidance, a worked example of good evidence, and a practice activity with a self-check. Two settings recur: a corporate academy (an HR department running credentials for employees and partners) and a university or training provider.

Status of topics

Status as of November 2026; check before publishing.

Portfolio guidance

This module explains what the portfolio is, how to structure it and what the panel expects to see. It prepares you mainly for outcomes 1 and 3.

What the portfolio must show

The portfolio is a technical dossier built from live work. It shows that you, personally, carry out the work described in ICSF skill STND at level L3: you select standards and profiles, map data models and resolve interoperability issues.

The panel looks for three qualities in everything you submit:

• Real: the artefact comes from a system that serves real earners, learners or employees, not from a sandbox built for the validation.
• Yours: your role is clear. A team result is fine, as long as you say what you decided and what you did.
• Over time: the evidence covers weeks or months, not a single afternoon. Stage C asks for application over time with observable effect.

A good portfolio is short and well indexed. Aim for 12 to 20 artefacts, each with a one-paragraph cover note. Quality of selection counts more than volume.

Keep the portfolio in a format the panel can open without special tools: PDF for documents, plain JSON files for sample credentials, and text or CSV exports for logs and conformance results.

The evidence map

The technical evidence map links each outcome to the artefacts that support it. Build your own version of this map before you collect anything. It stops you from collecting 30 documents for outcome 1 and none for outcome 3.

The colours in the graphic are labels for the kind of artefact. Your own artefacts may come from either an employer or an education setting, and many will come from both.

Structure of the portfolio

Use this structure. It is the same for every candidate, which helps the panel to read your work quickly.

1. Cover sheet (one page): name, organisation, role, systems in scope, period covered, and the AI disclosure statement.
2. Role statement (half a page): what you are responsible for, and what others decide.
3. Evidence index (one page): a table listing every artefact with its ID, title, date, outcome supported and the criteria it addresses.
4. Section A, Issue and verify (outcome 1): conformance results, sample credentials, verification evidence.
5. Section B, Status, revocation and incidents (outcome 2): operations records and incident records.
6. Section C, Integration and portability (outcome 3): decision records, data mappings, export tests.
7. Reflection (one page): what you would change in your set-up after this review.
8. Attestation (sent separately by your manager, see below).

The AI disclosure statement

The AI focus of this validation is the disclosure of AI use in technical artefacts. On your cover sheet, state whether AI tools were used in preparing any artefact. For each artefact where they were, say:

• what the tool was used for, for example drafting a field mapping table or summarising a log;
• what you checked or changed yourself;
• who is accountable for the final content, which is you.

If you used no AI tools, write that in one line. A missing statement is treated as an incomplete portfolio, because the panel cannot judge trustworthiness without it.

Confidentiality and data protection

Your artefacts will contain real data. Before submitting, remove or pseudonymise personal data of earners and colleagues. Replace names, email addresses and identifiers with consistent placeholders such as "Earner A". Black out internal URLs and credentials. Tell the panel in the cover note what you changed. Check your organisation's rules before you share anything, and ask for written permission where needed.

Worked example: A portfolio index from a corporate academy

Maria Keller is the learning technology owner in the HR department of a mid-sized company. The numbers below are illustrative. She runs a credential service for internal training and for partner suppliers. Her evidence index begins like this:

Why this is good evidence: every item has a date, belongs to live work, names the outcome it supports and can be checked by the panel. The index shows a spread over seven months, so the panel sees application over time. Maria's cover sheet adds that AI tools helped her draft the layout of mapping table C2, and that she checked every row against the source system.

Practice activity: Draft your evidence index

Time: about 90 minutes.

1. List every system you run or help run that issues or verifies credentials. Note your role for each.
2. For each learning outcome, list up to six possible artefacts from the last 12 months. Do not worry about quality yet.
3. Build a table with the columns ID, Artefact, Date, Outcome, Criteria. Use the criteria table in "Assessment and badge" to fill the last column.
4. Mark any outcome that has fewer than three artefacts. Plan what you will collect to fill the gap.
5. Draft your AI disclosure statement, even if it only says that you used no AI tools.

Self-check: Portfolio guidance

Selecting evidence

This module explains which artefacts best show each outcome, how to judge their quality and how the manager attestation works. It prepares you for outcomes 1 and 2 above all, and it supports outcome 3.

Evidence for outcome 1: issue and verify to the standards

The panel wants to see that the systems you run produce credentials that meet the current standards, and that they are checked in practice. Strong evidence for this outcome includes:

• Conformance results. Output from a conformance or validation test for your issuing service, with the date, the tool or test suite named in neutral terms, the version of the specification tested and the result. Include failed tests and what you did about them.
• Sample credentials. Two or three redacted credentials, in their native data format, that represent different credential types. Open Badges 3.0 credentials and CLR 2.0 records are the current specifications for badges and learner records. W3C Verifiable Credentials Data Model 2.0 has been a W3C Recommendation since 2025.
• Verification evidence. Logs or records showing that credentials were verified by someone other than the issuing system, for example an employer or a partner institution, with outcomes.
• Tool conformance information. Platform support for the standards is still uneven. Show that you checked the conformance certification of the tools you use, and note what is certified and what is not.

Related specifications for status lists and securing mechanisms continue to evolve. Where your set-up depends on them, record the exact version or draft you used and the date you checked it. Do not claim conformance to a specification version you did not test.

Evidence for outcome 2: status, revocation and incidents

This outcome is about what happens after issuing. Good evidence shows that you run the lifecycle of a credential, not only its first day.

• Status and revocation records. An extract from your revocation or suspension log covering several months: the credential, the reason category, the date of the request, the date of the action and who approved it.
• Policy or procedure. The rule your organisation follows for revocation, with your role in it. A short, current document is enough.
• Incident record. One or two real incidents, for example an expired signing key, a verification failure after a platform update or an issuing error that affected many earners. For each: timeline, impact, how earners and verifiers were informed, the fix and the follow-up.
• Monitoring. A sample of the checks you run, for example key expiry reminders or verification failure reports.

The panel values honest incident records. An incident with a clear cause, a clear fix and a lesson learned is stronger evidence than a claim that nothing ever went wrong.

Evidence for outcome 3: integration and portability

This outcome asks for decisions you made, not only systems you operate. The panel wants to know why.

• Decision records. A short record of a real choice, for example which profile to use for a programme, or whether to integrate the credential service with the HR or student record system. Include the options you considered, the criteria, the decision and the date.
• Data mappings. A table showing how fields in a source system map to fields in the credential data model, with notes on gaps and workarounds.
• Portability tests. Evidence that earners and your organisation can take data out: an export of issued credentials, a re-import or verification in another system, or a documented exit plan.
• Interoperability issues you resolved. One case in which two systems did not work together, with diagnosis and resolution.

Wallets are an emerging topic. Member States must offer at least one EUDI Wallet by 24 December 2026, Germany plans its state wallet for 2 January 2027 with basic functions first, and regulated private sectors must accept the wallet about one year after issuance starts. Readiness varies widely between Member States. If you made a decision with wallets in mind, record what you assumed and what you will recheck. If you have made no wallet decision yet, do not invent one: say so, and explain how your portability evidence prepares you.

Status as of November 2026; check before publishing.

Judging the quality of an artefact

Before you add an artefact, ask five questions:

1. Authentic: does it come from live work?
2. Dated: can the panel see when it was created?
3. Attributable: is your role clear?
4. Relevant: does it show something specific in the criteria table?
5. Checkable: could the panel ask you about it and expect a detailed answer?

The manager attestation

The manager attestation is a short statement from a person who supervises or sponsors your work and can confirm that the portfolio reflects live work. It is not a reference letter and it does not replace the evidence.

How it works:

1. You choose the attester. This is usually your line manager, programme owner or head of department. If no suitable manager exists, ask a senior colleague who has seen your work over time and tell the panel why.
2. You brief them. Share the outcomes, the criteria table and your evidence index. Ask them to read the artefacts they are asked to confirm.
3. They write and send it themselves. The attester sends the attestation directly to the panel, not through you. This protects its independence.
4. It covers four points. The relationship and the period they have known your work, the systems and responsibilities you hold, confirmation that the artefacts are from live work and that you did what you describe, and any limits, for example decisions made by others.
5. It states no more than they know. A good attester says what they have seen and what they have not.

Worked example: An incident record from a university

Dr Samira Haddad leads credential operations at a university. The numbers below are illustrative. Her incident record covers a failure that affected graduates during a busy summer:

• Summary: after a platform update, 410 degree-related credentials failed verification at two partner employers.
• Detection: a verifier reported the problem on day 1; Samira confirmed it with a test verification the same morning.
• Cause: the update changed how the signing key reference was published. Samira compared the credential against the data model and located the changed reference.
• Resolution: the provider corrected the reference within two days. Samira re-verified a sample of 30 credentials from each batch and recorded the results.
• Communication: a message to graduates and verifiers on day 2 and a closing note on day 4.
• Follow-up: a post-update verification test was added to the change procedure, and the supplier agreement was amended to require advance notice of changes to key references.
• AI disclosure: Samira used an AI tool to tidy the timeline wording and confirmed every date from the system logs.

Why this is good evidence: it shows detection, diagnosis against the standard, communication, resolution and a lasting change in the procedure. It also shows Samira's own part and an honest account of the supplier's role.

Practice activity: Choose and assess three artefacts

Time: about 2 hours.

1. For each outcome, pick the single strongest artefact from your list.
2. Apply the five quality questions (authentic, dated, attributable, relevant, checkable). Write one sentence for each answer.
3. Replace any artefact that fails two or more questions.
4. Draft the cover note for each artefact in five lines: what it is, when, your role, which outcome and criteria, what you changed for confidentiality.
5. Write the briefing email to your attester. List what you want them to confirm and attach the evidence index.

Self-check: Selecting evidence

Preparing for the technical discussion

This module explains the 45-minute technical discussion and how to prepare for it. It brings together all three outcomes, with a particular focus on outcomes 2 and 3.

What the discussion is

The technical discussion is a conversation between you and one or two panel members who have read your portfolio. It takes 45 minutes. It is not an exam on definitions. The panel wants to understand what you did, why you did it and how you think about problems.

The discussion checks three things:

• Authenticity: you can talk about your evidence in detail, because you did the work.
• Judgement: you explain choices and trade-offs, and you know the limits of your solution.
• Trustworthiness: you are honest about what went wrong, what you do not know and how you used AI tools.

A suggested shape for the 45 minutes

The exact running order is set by the panel. This shape is typical.

Questions to expect

You cannot predict every question, but you can prepare for the kinds of question the panel will ask.

On issuing and verification (outcome 1)

• Which specification versions do your systems support, and how do you know?
• Show me a credential from your portfolio. Which fields are required, and which did you add?
• How did you check conformance? What did the tool not cover?
• How can someone outside your organisation verify this credential?

On status, revocation and incidents (outcome 2)

• When do you revoke and when do you suspend or reissue? Who decides?
• Walk me through your incident. When did you know? What did you tell earners?
• What would you do if a signing key were compromised?
• How do you test that status information is still reachable?

On integration and portability (outcome 3)

• Why did you choose this profile? What else did you consider?
• Where do your mappings lose information, and how do you handle that?
• If you changed platform tomorrow, what would an earner keep?
• How do wallets affect your plans, and what would you recheck before acting?

On AI use and trustworthiness

• Which artefacts did you prepare with AI support? What did you verify yourself?
• Where would you not use AI for a technical artefact, and why?

How to answer well

• Start with your role. Say "I decided" or "I ran" when you did, and "the team decided" when you did not.
• Use the artefact. Point to the log line, the field or the table row. Panels like specifics.
• Name the limit. Say what your solution does not cover. This shows judgement.
• Be honest about the emerging. For topics marked Emerging, such as the EUDI Wallet, say what is known, what is planned and what you will recheck. Do not present plans as facts.
• Ask for clarification. If a question is unclear, restate it before answering.
• Do not guess. "I do not know, and this is how I would find out" is an acceptable answer. An invented answer is not.

Practical preparation

• Re-read your portfolio the day before, with the criteria table next to it.
• Prepare a one-page note of the main facts: systems, versions, dates, numbers. You may use it if the panel allows notes.
• Test your video link, audio and screen sharing. Have the artefacts open in a folder.
• Prepare a 3-minute overview of your role and systems for the opening.
• Plan a quiet place and a short break before the discussion.

Worked example: A strong answer on a portability decision

Panel question to Jonas Reiter, a head of training operations at a vocational training provider: "If you changed platform tomorrow, what would an earner keep?"

Jonas answers, using his portability test (artefact C3 in his index):

"Earners keep every credential they have already collected, because each one is signed and verifiable on its own. In March, I ran a full export of 1,200 issued credentials (an illustrative figure from our test) and verified a sample of 50 in a second environment. 47 verified without change. Three failed because the issuer identifier pointed to a path that only exists on our current platform. I recorded that as a risk and agreed with our IT team to host the issuer identifier on a domain we control. Earners would lose two things: the badge gallery pages on the current platform, and the analytics on how often employers view them. I put both in the exit plan. I have not yet tested wallet import. Wallet readiness varies between Member States and I will recheck the position when the national wallet is available."

Why this is a strong answer: Jonas refers to a real test, gives numbers, names the three failures and their cause, states what was lost and what he did about it, and is honest about what he has not tested. He does not claim more about wallets than he knows.

Practice activity: Rehearse the discussion

Time: about 3 hours including a peer session.

1. Write answers of no more than 90 seconds to one question from each group above, using your own artefacts.
2. Prepare your failure story in five parts: cause, impact, fix, lesson, change made.
3. Arrange a 45-minute mock discussion with a peer or mentor who has read your evidence index. Ask them to play the panel, using the questions above and two scenarios of their own.
4. After the mock, note three answers that were vague and rewrite them with a specific artefact reference.
5. Check your AI disclosure statement again and prepare a clear answer on what you verified yourself.

Self-check: Preparing for the technical discussion

Assessment and badge

The task

The validation has three parts. All three must be completed within your validation window, which the panel confirms in your candidate agreement.

1. Technical portfolio. Submit the portfolio described in "Portfolio guidance", with conformance results, sample credentials, operations records, decision records and the AI disclosure statement.
2. Manager attestation. Your attester sends the attestation directly to the panel.
3. Technical discussion. A 45-minute conversation with the panel, based on your portfolio.

In addition, complete the final knowledge check below. It helps you confirm that you can state the core points before the discussion. It does not replace any of the three parts above.

Assessment criteria

Each criterion is rated as Not yet met, Met or Strongly met. The panel rates the combined evidence from the portfolio, the attestation and the discussion.

Pass rule

• You pass when every criterion C1 to C8 is rated at least Met.
• At least two of the criteria C1 to C6 must be rated Strongly met.
• The attestation must be received and must confirm that the evidence is from live work.
• The AI disclosure statement must be complete.
• If a criterion is rated Not yet met, the panel states which evidence is missing. You may resubmit within the period set in the candidate agreement.

Self-check against the criteria

Before you submit, answer each question with yes or no. Any "no" shows work to do.

• [ ] My evidence index lists every artefact with date, outcome and criteria.
• [ ] Every artefact comes from live work and names my role.
• [ ] I have conformance results and at least two sample credentials with the specification version stated.
• [ ] I have verification evidence from beyond my own system.
• [ ] I have a revocation log extract over several months and a procedure.
• [ ] I have at least one real incident record with a lasting follow-up.
• [ ] I have at least one decision record and one data mapping with gaps noted.
• [ ] I have an export or exit test and I can state what is lost.
• [ ] I have briefed my attester, and the attester will send the attestation directly.
• [ ] My AI disclosure statement is on the cover sheet.
• [ ] I removed or pseudonymised personal data and have permission to share.
• [ ] I can answer questions on EUDI Wallet plans without over-claiming.

Final knowledge check

Evidence submitted for the badge

The badge "Competency Validation: Credential Technologist (Competency, L3)", alignment code ICSF-STND-L3-C, is awarded on the basis of three pieces of evidence:

1. Portfolio: your technical portfolio, including conformance results, operations records, decision records and the AI disclosure statement.
2. Attestation: the manager attestation received by the panel.
3. Discussion record: the panel's record of the 45-minute technical discussion and its ratings against criteria C1 to C8.

The badge is valid for 3 years. It records that a panel reviewed evidence from live work against stated criteria. It does not state that the holder is competent in any particular job. After three years, you can renew by submitting new evidence from your current work.

Sources and further reading

Status as of November 2026; check before publishing.

Only official texts and framework owners are listed. Check the current version and publication status of each before you rely on it.

• 1EdTech Consortium: Open Badges 3.0 specification and Comprehensive Learner Record (CLR) 2.0 specification, with their conformance and certification information. Search the 1EdTech Consortium website for the current documents.
• World Wide Web Consortium (W3C): Verifiable Credentials Data Model 2.0, W3C Recommendation. Search the W3C website, technical reports section, for the current text and for related work on status lists and securing mechanisms.
• European Union: Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183 (eIDAS 2.0), establishing the European Digital Identity Framework. Search EUR-Lex for the consolidated text.
• European Commission: information on the European Digital Identity Wallet and its implementing acts and the architecture and reference framework. Search the European Commission website for current information.
• German federal government: official information on the planned German state wallet. Search the websites of the responsible federal ministries for current statements.
• ICoBC: ICoBC Credentialing Skills Framework (ICSF), skill STND "Standards and interoperability", and the ICoBC validation rules and candidate agreement. Available from ICoBC, info@icobc.net.