All posts
· 9 min read ·

eIDAS 2.0 mandate credentials and the agent-delegation problem

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.

The conversation around agent identity in 2026 is unusually EU-centric. The European Digital Identity Wallet (EUDI Wallet) must be available in every Member State by 6 December 2026 per Regulation (EU) 2024/1183. We already wrote 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:

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 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), and almost no tooling for facts 3 and 4. We see this empirically: of the 1,211 alive A2A agents 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 ("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 + W3C Verifiable Credentials 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) defines how a verifier requests credentials and how the holder responds. The Wallet implementations from the EUDI reference implementation and from Sphereon ship OID4VP today.
  • The trust list: eIDAS Trusted Lists 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 fields. The A2A spec 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). Proves card integrity, doesn't prove identity. Adoption at 8 %.
  • GLEIF LEI (GLEIF docs). Solid legal-entity proof; doesn't carry delegation. We use it as the primary verification anchor 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). 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). On-chain identity + reputation. We wrote 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 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 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 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

Cite this post

@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}
}
← Back to blog Agenstry