EUDI wallet: using digital identity proofs in the shop

A customer puts an age-restricted item into the basket and has to prove they are of age. Today they upload a picture of an identity document or go through a video check, and afterwards the shop holds date of birth, address and document number, although a single question was all that mattered. The European Digital Identity Wallet turns that around: the customer releases a confirmed proof, the shop receives the answer, and the rest stays on the device. The basis is Regulation (EU) 2024/1183 of 11 April 2024, the deadlines hang on the implementing acts of November 2024, and registration of the requesting parties is governed by Implementing Regulation (EU) 2025/848. This article sorts the duties, names the deadlines and shows the points in the online shop where the wallet attaches.

What the wallet is and who it concerns

The European Digital Identity Wallet is an application that a member state provides or has provided on its behalf. It holds person identification data and electronic attestations of attributes, that is individually confirmed statements such as age, address or the capacity to act for a company. Every member state provides at least one such wallet within 24 months of the entry into force of the corresponding implementing acts (Regulation EU 2024/1183, Article 5a(1)). For a shop it is therefore neither a payment method nor a customer account, but a source for proofs that are obtained today either not at all or by detours: a picture of an identity document, a video check, a register extract as a file attachment.

Two properties set it apart from an uploaded document. First, the regulation requires that selective disclosure of data is possible: the user releases individual attributes rather than the whole record (Regulation EU 2024/1183, Article 5a(4)(a)). Second, issuance, use and revocation are free of charge for natural persons (Regulation EU 2024/1183, Article 5a(13)). What that means in the ordering path shows in a single question: a shop that needs to know whether a customer is of age receives a confirmed yes or no instead of a date of birth that it has to calculate from and that then sits in its database.

The use of European Digital Identity Wallets shall be voluntary.

Regulation (EU) 2024/1183, Article 5a(15)

Voluntary means the wallet replaces no existing path, it sits next to them. A shop working today with a password, a passkey or guest checkout keeps those paths and gains one more. That is the decisive planning constraint, because any implementation that switches off the old path creates failures for everyone who has no wallet or does not want to use one. Anyone already working on registration in the customer account is better off planning the additional path in from the start than cutting it into a finished form later.

Registration: the shop becomes a relying party

Anyone who wants to query a wallet registers beforehand. The regulation requires registration in the member state in which the relying party is established (Regulation EU 2024/1183, Article 5b(1)). This is not an account with a provider but an entry in a state register, and it is the precondition for a wallet answering a request at all. For a shop established in Germany that means one procedure with the competent German body, regardless of which member states the customers come from.

How that procedure runs is set out in Implementing Regulation (EU) 2025/848. It obliges the registrars to set up easy-to-use electronic and, where possible, automated registration procedures (Implementing Regulation EU 2025/848, Article 6(1)) and at the same time requires refusal where the information cannot be verified (Implementing Regulation EU 2025/848, Article 6(6)). The entry is therefore not a form filled in on the side, but a self-declaration with a check – comparable to what a shop asks of its own business customers today.

• Who is asking: the name from the official record, identifiers such as a commercial register number or a VAT identification number, the physical address of the establishment and the website address.
• Which data: for each intended use, the list of attestations and attributes to be requested. The list in Annex I runs to 16 numbered items, from the official record through to the link to the relying party that relies on the intermediary used (Implementing Regulation EU 2025/848, Annex I as amended by Implementing Regulation EU 2026/1730).
• What for: each intended use comes with a description. A shop that wants to request age, company status and address describes three intended uses, not one.
• Public or private: the entry records whether the relying party is a public sector body, because different duties follow from that.
• Through whom: where an intermediary acts on behalf of the shop, that is noted in the entry. For B2B processes with connected procurement portals this is the point at which responsibility is settled.

Registration produces access and registration certificates that identify the requesting party towards the wallet. In practice: the customer sees before releasing anything who is asking and what for – not as explanatory text in the shop, but in their own application, from a source the shop does not control. For the design of the ordering path that is an advantage, because the question of trust no longer has to be answered on the product page. For operations it is an obligation, because the entry has to match the requests actually made.

Data minimisation: what the shop may request

The second duty is put unusually briefly in the text: relying parties shall not request data from users other than that declared at registration (Regulation EU 2024/1183, Article 5b(3)). That reverses the usual order. So far the shop decides in the form what it asks for and explains it later, if anyone asks. In future the explanation sits in the register beforehand, and the form may only ask for what is entered there. Anyone collecting fields today because they might be useful one day is working against their own registration in this logic.

What can be requested at all is outlined as well. Annex VI to Regulation (EU) 2024/1183 names a minimum list of 11 attributes, running from address through age and sex to financial data and company data for legal persons (Regulation EU 2024/1183, Annex VI). More important for the shop is the other direction: the use of pseudonyms shall not be refused as long as no legal provision requires identification of the user (Regulation EU 2024/1183, Article 5b(9)). A customer account without a legal name is therefore no longer a tolerated exception but a path that has to stay open.

The gain lies less in the technology than in what is no longer in the system afterwards. A picture of an identity document in the ticket system, a date of birth in the customer record, a register extract in a file attachment – those are holdings that have to be kept, protected and eventually deleted, and experience shows they sit in more places than planned. A request through the wallet returns an answer that the shop can log without storing the proof itself. That shrinks the data holding exactly where it is least manageable.

Where the wallet attaches in the ordering path

There are four points in the ordering path where a request usefully attaches, and they differ markedly in effort and effect. At the beginning stands the creation of an account, at the end the release of a single order. In between sit the cases where a proof belongs not to the customer but to the transaction: an age proof for a particular product, a company confirmation for a price tier, an entitlement for a range that is not visible to everyone.

Which point gets built first depends less on the technology than on the range. A shop with age-restricted items has a hard trigger, because that is where the most laborious check sits today and every extra step costs orders. A shop taking on business customers saves elsewhere: the business check during new customer registration is manual work with waiting time today, and precisely that waiting time falls away when an attested company attribute is available.

• Account creation: the customer creates an account and releases a confirmed name or a pseudonym in the process. The advantage is a record checked once, the drawback an extra hurdle at the least favourable point of the ordering path.
• Product-related release: the request appears only when an item in the basket calls for it. That keeps the normal case clear and in practice has a favourable ratio of effort to effect.
• B2B onboarding: company attributes replace the register extract. Where price tiers, pack sizes and minimum order quantities hang on the customer group, this proof decides which range is unlocked.
• Account recovery: a lost customer account can be matched through a confirmed proof without anyone in support looking at identity document data.

The same condition applies to each of these points: the existing path stays. Because use is voluntary, every ordering path has to reach its end without a wallet as well, with no dead end and no second sign-in. Technically that is a branch and not a replacement; it belongs in custom development at the checkout and not in an extension that overwrites the standard path.

Voluntary, mandatory, exempt

The regulation distinguishes who has to accept the wallet. Where member states require electronic identification for access to an online service provided by a public sector body, they also accept the wallet (Regulation EU 2024/1183, Article 5f(1)). Private relying parties are only caught by the duty where they owe strong user authentication anyway, and then only 36 months after the entry into force of the implementing acts and only at the voluntary request of the user (Regulation EU 2024/1183, Article 5f(2)). Microenterprises and small enterprises within the meaning of Recommendation 2003/361/EC are exempt from it.

For an online shop the classification therefore hangs on a prior question: does it owe strong user authentication itself? In payments that duty as a rule sits with the payment service provider and not with the merchant, and the forthcoming EU payment rules shift that line in part. A shop that neither provides payment services nor is required to use strong authentication under other law typically does not fall under the acceptance duty – and can still connect, because the benefit lies in dropping its own checking route rather than in the duty.

Deadlines and dates

The deadlines hang on a single reference date, and it is not in the regulation itself but in the implementing acts. Article 5a(1) and Article 5f(2) both count from the entry into force of the acts referred to in Article 5a(23) and Article 5c(6). Implementing Regulation (EU) 2024/2981 on the certification of the wallets is based on Article 5c(6), was published in the Official Journal on 4 December 2024 and entered into force on the twentieth day following that publication (Implementing Regulation EU 2024/2981, Article 22). That puts the reference date at 24 December 2024.

This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. It shall apply from 24 December 2026.

Implementing Regulation (EU) 2025/848, Article 11

From that reference date the first marker follows: 24 months for the member states to provide the wallets, that is 24 December 2026. That Implementing Regulation (EU) 2025/848 on the registration of relying parties applies from exactly that day fits, because register and wallets depend on each other: no entry, no request; no wallet, no proof. For a shop that is the earliest possible point at which a request can be answered in live operation, and not the point at which implementation should begin.

The second marker lies twelve months later. Article 5f(2) gives private relying parties required to use strong user authentication 36 rather than 24 months from the same reference date, which leads to the end of December 2027. Until then the technical basis keeps moving: the Architecture and Reference Framework of the European Commission has been available in version 3.0.0 since 21 July 2026, and Implementing Regulation (EU) 2026/1730 of 15 July 2026 has adapted the registration rules to amended standards and specifications and added a sixteenth item to Annex I covering the link to the relying party that relies on the intermediary. Anyone planning today is planning against moving specifications with fixed deadlines – one more reason to build the request as a replaceable component.

Technical implementation in the shop

Less code arises in the shop than the legal position suggests. Four components are needed: a description of which attributes are requested for which purpose; a place that receives and checks an answer from the wallet; a decision that turns the answer into a yes or no for the ordering path; and a log that keeps that decision traceable without storing the proof. The first component is at the same time the template for the register entry, because the same information is asked for there – one list per intended use, plus a description.

{
  "purposes": [
    {
      "id": "age_proof",
      "description": "Release of age-restricted items in the basket",
      "attributes": ["age_over_18"],
      "store_answer": false,
      "log": ["timestamp", "purpose", "result"]
    },
    {
      "id": "company_proof",
      "description": "Onboarding as a business customer with a price tier",
      "attributes": ["legal_name", "legal_person_identifier"],
      "store_answer": true,
      "log": ["timestamp", "purpose", "result"]
    },
    {
      "id": "delivery_address",
      "description": "Confirmed address for the delivery",
      "attributes": ["resident_address"],
      "store_answer": true,
      "log": ["timestamp", "purpose", "result"]
    }
  ],
  "fallback": "the existing checking route stays active for every purpose"
}

The answer from the wallet is a signed proof and not a form value. What is checked is therefore not the content alone but the chain behind it: who issued it, is the proof valid, does it belong to the request the shop made. Only then does the decision arise, and only that decision belongs in the order record. How long such transactions are meant to stay traceable is shown by the duty on the registrars: they keep the records of the registered information for a period of ten years (Implementing Regulation EU 2025/848, Article 10).

Where these components sit decides how much maintenance follows. A separate service with a clear interface to the shop can be replaced when the specification changes – and it has already changed once since the first implementing act. An implementation that writes the check straight into the checkout means rework in many places rather than one at the next change. The request therefore belongs behind its own boundary, with a contract consisting of purpose, result and timestamp.

• Where the certificates sit: access and registration certificates belong in the same management as other keys, with an expiry date and named responsibility. Operations has to manage the change without an outage in the ordering path.
• What is logged: purpose, timestamp, result – not the proof. A log that writes attributes along with it cancels out the gain from data minimisation.
• Who sees what in the backend: the results belong behind the same permission check as order and customer data, and under the same deletion period.
• What is used for testing: test proofs belong in a separate environment. Real wallets in a test environment create transactions that nobody can attribute afterwards.

Checklist for the preparation

There is time until the first possible live operation, and it can be used without a project budget. The larger part of the preparation consists of sorting your own holdings: which proofs does the shop ask for today, on what basis, and what happens to them after the check. That inventory is useful independently of the wallet, because it shows the places where more is stored today than is needed.

• List every point in the ordering path where the shop asks for a proof today, with purpose and legal basis.
• Record for each proof which data arises, where it sits and when it is deleted.
• Check whether the shop itself is required to use strong user authentication – the acceptance duty under Article 5f(2) hangs on that.
• Phrase the planned intended uses so that they fit the register entry: one intended use, one attribute list, one description.
• Define the path for customers without a wallet at each point before the request is built.
• Name responsibility for certificates, log and register entry, with a deputy and expiry monitoring.
• Set a date for the registration in the member state of establishment and tie it to the provision of the wallets.

What can be decided now

Two decisions can be taken today without waiting for a finished wallet. The first is the question of where in the ordering path the first proof should be requested; it hangs on the range and not on the technology. The second is the question of how much the shop wants to keep after the check; it decides whether the implementation shrinks the data holding or merely puts another source next to it. Neither answer is in any legal act, they are in your own process.

Everything else is craft with known deadlines: a register entry, a branch in the checkout, a service with a clear boundary and a log without attributes. Anyone who wants to know which checking routes their shop runs today and which of them a wallet request could replace will find the way in through a shop check. For the implementation at checkout, customer account and B2B onboarding the route leads through a project enquiry with the actual range and the proofs asked for today.