# Accepting Wallet Credentials as a Relying Party **ICB-A07** | For employers, universities and professional bodies that will request wallet credentials. ## About this course 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. | Outcome | Module | How it is assessed | |---|---|---| | 1. Identify use cases where your organisation will request wallet credentials | Use cases | Practice activity, quiz, section 1 of the relying party plan, knowledge check | | 2. Specify the minimum data to request and why | Data minimisation | Practice activity, quiz, section 2 of the relying party plan, knowledge check | | 3. Plan registration, technical integration and process changes as a relying party | Registration and trust; Integration; Process change | Practice activities, quizzes, sections 3 to 5 of the relying party plan, knowledge check | | 4. Explain the acceptance duties for regulated sectors and their timelines | Use cases; Registration and trust | Practice activity, quiz, section 6 of the relying party plan, knowledge check | > **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.
Facilitator notes **Workshop outline (6 hours notional learning, about 2 hours self-paced in this file).** - Before the workshop: participants read the "About this course" section and complete module 1. - Live session part 1 (90 minutes): use case clinic. Participants bring one real use case from their organisation. - Live session part 2 (90 minutes): minimum data and trust. Pairs review each other's data lists. - Live session part 3 (60 minutes): integration and process change walk-through with an IT colleague if possible. - After the workshop: participants finish the relying party plan and submit it for assessment. Ask participants to name the organisation and the use case in advance. Mixed groups of employers and education providers work well, because the two worked-example contexts then appear side by side.
## 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.** Use case selection funnel Four steps narrow a list of document checks into wallet use cases: list decisions, score volume and risk, check holder readiness, and choose one pilot use case. Each step has a label and a short note. 1. List decisions that rely on personal data Hiring, admission, licence checks, site access 2. Score volume, risk and effort Use your own figures 3. Check holder readiness Will your people hold the credential? 4. Choose one pilot use case Start small, learn, then extend Orange: employers. Cyan: education. Lime: policy and the chosen outcome. ### 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: | Decision | Current method | Wallet candidate? | Reason | |---|---|---|---| | Confirm identity at enrolment | Passport scan by email | Yes | High risk, high volume | | Check prior qualification | PDF diploma upload | Yes, later | Depends on issuers offering wallet credentials | | Confirm age for adult learner fee | Date of birth typed in form | Yes | Low data need, easy win | | Check language level | Test taken on site | No | Result is produced by the college itself | 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.
Facilitator notes Run this activity as a use case clinic. Give each participant 15 minutes to list and score, then 15 minutes in pairs to challenge each other: "Which of these would you still do if the wallet were not available?" Collect common regulated-sector questions on a flipchart and note which ones need legal advice. Remind participants that scores are judgement calls and should use their own numbers.
### Quiz: Use cases **Question 1.** What should you identify first when you look for wallet use cases? [( )] The wallet products available on the market [(X)] A decision in your organisation that depends on a fact about a person [( )] The cheapest software for scanning documents [( )] The number of staff in your IT department **** You start with the decision, such as hiring or admission, and the fact it relies on. Technology choices follow from that. **** **Question 2.** Which factor decides most strongly whether a wallet use case can start in 2026 or 2027? [( )] The colour scheme of the wallet app [( )] The number of pages in your current form [(X)] Whether your applicants or staff will actually hold the needed credential in a wallet [( )] The size of your marketing budget **** A request only works if the holder can answer it. Readiness of holders and issuers varies widely between Member States. **** **Question 3.** Your organisation is in a regulated private sector. What is the best summary of the acceptance duty? [( )] No duty exists until the European Business Wallet is adopted [( )] The duty applies on the same day for all sectors in all Member States [(X)] Regulated private sectors must accept the wallet about one year after issuance starts, and you must verify the exact scope and dates [( )] The duty applies only to public bodies **** The status note says regulated private sectors must accept the wallet about one year after issuance starts. Scope and dates depend on the legal text and national implementation, so check them. **** **Question 4.** What is the status of the European Business Wallets proposal in this course? [( )] Adopted and in force [( )] Withdrawn by the Commission [(X)] A proposal (COM(2025) 838) that is not adopted as of November 2026 [( )] Replaced by the EUDI Wallet **** The proposal is on the Watch list. Do not plan on it as if it were in force. **** ## 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. Minimum data checklist A checklist with six questions a relying party asks about every requested data item: purpose, necessity, form, retention, legal basis and alternative. A navy circle in the centre stands for the holder, with the six checks arranged around it. Holder decides 1. Purpose 2. Necessity 3. Form 4. Retention 5. Legal basis 6. Alternative ### 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." | Data item | Needed? | Form | Reason shown to holder | |---|---|---|---| | Certificate type | Yes | Value | "To confirm you hold the required trainer certificate" | | Issuing body | Yes | Value | "To confirm the certificate is from a recognised issuer" | | Expiry date | Yes | Yes or no: still valid | "To confirm the certificate is valid today" | | Date of birth | No | Not requested | Not needed for this decision | | Home address | No | Not requested | Not needed for this decision | | Full name | Yes | Value | "To match the certificate to your contract" | 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.
Facilitator notes Pair participants and ask them to play the holder. The holder reads each reason aloud and says whether it is clear and fair. Encourage participants to challenge any item that exists "because we always ask for it". Note that legal basis and retention must be confirmed by the data protection officer, so participants should mark open points rather than invent answers.
### Quiz: Data minimisation **Question 1.** What does data minimisation mean for a relying party? [( )] Collecting as much data as possible in case it is useful later [(X)] Requesting only the data needed for a stated purpose [( )] Encrypting all data and keeping it forever [( )] Asking the holder to choose any data they like **** Minimisation links every requested item to a purpose and a decision. **** **Question 2.** You only need to know whether an applicant is over 18. Which request fits the principle best? [( )] The full identity card image [( )] Name, address and date of birth [(X)] A yes or no answer to "over 18", if the credential and the wallet support it [( )] A photograph of the applicant **** A derived attribute gives the answer without the underlying data. Verify that your target credentials support it. **** **Question 3.** Which item belongs in a good reason shown to the holder? [( )] A reference to an internal project code [( )] A long legal paragraph [(X)] A short plain sentence that names the decision the data supports [( )] A note that the holder has no choice **** Reasons should be short, name the decision, and make sense without legal training. **** **Question 4.** What should a plan state for a holder who cannot present a wallet credential? [( )] Nothing, because wallets will be mandatory for everyone [(X)] An alternative route to complete the check [( )] A refusal of service [( )] A request for twice as much data **** An alternative path protects fairness and access, and it supports trust in the process. **** ## 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. Request and response flow between relying party and wallet Five numbered steps between a relying party on the left, a holder wallet in the centre and a registry and issuer trust list on the right. The relying party sends a request, the wallet checks registration, the holder approves, the wallet returns a presentation, and the relying party verifies it. Relying party Employer, university, professional body Holder wallet Shows who asks and why Holder approves or declines Trust sources Registration of the relying party; issuer trust lists 1 2 3 4 5 3: Holder approves the request 5: Verify authenticity, issuer, validity 1: Request with declared purpose. 2: Wallet checks registration. 4: Wallet returns presentation. ### 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: | Item | Owner | Input needed | Due (illustrative) | |---|---|---|---| | Legal entity details | Registry | Legal name, legal form | Month 1 | | Declared data list | Registry and data protection officer | Minimum data list for enrolment | Month 1 | | Purpose and reasons text | Registry | Short plain sentences | Month 2 | | Privacy notice update | Data protection officer | New wording for wallet use | Month 2 | | Submission to national registrar | Registry | All inputs, after checking process | Month 3 | | Test with sandbox wallet | IT | Technical profile | Month 4 | 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.
Facilitator notes Invite a participant who works in a regulated sector to describe their expected deadline. Use it to show how uncertainty is handled: write the assumption, mark it for verification, and set a date by which it must be confirmed. If a national registrar has published guidance by the time you run the workshop, bring it and compare it with participants' assumptions. Do not present unverified details as facts.
### Quiz: Registration and trust **Question 1.** Why does a relying party register and declare the data it intends to request? [( )] To avoid paying for software [(X)] So holders can see who is asking and for which data, which supports trust [( )] To receive credentials without holder approval [( )] To skip data protection rules **** Registration identifies the organisation and its declared purposes. The holder keeps the decision. **** **Question 2.** Which set lists checks a relying party should make on a received presentation? [( )] Colour, file size and language [( )] Name, address and phone number [(X)] Authenticity, issuer trust, validity and holder binding [( )] Age, nationality and employment history **** These four checks cover whether the data is genuine, from a trusted source, current and presented by its holder. **** **Question 3.** An organisation in a regulated private sector wants to plan its acceptance date. What is the sound approach? [( )] Wait until the Business Wallet proposal is adopted [( )] Assume the deadline is the same in every sector [(X)] Plan backwards from the legal deadline for the sector, mark assumptions to verify, and add buffer [( )] Accept wallets only after all Member States have identical readiness **** The status notes say regulated sectors must accept about one year after issuance starts and that readiness varies. Verify sector and national details. **** **Question 4.** What is a good definition of a registration work package? [( )] A list of competitors [(X)] A plan with named owners, inputs and deadlines for registering as a relying party [( )] A software licence [( )] A marketing campaign for the wallet **** Treat registration as a managed piece of work with owners, inputs and dates. **** ## 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. | Requirement | Test | |---|---| | Request only the agreed data items | Inspect a sample request | | Show registered organisation name to the holder | Check in a test wallet | | Verify authenticity, issuer, validity, holder binding | Run test credentials that pass and fail | | Store only the agreed result and fields | Review stored record | | Log each check without storing extra personal data | Review log format | | Offer a fallback route | Run a scenario with no wallet | | Update trust lists on a defined schedule | Check update procedure | Add requirements for security, accessibility and availability based on your own policies. Relying party integration building blocks A chain of six boxes from left to right: request, wallet, verification, mapping, record and logging, with a fallback box beneath the chain. Each box is labelled. Request Wallet Verify Map Record Log Fallback route When the wallet is not available Orange: your organisation. Navy: holder. Lime: alternative route and policy. ### 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.
Facilitator notes If an IT colleague joins, ask them to review the requirements table for testability. Look out for vague requirements such as "must be secure". Ask participants to rewrite them as checks someone could run. Do not recommend products. If participants ask about specific protocols, refer them to the official architecture and reference framework and to the standards bodies listed in the sources section.
### Quiz: Integration **Question 1.** Which component checks authenticity, issuer trust, validity and holder binding? [( )] The mapping component [( )] The logging component [(X)] The verification component [( )] The fallback route **** Verification is the step that decides whether the presented data can be relied on. **** **Question 2.** Which requirement is testable? [( )] The system must be modern [( )] The system must be secure [(X)] The request must contain only the three agreed data items, checked by inspecting a sample request [( )] The system must be user friendly **** A testable requirement states a result and a way to check it. **** **Question 3.** Why include a test case with an expired credential? [( )] To check how fast the wallet app loads [(X)] To confirm that the system rejects invalid data and triggers the fallback or review route [( )] To increase the number of logs [( )] To reduce the cost of the pilot **** Failing cases show whether your process behaves correctly when a check does not pass. **** **Question 4.** What should a log entry for a wallet check contain? [( )] The full credential [( )] The holder's full identity record [(X)] The date, use case and result, without extra personal values [( )] Nothing at all **** Logs support audit and troubleshooting. Keep them minimal, in line with data minimisation. **** ## 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. | Measure | Example (illustrative) | |---|---| | Staff time per check | Minutes saved compared with the current method | | Share of checks completed by wallet | Percentage of all checks in the pilot | | Failed checks sent to fallback | Number and cause | | Holder feedback | Short question after the check | | Data held | Fields stored per case compared with before | Review these after the pilot and decide: extend, adjust or stop. Report results to the use case owner and to the data protection officer. Redesigned process with wallet route and fallback route Five steps in a row: invite, request, approve, verify and record. A fallback loop from verify or request leads to an alternative check by staff and then to record. Each step is labelled. Invite Request Approve Verify Record Fallback: staff offer another route No wallet, declined request or failed check Orange: employer or provider steps. Navy: holder decision. Lime: fallback route. ### 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: | Step | Change | Owner | Training need | |---|---|---|---| | Invitation | Email explains the data request and reasons | Registry communications | Short template | | Request | Applicant starts the wallet request in the portal | IT | None | | Decision | Applicant approves in the wallet | Applicant | Help page | | Verification | System checks the presentation | IT | Incident procedure | | Outcome | Student record receives the result and agreed fields | Registry | Reading results | | Fallback | Clerk offers an in-person or document check | Registry | Fallback script, accessibility | 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.
Facilitator notes Ask participants to role-play the fallback conversation: one plays a member of staff, the other plays a person without a wallet. Debrief on tone, speed and dignity. Collect typical fears from staff and answer them with the plan elements. At the end, remind participants that the final plan needs all six sections, and give them the deadline for submission and the contact for assessment questions.
### Quiz: Process change **Question 1.** Why must a redesigned process include a fallback route? [( )] Because wallets never work [(X)] Because some people have no wallet or a check may fail, and they still need a fair route [( )] Because it reduces the number of records [( )] Because it is cheaper than the wallet route **** A fallback route supports inclusion and keeps the process usable when the wallet route fails. **** **Question 2.** Which action belongs in the invitation step? [( )] Asking the person to send a document scan by email [(X)] Telling the person which data you will request and why [( )] Deleting the person's record [( )] Sending the person a contract **** People should know what is asked and the reason before they open the wallet request. **** **Question 3.** Which is a good measure of value for a pilot? [( )] The number of staff who like the colour of the wallet [(X)] Staff time per check compared with a baseline [( )] The length of the privacy notice [( )] The number of emails sent in total **** Value measures compare results with a starting point, such as time, share completed and fields stored. **** **Question 4.** Which change belongs in policy and records? [( )] Printing more paper forms [( )] Storing the full presentation forever [(X)] Updating the privacy notice and the retention rule for wallet cases [( )] Removing the data protection contact **** Policy documents must match the new process and the minimum data you decided to keep. **** ## 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. | Criterion | 3 | 2 | 1 | 0 | |---|---|---|---|---| | A. Use case (outcome 1) | Decision, affected people and value are clear; selection reasoning scores several candidates | Decision and value are clear; some selection reasoning | Use case named; weak reasoning | Missing | | B. Minimum data and reasons (outcome 2) | Every item tied to the purpose; forms chosen carefully; clear reasons; retention stated | Most items justified; reasons mostly clear | Item list with weak reasons | Missing | | C. Registration and trust (outcome 3) | Complete inputs and owners; four checks defined; failure handling clear | Inputs and checks mostly complete | Partial inputs or checks | Missing | | D. Integration (outcome 3) | Option reasoned; testable requirements; pass and fail test cases; fallback described | Testable requirements; some test cases | Vague requirements | Missing | | E. Process change (outcome 3) | Redesigned steps with owners, training, policy and communication; inclusive fallback; value measures with baseline | Most elements present | Few elements or no fallback | Missing | | F. Regulated sector duties and timeline (outcome 4) | Duty and timeline stated correctly with sources; backward plan; open points marked to verify | Duty and timeline broadly correct; some open points | Unclear or partly incorrect | Missing | | G. Trustworthiness and Value | Plan protects holders, avoids over-collection and defines measurable benefit | Plan addresses both mostly | One of the two is weak | Missing | | H. Clarity and honesty | Clear structure; unverified facts marked; no invented claims | Mostly clear; few unmarked claims | Hard to follow or unmarked claims | Missing | **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. **Question 1.** Which starting point is best when you identify wallet use cases? [( )] Select the wallet product first [(X)] Find decisions that rely on facts about people and are checked by documents today [( )] Ask all staff to submit ideas without criteria [( )] Wait until the law forces acceptance **** Start with decisions and the facts they depend on. Technology follows. **** **Question 2.** Which factor is part of use case readiness in 2026 and 2027? [( )] The logo of your organisation [(X)] Whether your applicants or staff will hold the needed credential in a wallet [( )] The number of social media followers [( )] The age of your office building **** Readiness of holders and issuers varies widely between Member States and limits what you can request. **** **Question 3.** What does the course say about the European Business Wallets proposal, COM(2025) 838? [( )] It is in force and mandatory for all employers [( )] It was rejected by the Council [(X)] It is a proposal that is not adopted as of November 2026, so treat it as a topic to watch [( )] It replaces the EUDI Wallet for individuals **** The proposal is dated 19 November 2025, a Council general approach was prepared for June 2026, and Parliament work is ongoing. Check the current status before you rely on it. **** **Question 4.** What is the best expression of data minimisation for an age check? [( )] Request the full identity document to be safe [( )] Request date of birth and address [(X)] Request a yes or no answer to "over 18", if supported by the credential and wallet [( )] Request nothing and rely on trust **** A derived attribute answers the question without disclosing the underlying data. **** **Question 5.** What makes a "reason shown to the holder" good? [( )] It is as long as possible [( )] It uses technical terms [(X)] It names the decision, is short and is understandable without legal training [( )] It is hidden in a privacy notice **** Holders need a clear, short statement that explains why the data is needed. **** **Question 6.** Why do relying parties register and declare their intended requests? [( )] To avoid holder approval [(X)] So holders can see who asks and for which data, which supports trust [( )] To keep requests secret from regulators [( )] To reduce the number of credentials in circulation **** Registration identifies the organisation and its declared purposes, which the wallet can show to the holder. **** **Question 7.** Which set describes the verification checks a relying party should plan? [( )] Speed, colour, size and language [(X)] Authenticity, issuer trust, validity and holder binding [( )] Name, address, age and nationality [( )] Price, brand, location and supplier **** These checks establish whether the presented data is genuine, from a trusted source, current and presented by its holder. **** **Question 8.** Which integration requirement is testable? [( )] The solution must be state of the art [( )] The solution must be flexible [(X)] The request must contain only the three agreed data items, checked by inspecting a sample request [( )] The solution must be popular with staff **** A testable requirement states a result and a way to check it. **** **Question 9.** What must a redesigned process include for people without a wallet? [( )] A refusal message [( )] A request to buy a device [(X)] A fallback route that is fair, prompt and dignified [( )] A longer form with more data **** A fallback route protects inclusion and keeps the process usable. **** **Question 10.** Which statement about acceptance duties for regulated sectors matches the course status notes? [( )] Regulated private sectors must accept the wallet on 24 December 2026 [( )] Regulated private sectors have no duty [(X)] Regulated private sectors must accept the wallet about one year after issuance starts, and the exact scope and dates must be verified [( )] The duty starts only after the European Business Wallet is adopted **** The status note says about one year after issuance starts. Member States must offer at least one wallet by 24 December 2026, and readiness varies widely. Verify sector and national details. **** **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.
Facilitator notes Assessor guidance: - Use the rubric as written and record a short justification for each score. - Check that unverified legal and technical points are marked as such. A plan that states uncertain facts with confidence should lose marks on criterion H. - Invite a second assessor to review borderline plans. - Feedback should name one strength and one improvement for each section. - Allow one resubmission after feedback, within the period set by your programme. - Keep submitted plans confidential, because they may contain organisational details.
## 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.