Accepting Wallet Credentials as a Relying Party

ICB-A07 | For employers, universities and professional bodies that will request wallet credentials.

This course belongs to the ICoBC Credentialing Skills Framework (ICSF), skill IDWL "Digital identity and wallets" (VRITE pillar: Trustworthiness), level L3 "Enable", stage A "Ability". At this level you plan wallet use cases for a programme and specify requirements as an issuer or a relying party. This course takes the relying party view.

A relying party is an organisation that asks a person to present data from a digital identity wallet and then relies on that data to make a decision, for example to hire someone, admit a student or grant a licence.

Who it is for

• HR, talent acquisition and mobility teams (C2)
• HR and learning technology owners (C3)
• Quality, registry and admissions staff (E3)
• Professional bodies and sector associations (P1)

Prerequisite: ICB-F06 Digital Identity and the EUDI Wallet: Essentials.

Learning outcomes

1. Identify use cases where your organisation will request wallet credentials.
2. Specify the minimum data to request and why.
3. Plan registration, technical integration and process changes as a relying party.
4. Explain the acceptance duties for regulated sectors and their timelines.

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

Assessment. You produce a relying party plan for one use case. A trained assessor marks it with the rubric in the section "Assessment and badge". A short knowledge check supports the plan. The file does not grade your plan.

Badge. "Accepting Wallet Credentials as a Relying Party (Ability, L3)", alignment code ICSF-IDWL-L3-A. The badge evidence is your relying party plan.

Quality focus. VRITE Trustworthiness and Value: you build requests that earn trust and that give your organisation a real benefit.

A note on facts. This course describes a fast-moving field. Facts marked "Status: November 2026" can change. Always check the current legal text and national guidance before you act.

Use cases

Where a wallet request fits

A wallet credential is a digital statement about a person, held by that person in a wallet on their own device. The wallet holder decides what to share. As a relying party, you ask for specific data, the holder approves, and your system checks the result.

Start with the decision, not the technology. Ask: which decision in our organisation depends on a fact about a person that we now collect through documents, emails or uploads?

Typical decisions in the two contexts of this course:

Corporate academy or HR department

• Confirming the identity of a new hire before a contract starts.
• Checking a professional qualification claimed in an application.
• Confirming that a candidate holds a right-to-work or residence status for a mobility case.
• Confirming that a contractor holds a safety certificate before site access.

University, college or training provider

• Confirming the identity of an applicant at enrolment.
• Checking a prior qualification for admission.
• Confirming a student's age or enrolment status for a service.
• Verifying a professional licence before a continuing education course for regulated roles.

Each of these decisions currently relies on paper copies, scans or manual checks. A wallet request can replace the copy with a verifiable presentation of data.

Choosing use cases worth the effort

Not every document check needs a wallet. Score each candidate use case on four questions:

1. Volume. How often does the check happen in a year? (Use your own figures.)
2. Risk. What goes wrong if the data is false or stolen?
3. Effort. How much staff time does the current check take?
4. Readiness. Will your applicants or staff hold the credential in a wallet in the near term?

The fourth question matters most in 2026 and 2027. Wallet readiness varies widely between Member States, and holders will only have wallets if their state or another provider offers one.

Status: November 2026.

Acceptance duties and timelines

The EUDI Wallet comes from the revised eIDAS Regulation, often called eIDAS 2.0. The status notes for this course are:

• EUDI Wallet (eIDAS 2.0) [Emerging]. Member States must offer at least one wallet by 24 December 2026. Germany plans its state wallet ("d-you") for 2 January 2027, with basic functions first. Regulated private sectors must accept the wallet about one year after issuance starts. Readiness varies widely between Member States.
• European Business Wallets [Watch]. The Commission proposal is COM(2025) 838 of 19 November 2025. A Council general approach is prepared for June 2026, and Parliament work is ongoing. It is not adopted as of November 2026.

For you, this means:

• If your organisation operates in a regulated sector, you will probably have an acceptance duty. Which sectors are covered, and from which date, depends on the legal text and on national implementation.
• If your organisation is not in a regulated sector, acceptance is a choice. You can still decide to accept wallets where it brings value.
• A business wallet could later support employer and organisation use cases, but it is a proposal only. Treat it as something to watch, not something to plan on.

Status: November 2026.

Worked example and practice

Worked example: Admission check at a training provider

Context: a training provider (a college) runs a part-time programme for healthcare assistants. Applicants must show a prior qualification and confirm their identity.

The registry lead, Maria Okafor, lists the decisions:

Maria's scoring (illustrative numbers): 400 applicants a year, 6 minutes of staff time per identity check, one past case of a forged document. She picks identity at enrolment as the pilot because volume and risk are high and national wallet issuance is close.

Practice activity: Pick a pilot use case

Work on your own organisation, or on one of the two contexts above.

1. List at least five decisions that rely on personal data.
2. Score each on volume, risk, effort and readiness (use High, Medium or Low).
3. Choose one pilot use case and write two sentences that justify it.
4. Write one sentence on whether an acceptance duty may apply to you, and mark what you need to verify.

Keep your result. It becomes section 1 of your relying party plan.

Quiz: Use cases

Data minimisation

Ask for the least data that does the job

Data minimisation means you request only the data you need for a stated purpose. Wallets support this well, because a request can ask for single attributes instead of a whole document.

Compare two ways to check that an applicant is an adult learner:

• Document copy: you receive a full identity card scan with name, address, number, photo and date of birth.
• Wallet request: you ask for one yes or no answer: "is the holder over 18?" You receive only that answer, if the credential and the wallet support it.

The second option reduces risk for the holder and for you. You store less, you can lose less, and you face a smaller compliance burden.

How to define the minimum

For each use case, write a purpose statement, then list data items against it. Use this checklist for every item:

1. Purpose. Which decision needs this item?
2. Necessity. Could the decision be made without it?
3. Form. Do you need the value itself, or only a yes or no answer derived from it?
4. Retention. How long must you keep it, and why?
5. Legal basis. Which basis supports the request? Check with your data protection officer.
6. Alternative. What happens if the holder declines or cannot present it?

Data protection law, in particular the General Data Protection Regulation, sets principles that apply to relying parties, including purpose limitation and data minimisation. Your data protection officer decides how these apply to your case.

Reasons you write down

"And why?" is part of the outcome. A request should carry a reason that the holder can see and that an auditor can read. Write each reason in one plain sentence, for example: "We ask for your family name and date of birth to match your application to your enrolment record."

Good reasons share three features. They name the decision. They are short. They would make sense to the holder without legal training.

Worked example and practice

Worked example: Qualification check in a corporate academy

Context: the corporate academy of a logistics company, run by learning technology owner Samuel Reyes, offers a forklift instructor programme. Instructors must hold a recognised trainer certificate. Today, candidates email a PDF.

Samuel writes the purpose statement: "Confirm that the candidate holds a valid trainer certificate before they start as an instructor."

Samuel decides to keep only the result "valid on the check date" plus the certificate type in the HR record, and to delete the rest after the check. He confirms the retention rule with the data protection officer. (Retention periods here are Samuel's decision for his case, not a general rule.)

Practice activity: Build a minimum data list

Use the pilot use case from module 1.

1. Write one purpose statement.
2. List every data item you would ask for.
3. Apply the six checks to each item. Remove items that fail the necessity check.
4. For each item you keep, write the reason for the holder in one plain sentence.
5. Write what you will do if the holder cannot or will not present a wallet credential.

Keep your result. It becomes section 2 of your relying party plan.

Quiz: Data minimisation

Registration and trust

Why a relying party registers

A wallet holder needs to know who is asking. In the EUDI framework, relying parties are expected to register in their Member State and to declare what data they intend to request. Wallets can then show the holder who is asking and for which data, and can warn about requests that exceed the registered purpose.

Registration is part of the trust model. It turns a request from an unknown party into a request from an identified organisation with declared purposes.

For your plan, treat registration as a work package with an owner, a deadline and inputs.

Inputs you prepare for registration

Collect these inputs well before the registration window opens. Check each one against the rules of your national registrar.

• Legal name and legal form of your organisation.
• Contact details for a responsible person.
• The list of data items you intend to request, per use case.
• The purpose for each use case and the reasons from module 2.
• Privacy information and your data protection contact.
• Evidence of any sector authorisation, if your sector is regulated.

Different use cases may need different registrations or request profiles. Your minimum data list from module 2 is the main input.

Trust, verification and what you must check

When a presentation arrives, your system should check at least:

1. Authenticity. Was the credential issued by the claimed issuer, and has it been altered?
2. Issuer trust. Is the issuer on a list you trust for this type of credential?
3. Validity. Is the credential current, not expired and not revoked?
4. Holder binding. Does the person presenting hold the credential?

Your process decides what happens when a check fails. Define the outcome in advance: retry, fallback route, or manual review.

Timelines for regulated sectors

If you operate in a regulated private sector, plan backwards from the acceptance deadline. The status note says regulated private sectors must accept the wallet about one year after issuance starts. With Member States obliged to offer at least one wallet by 24 December 2026, and Germany planning its state wallet for 2 January 2027 with basic functions first, an organisation that acts in Germany should read these as planning signals. The exact deadline depends on the legal text and national rules, so confirm it for your sector.

Status: November 2026.

A simple backward plan has four checkpoints: registration prepared, technical test passed, staff trained, live acceptance. Add buffer time, because readiness varies widely between Member States.

Worked example and practice

Worked example: Registration plan for a university

Context: a university registry, led by admissions manager Priya Nair, plans to accept wallet identity at enrolment for 2027 entry.

Priya builds a registration work package:

She notes two open points marked "to verify": the registrar's exact process and whether the university needs a separate registration for the admissions office and the library.

Practice activity: Draft a registration and trust work package

Using your pilot use case:

1. List the inputs you must prepare before registration.
2. Assign an owner to each input (a named role).
3. Write the four verification checks your system will make on a received presentation.
4. Define what happens when a check fails (retry, fallback or manual review).
5. If you are in a regulated sector, write a backward timeline from the acceptance deadline, and mark the date to verify.

Keep your result. It becomes section 3 of your relying party plan, together with section 6 on regulated sector duties.

Quiz: Registration and trust

Integration

The technical building blocks

Integration connects your systems to the wallet request and response flow. You do not need to become a protocol expert, but you must specify requirements and test them. The main building blocks are:

1. Request component. Creates a request that asks for the data items you defined, and shows your registered identity.
2. Verification component. Checks the presentation: authenticity, issuer trust, validity, holder binding.
3. Trust list handling. Keeps your list of trusted issuers up to date.
4. Mapping. Converts verified attributes into fields in your own systems, such as an HR system or a student record system.
5. Logging. Records that a check took place, with minimal data, for audit.
6. Fallback. Offers another route when the wallet is not available.

Your plan should name the standards your supplier or internal team must follow, based on the official architecture and reference framework and on national guidance. Use only requirements you have checked.

Build, buy or join

You have three common choices, described here without naming products:

• Build the verification component in your own team. This gives control and needs skills.
• Buy a service from a provider that handles request and verification. This needs a procurement process and contract terms for data protection.
• Join a sector or national service that already offers acceptance for many relying parties. This can reduce effort, and you must check its terms.

Write down which option you choose and why. Use these questions: who runs the verification, where does the data go, who is accountable if a check fails, and what does it cost over three years (use your own figures).

Requirements for suppliers and IT

A short requirements list helps IT and procurement. Write each requirement so it can be tested.

Add requirements for security, accessibility and availability based on your own policies.

Worked example and practice

Worked example: Integration requirements for an HR department

Context: the HR department of a manufacturing company, led by talent acquisition manager Elena Fischer, wants to check a professional qualification for engineering hires.

Elena's team chooses to "join" a sector service if one becomes available and to run a small pilot meanwhile. They write these requirements for their HR system supplier:

• The request asks only for qualification type, issuer and validity status.
• The HR record stores the result "qualification verified on [date]" and the qualification type, not the full credential.
• The trust list is reviewed every month by the HR operations lead. (Interval is the team's own choice.)
• If verification fails, the system creates a task for a recruiter to contact the candidate and offer the fallback route.
• Every check creates a log line with date, use case and result, and no personal values.

The team defines three test cases: a valid credential, an expired credential and a credential from an issuer not on the trust list. The pilot starts only when all three tests behave as written.

Practice activity: Write integration requirements and test cases

For your pilot use case:

1. Choose build, buy or join, and write two reasons.
2. Write at least six testable requirements in a table (requirement and test).
3. Define three test cases, including at least one that must fail.
4. Describe the fallback route in two or three sentences.
5. List the systems that must change (for example HR system, student record system, identity provider) and name an owner for each.

Keep your result. It becomes section 4 of your relying party plan.

Quiz: Integration

Process change

From document handling to wallet handling

A wallet request changes work for people as well as for systems. Map the current process step by step, then redesign it. For each step ask: what happens now, what changes, who does it, and who must be trained?

A typical enrolment or onboarding process has these stages:

1. Invitation. Tell the person which data you will request, and why, before the check.
2. Request. The person starts the wallet request from your portal or from a link.
3. Decision. The person approves or declines in the wallet.
4. Verification. Your system checks the presentation.
5. Outcome. Your staff or system records the result and moves the case on.
6. Fallback. If the wallet route fails or is not available, staff offer an alternative.

People, policy and communication

Plan the following changes:

• Roles. Name an owner for the use case, a data protection contact, an IT contact and a person who handles fallback cases.
• Training. Staff must know what a valid result looks like, what a failure means, and how to explain the request to a person who is unsure. Give staff a short script.
• Policy. Update your privacy notice, your retention schedule and your internal procedure. Decide who may see which data.
• Communication. Write a short message for applicants, students or employees. Use plain language and the reasons from module 2.
• Accessibility and inclusion. Not everyone holds a wallet. Some people lack a suitable device, or need support. The fallback route must be as dignified and as fast as practical.
• Records. Decide what you store, for how long and where.

Keep the human option visible. A relying party that treats the wallet as the only route risks excluding people and may meet legal limits.

Measuring value

The quality focus of this course includes Value. Define a few measures before you start, and use your own baseline.

Review these after the pilot and decide: extend, adjust or stop. Report results to the use case owner and to the data protection officer.

Worked example and practice

Worked example: Process change at a university registry

Context: the registry of a university, under admissions manager Priya Nair, redesigns enrolment for wallet identity.

Current process: applicants upload a passport scan. A clerk compares it with the application and types the result into the student record. This takes about six minutes per case (illustrative).

Redesigned process:

Priya adds a policy change: the passport scan is no longer stored for wallet cases. She asks the data protection officer to confirm the new retention rule. She sets three pilot measures: staff time per check, share completed by wallet, and applicant feedback.

Practice activity: Redesign the process and plan the change

For your pilot use case:

1. Describe the current process in five to seven steps.
2. Redesign it with the wallet route and a fallback route.
3. For each step, name the owner and any training need.
4. List the policy documents you must update.
5. Write a short message to the people who will be asked for wallet data (three to five sentences).
6. Choose three measures of value and describe your baseline.

Keep your result. It becomes section 5 of your relying party plan.

Quiz: Process change

Assessment and badge

The task: relying party plan

You produce a relying party plan for one use case in your own organisation, or in one of the two worked-example contexts (a corporate academy or HR department, or a university, college or training provider). A trained assessor marks the plan with the rubric below. This file does not grade your plan.

Length. About 4 to 8 pages, or an equivalent structured document.

Required sections

1. Use case and decision. The decision, who is affected, why a wallet request adds value, and your selection reasoning (module 1).
2. Minimum data and reasons. Purpose statement, data items, form, reasons shown to the holder, retention (module 2).
3. Registration and trust. Registration inputs, owners, verification checks and failure handling (module 3).
4. Integration. Build, buy or join choice, requirements table, test cases, systems affected (module 4).
5. Process change. Redesigned process, fallback route, roles, training, policy updates, communication, value measures (module 5).
6. Regulated sector duties and timeline. Whether an acceptance duty applies to you, the expected deadline, a backward timeline, and a list of items to verify (modules 1 and 3).

Mark every unverified legal or technical point as "to verify" and name who will verify it and by when. Use illustrative numbers only where you label them as illustrative.

Rubric

Levels: 3 = Meets the standard with strength, 2 = Meets the standard, 1 = Partly meets, 0 = Not shown.

Pass rule. To pass, the plan must score at least 2 on every criterion A to F and at least 2 on criterion G. Criterion H must score at least 1. A plan with a score of 0 on any criterion does not pass. The assessor may ask you to revise and resubmit once.

Knowledge check

The knowledge check supports the plan. Answer all ten questions. The pass mark for the knowledge check is 8 of 10, and it is a condition for the badge together with the plan.

Status: November 2026.

Evidence submitted for the badge

To earn the badge "Accepting Wallet Credentials as a Relying Party (Ability, L3)", alignment code ICSF-IDWL-L3-A, submit:

1. Your relying party plan, with all six sections.
2. A short statement of which items are marked "to verify" and who will verify them.
3. Your knowledge check result (8 of 10 or more).

The assessor marks the plan with the rubric. The badge shows that you completed this course and a plan that met the standard for this task. It does not prove competency in a job.

Sources and further reading

Only sources that exist are listed. No web addresses are given, to avoid errors. Search for the exact titles on the official sites of the bodies named.

Status: November 2026.

• Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS), as amended by Regulation (EU) 2024/1183 establishing the European Digital Identity Framework. Source: EUR-Lex, Official Journal of the European Union.
• Regulation (EU) 2016/679, the General Data Protection Regulation. Source: EUR-Lex, Official Journal of the European Union.
• European Commission, proposal COM(2025) 838 of 19 November 2025 on European Business Wallets. Source: European Commission and EUR-Lex. Status: proposal, not adopted as of November 2026.
• European Digital Identity Wallet Architecture and Reference Framework. Source: European Commission, Digital Strategy website. Check the latest published version.
• ICoBC Credentialing Skills Framework (ICSF), skill IDWL "Digital identity and wallets". Source: ICoBC, info@icobc.net.
• ICB-F06 Digital Identity and the EUDI Wallet: Essentials. Source: ICoBC course library.
• National guidance from the authority responsible for the wallet and for relying party registration in your Member State. Check which body is responsible, and read the current guidance.