All posts
· 10 min read ·

Europe's digital identity wallet ships in 2026. The agent case is in the next one.

Regulation (EU) 2024/1183 puts at least one government-issued EU Digital Identity Wallet in every Member State by 6 December 2026. The current Architecture and Reference Framework — v2.8.0 — explicitly removes the legal-person credential from scope and defers it to a separate 'European Business Wallet'. The credential pattern an agent acting on behalf of a company actually needs sits between the two.

Regulation (EU) 2024/1183 — the update to eIDAS that creates the European Digital Identity Wallet — was adopted on 11 April 2024 and entered into force on 20 May 2024. The first round of implementing regulations was published on 4 December 2024, starting a 24-month clock. By 6 December 2026, every EU Member State must make at least one wallet available to its citizens, residents, and businesses. By 6 December 2027, every private-sector relying party that is required by law or contract to use strong authentication has to accept it.

The version of the Architecture and Reference Framework that operationalises all of this is ARF v2.8.0. Section 3.2 of that document contains one sentence the agent-infrastructure community should read carefully:

the topic of Wallet Units for legal persons, possibly containing a legal-person PID, has has been removed from this ARF in view of the development of a separate business wallet.

The wallet that ships at the end of 2026 is the personal one. Person Identification Data, Electronic Attestations of Attributes, and a natural-person representation attestation are in scope. The legal-person side has been deferred to a separate "European Business Wallet" on a timeline that is not yet public.

That split is the structural observation worth marking, because the agent web's canonical identity case sits exactly between the two halves.

What ships in the personal wallet

The wallet specified by ARF v2.8.0 carries three things relevant to identity:

  • PID — Person Identification Data. Issued by or on behalf of a Member State, at Level of Assurance "high", containing the natural-person attributes (legal name, date of birth, national identifier). This is the anchor.
  • EAAs — Electronic Attestations of Attributes. Driving entitlements, professional qualifications, residency. Issued by public or private attribute providers, supporting selective disclosure.
  • Representation attestations. Section 2.6.5 of the ARF defines these as a "dedicated representation attestation for a natural person", with an Attestation Rulebook that "specifies the nature of the representation and clearly defines the operations that the representative is authorized to perform." The canonical examples in the spec are legal guardianship of a minor and power of attorney over a parent's affairs.

What is not in scope, by the ARF's own admission, is the legal-person credential and the wallet unit that would hold it.

What got pushed to the Business Wallet

The EWC consortium's RFC005 gives the cleanest current picture of what a Legal Person Identification Data credential looks like. The mandatory attributes are minimal — a legal_person_id matching the EUID structure used by EU business registers, and a legal_person_name as registered in that authentic source. The credential is issued in dc+sd-jwt format over OpenID4VCI, and its issuance flow requires the natural person requesting it to be authenticated at LoA "high" and to have their representative rights verified against the business register.

The credential is functionally what GLEIF's LEI is in the cross-border identifier system, with one difference that matters: it is issued through national authentic sources (the Unternehmensregister in Germany, the KvK in the Netherlands, the INSEE in France, the Companies House register in the UK), and held in a wallet rather than in a public lookup. That changes who can prove what and how.

But the RFC is a pilot specification, not a production deployment. The personal wallet ships first. The business wallet's date is open.

The composition gap

The agent web's standard identity case is "this software agent is authorised to act on behalf of a particular legal entity." It is the case x402 receipts implicitly assume when an autonomous payment lands on a wallet; it is the case the A2A signed agent card declines to encode; it is the case ERC-8004's three registries acknowledge by separating identity from validation.

The eIDAS 2.0 stack has both of the primitives needed to express it.

  • The LPID names the legal entity.
  • A representation attestation names the bind between an identity and that legal entity, with a Rulebook that scopes which operations are authorised.

The composition is the agent attestation: "Software identity X is authorised to perform operations Y on behalf of legal-person Z, until time T." Nothing in the regulation prevents that composition. Nothing in the regulation has formalised it either. The pieces ship on different timelines into different wallets.

Personal wallet (ARF v2.8.0) Business wallet (deferred) PID Member-state issued Natural person, LoA high ships Dec 2026 EAAs Selective disclosure Qualifications, residency ships Dec 2026 Representation Natural-person to natural-person scope ships Dec 2026 LPID EWC RFC005, pilot no public date Agent representation No spec yet no public date

The two boxes above the line ship in eighteen months. The two below the line do not have public timelines. Until they do, the agent identity case has to be reconstructed from primitives that exist outside the wallet.

What this means until the Business Wallet arrives

Operators in the EU who want to prove "agent X serves on behalf of legal entity Y" between now and the Business Wallet's release are working with three available primitives:

  1. GLEIF's Legal Entity Identifier — production, cross-border, but not held in a wallet and not natively bound to a software identity.
  2. National authentic business registers — accessible by ad-hoc API, none harmonised at the agent-binding layer.
  3. DNS plus a signed agent card — the JWS-signed agent card at a verified domain, with the legal-entity binding established outside the card itself.

Each of these proves part of the chain. None of them proves the composed statement: a particular legal entity, registered in an authentic source, has authorised a particular software identity to act on its behalf in a particular scope. The Business Wallet's eventual LPID plus a Rulebook for representation-by-a-legal-person would prove that natively. Until then, the binding lives in registries that aggregate the available signals.

That gap is not a regulatory failure. It is a sequencing decision. The Commission chose to ship the consumer side of the wallet first because the consumer side is the part with the largest cross-border friction (border crossing, age verification, qualification recognition), and the business side has working national authentic sources that already cover most domestic use cases. The agent web inherits the lag.

What we are watching

Three things between now and the Business Wallet's first public draft.

  1. Whether the personal wallet's representation attestation Rulebook ever covers legal-person scope. The ARF leaves that question open. If the Rulebook stays restricted to natural-person guardianship and power-of-attorney, the agent case has to wait for the separate business wallet. If it broadens, agent attestations could land earlier.
  2. The first non-pilot LPID issuance. EWC's pilot phase covers digital travel credentials and a handful of business-identity use cases. None has crossed into production issuance with the relying-party acceptance the eIDAS 2.0 framework requires.
  3. The shape of the European Business Wallet specification when it appears. Whether it inherits the personal wallet's representation-attestation architecture, or whether legal-person representation gets a new credential type designed for the case the agent web is already running into.

The credential the agent web ultimately wants — one that proves, in a single verifiable statement, that a specific software identity is acting on behalf of a specific legal entity at a specific scope — is something the eIDAS 2.0 framework can produce. The framework's first deliverable does not. Treating the gap as temporary, rather than as an absence, is the accurate read.

Sources

← Back to blog Agenstry