---
title: "eIDAS 2.0 mandate credentials and the agent-delegation problem"
date: 2026-05-18
summary: "The EU Digital Identity Wallet ships a representation credential type — 'X is authorized to act on behalf of Y' — that is structurally identical to what an autonomous agent needs to prove. The credential pattern is already drafted in the EUDI Architecture and Reference Framework v2.8. Whether it lands as agent-readable infrastructure is now a presentation-protocol question, not an identity question."
slug: eidas-2-mandate-credentials-agent-delegation
author: "Sebastiaan Hilbers"
hero_glyph: branches
kind: research
---

The conversation around agent identity in 2026 is unusually
EU-centric. The
[European Digital Identity Wallet (EUDI Wallet)](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/)
must be available in every Member State by
[6 December 2026](https://eur-lex.europa.eu/eli/reg/2024/1183) per
Regulation (EU) 2024/1183. We
[already wrote](https://agenstry.com/blog/eudi-wallet-2026-agent-case-deferred)
that the *legal-person* credential — the one that would let an
agent prove "I belong to Acme BV" — has been deferred to a separate
"European Business Wallet" workstream. This post is about a
different credential type in the same regulation that is *not*
deferred, and that maps unusually closely onto the agent-delegation
problem: the **representation credential**, also called a *mandate*.

The credential's draft definition is in
[ARF v2.8, §6.6.5](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v2.8.0/docs/arf.md#665-representation-credentials):

> A Representation Credential ("Power of Representation Attestation"
> or "PoR Attestation") allows a natural or legal person to issue, to
> another natural or legal person, an attestation that the latter is
> authorized to represent the former for a specified purpose.

Strip the legalese and the structural shape is: **subject** (who is
allowed to act), **principal** (on whose behalf), **scope** (for what
purpose), **validity window** (until when), **issuer** (who attests
to the relationship), all of it wrapped in an
[ISO/IEC 18013-5 mDL](https://www.iso.org/standard/69084.html)
container with the eIDAS-mandated signature chain. The same data
model an autonomous agent acting on behalf of a human or company
needs to publish.

## What this maps to in the agent stack

Consider an agent built to handle a small business's online ordering.
The structurally honest version of its identity has four
distinguishable facts:

1. The agent is a software system with a public endpoint.
2. The agent is built/run by some operator (a person or company).
3. The operator has been delegated some power by the business —
   often the business is the operator (sole proprietor), often it
   isn't (the operator is a contractor or platform).
4. The delegation has a scope (allowed to take orders for X
   products), a validity window (today through end-of-quarter), and
   should be revocable.

The agent ecosystem has tooling for fact 1 (DNS + TLS), partial
tooling for fact 2 (JWS-signed cards, the LF
[Linux Foundation A2A registry](https://github.com/Linux-Foundation/a2aregistry)),
and almost no tooling for facts 3 and 4. We see this empirically:
of the [1,211 alive A2A agents](https://agenstry.com/reports/state-of-agent-economy)
in our index, 8 % publish a signed card (the fact-2 piece); zero
currently expose a credential structure that maps "the operator
behind this agent has been delegated authority by Acme BV for the
purpose of online ordering, valid through 2026-12-31."

EUDI representation credentials are an exact fit for facts 3 + 4. The
ARF draft cites use cases including
[delegation of legal representation](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v2.8.0/docs/arf.md#665-representation-credentials)
("an employee acting on behalf of an employer"), parental authority,
and proxy voting. The agent case is the same shape with a different
subject category — the subject is a software system rather than a
natural person.

## The infrastructure that already exists

Three pieces of the credential infrastructure are already operational
in eIDAS 2.0 territory:

- **The credential format**:
  [ISO/IEC 18013-5 mdoc](https://www.iso.org/standard/69084.html) +
  [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/)
  are the two formats the Wallet must accept. mdoc is the offline-
  capable format with a chain back to an Issuer Trust List; VCDM 2.0
  is the JSON-LD format that JWS-signed agent cards are a subset of.
  Both already have working signers + verifiers.
- **The presentation protocol**:
  [OpenID for Verifiable Presentations (OID4VP)](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
  defines how a verifier requests credentials and how the holder
  responds. The Wallet implementations from
  [the EUDI reference implementation](https://github.com/eu-digital-identity-wallet/eudi-reference-implementation)
  and from
  [Sphereon](https://github.com/Sphereon-Opensource/SSI-SDK) ship
  OID4VP today.
- **The trust list**:
  [eIDAS Trusted Lists](https://eidas.ec.europa.eu/efda/tl-browser/)
  publish the public keys of the credential issuers each Member
  State has accredited. Verifying a representation credential
  reduces to "is the signing key in the relevant Member State's
  trust list?" — well-defined, no new PKI needed.

What is *missing* is the agent-side adapter: a convention for
where an agent publishes the representation credential it holds, how
a routing/verifier surface fetches it, and the field-mapping between
the EUDI credential fields (`representation_type`, `effective_from`,
`effective_until`, `legal_person_identifier`) and the
[A2A AgentCard `provider`](https://a2a-protocol.org/latest/specification/#441-agentcard)
fields. The
[A2A spec](https://a2a-protocol.org/latest/specification/)
deliberately leaves the link to external identity systems
under-specified — the protocol is designed to be agnostic to which
identity layer is used, on the reasonable theory that the identity
layer market hasn't picked a winner yet.

## Why this is plausibly the winner

The agent-identity conversation has, since 2024, cycled through:

- **Self-attested JWS-signed cards** ([A2A §8.4](https://a2a-protocol.org/latest/specification/#84-agent-card-signing)).
  Proves card integrity, doesn't prove identity. Adoption at
  [8 %](https://agenstry.com/blog/a2a-signed-cards-adoption-measurement).
- **GLEIF LEI** ([GLEIF docs](https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei)).
  Solid legal-entity proof; doesn't carry delegation. We use it as
  the
  [primary verification anchor](https://agenstry.com/methodology) on
  Agenstry, but it tells you *that* a company exists, not *what an
  agent is allowed to do on that company's behalf*.
- **DID:web** ([W3C DID Core](https://www.w3.org/TR/did-core/)).
  Domain-bound identifier with optional VC delegation chains. Strong
  primitives, weak adoption pull — counted DID-published agents on
  our index: 47.
- **ERC-8004 three-registry pattern** ([EIP draft](https://eips.ethereum.org/EIPS/eip-8004)).
  On-chain identity + reputation. We
  [wrote](https://agenstry.com/blog/erc-8004-three-registries-honesty)
  about why even ERC-8004's authors admit identity-alone is insufficient.

EUDI representation credentials are different from all four because
they are *issued*, not *self-attested*. The signing key sits with a
public-registered Trust Service Provider in a Member State; the
credential itself is bound to the eIDAS framework's legal force.
That moves agent delegation out of "the operator claims this is
true" territory into "a registered authority attested to this on
date X". The operational distinction is the same one between an
SSH key fingerprint (proves possession) and a TLS certificate
(proves possession + a trust chain back to a CA).

## The remaining open question

The bottleneck is not the credential format. The bottleneck is
**where the agent publishes the credential and how the routing
surface fetches it**. Three plausible shapes:

1. **Embedded in the AgentCard.** The card already has a
   `provider` block; extending it with a `representationCredential`
   field carrying a VC + presentation proof is a one-field schema
   addition. The Linux Foundation A2A working group is the body
   that would land this; the
   [A2A v1.0 extension registry](https://github.com/a2aproject/A2A/tree/main/specification/extensions)
   already supports versioned protocol additions. This is the
   lowest-friction path.
2. **A separate `/.well-known/representation-credential.json`
   endpoint.** Mirrors the JWKS pattern. Lets the card stay small
   and lets the credential refresh independently. The downside is
   another fetch in the verification path, which routers care about.
3. **OID4VP roundtrip at verification time.** Strong privacy story
   (no credential bytes in transit until verification is requested),
   higher operational complexity (the verifier holds the protocol
   state). Suitable for enterprise gateways, overkill for casual
   discovery.

The first option is the one we will be advocating for on our
[methodology page](https://agenstry.com/methodology) and in the LF
working group conversations. The credential is small (~2 KB JSON
+ signature), the schema change is additive, and the verification
flow already exists in JWS-validator implementations that handle
nested VCs.

## What we are watching

The
[European Business Wallet workstream](https://digital-strategy.ec.europa.eu/en/policies/european-digital-identity-wallet)
hasn't published a public schedule beyond "consultation phase
2026-2027". Whichever working group lands the agent-side adapter
first — A2A, AGNTCY, AAIF — picks the credential shape the rest of
the agent industry inherits. The EUDI reference implementation is
mature enough that the agent-side adapter is software, not
standards, work; the choice is which standards body claims it.

The EU has spent two decades building a credential framework that
maps onto the agent-delegation problem. The framework now ships in
December 2026. The next twelve months decide whether the agent
industry picks it up or builds a parallel one with weaker
assurances.

## Sources

- [Regulation (EU) 2024/1183 — eIDAS 2.0](https://eur-lex.europa.eu/eli/reg/2024/1183) — Official Journal of the EU, 30 April 2024.
- [EUDI Architecture and Reference Framework v2.8](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v2.8.0/docs/arf.md) — European Commission, March 2026.
- [ARF §6.6.5 Representation Credentials](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/v2.8.0/docs/arf.md#665-representation-credentials) — European Commission, March 2026.
- [ISO/IEC 18013-5 — mobile driving licence / mdoc](https://www.iso.org/standard/69084.html) — ISO, 2021.
- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) — W3C Recommendation, 15 May 2025.
- [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) — OpenID Foundation, January 2026.
- [eIDAS Trusted Lists Browser](https://eidas.ec.europa.eu/efda/tl-browser/) — European Commission, live.
- [EUDI reference implementation](https://github.com/eu-digital-identity-wallet/eudi-reference-implementation) — European Commission, retrieved 2026-05.
- [A2A specification v1.0 §4.4 Agent Card](https://a2a-protocol.org/latest/specification/#441-agentcard) — Linux Foundation, March 2026.
- [A2A v1.0 extension registry](https://github.com/a2aproject/A2A/tree/main/specification/extensions) — A2A Project, retrieved 2026-05.
- [Agenstry: EUDI Wallet 2026 — agent case deferred](https://agenstry.com/blog/eudi-wallet-2026-agent-case-deferred) — Sebastiaan Hilbers, 18 May 2026.
- [Agenstry: A2A signed-cards adoption measurement](https://agenstry.com/blog/a2a-signed-cards-adoption-measurement) — Sebastiaan Hilbers, 18 May 2026.

## Cite this post

```bibtex
@misc{agenstry-eidas-2-mandate-2026,
  author       = {Hilbers, Sebastiaan},
  title        = {eIDAS 2.0 mandate credentials and the agent-delegation problem},
  howpublished = {Agenstry research blog},
  year         = {2026},
  month        = {may},
  url          = {https://agenstry.com/blog/eidas-2-mandate-credentials-agent-delegation}
}
```