Agent Credentials and the European Wallet: A Roadmap Target, and a Question Nobody Upstream Has Settled

Nothing here is legal advice

This page describes engineering state and a roadmap. It is a reading of our own code and our own plans, not legal advice, and nothing on it should be relied on as a statement about what any regulation requires of you.

The position, stated exactly

Alignment with the European digital identity architecture is a roadmap conformance target for the final quarter of 2026. It is not a certification we hold.

The qualified-trust-service path and mobile-document issuance are documented roadmap on the same basis. Neither is built, and neither is claimed.

Why we are building toward it, which belongs on the page

A self-issued identifier is worth nothing until a relying party trusts the issuer. That is the whole problem with decentralised identity, and it is not a cryptographic problem.

The European framework manufactures exactly that trust, at continental scale, by making trusted issuers a legal category rather than a bilateral negotiation. For an issuer, that is the difference between convincing one counterparty at a time and being recognised by construction.

So this is the most valuable thing on our roadmap and the furthest from done, and saying only the second half would misdescribe our position as much as saying only the first.

The gap, measured rather than characterised

Across this surface's packages and backend, the vocabulary of the European architecture, mobile documents and qualified trust services returns nothing at all. The single hit for the wider search is an import of the status-list draft, used for revocation.

CONTROL ONE: the same search over a different package of ours returns nine files, so the format capability exists inside the company and not on this surface.

CONTROL TWO: credential vocabulary matches fourteen files here, so the searched path is not empty.

What this surface emits today is a Solidus-defined envelope, and its own proof type refuses to claim conformance with a standard cryptosuite it has not been assessed against. That refusal is correct and it is also the gap: an artefact that declines to claim conformance is an artefact that does not have it.

What is already aligned, and what you can check today

The credential data model is the published W3C one, so the shape is not invented.

The revocation mechanism is the same status-list draft the wider ecosystem is standardising on, which is why the one import above exists.

And the identifier method is registered in the W3C DID Method Registry, which is the piece most often missing when somebody claims standards alignment.

Three real pieces, and none of them is conformance.

And the third is checkable in one command, which is why it is the one we lead with: curl -s https://api.github.com/repos/w3c/did-extensions/pulls/713 returns a merged request titled "Register did:solidus method". You can verify that yourself, today, without us. The public agent card is likewise fetchable with no account.

And the question a marketing version would skip

An agent is not a natural person.

The European wallet framework was designed for people, and for legal persons, with human attributes, human consent flows and human recovery in mind. Whether credentials about a non-human actor belong inside that framework, or beside it, is not settled, and it is not ours to settle.

So even a complete conformance effort on our side leaves an open question upstream, and any page implying that an agent credential simply drops into a European wallet once we finish our work would be inventing an answer.

We think the operator's credential is where the two meet, since the operator is a person, and this surface ingests exactly that credential rather than issuing it. That is a thesis, and it is the one worth testing first.