eIDAS 2.0 From the Relying Party's Side, Where Our Own Verifier Half Satisfies It

Nothing on this page is legal advice, and we make no compliance claim, hold no qualified status of any kind, and do not claim to be aligned, compatible or conformant with this framework.

What the framework does, in one paragraph

It amends an older European regulation on electronic identification and trust services to add a wallet, and to place duties on the parties around it: member states make wallets available, qualified providers issue certain attestations under supervision, and relying parties that accept wallet credentials take on duties of their own.

We have already scored ourselves against the wallet obligations and most of them are unmet. This page is about the other seat, because our own verifier sits in it.

What the framework asks of a relying party

Register, and be identifiable, so a holder can see who is asking.

State in advance what you need, rather than requesting everything and filtering later.

Do not ask for more than the purpose requires, and do not retain beyond it.

Do not refuse a holder who declines to disclose something the purpose does not require.

What is already built, because absences alone would misdescribe us

We implement one of the two credential formats the framework accepts, with selective disclosure and holder binding at the package layer.

We implement the presentation protocol on the verification side, which is the half a relying party runs.

Our identifier method is registered in the W3C DID Method Registry, and documents resolve publicly today.

That is a real starting position. It is not conformance, not qualified status, and not alignment.

Our verifier against those, measured

Stating in advance: yes, and properly. The request pins the credential type, enumerates the specific claims needed, and sets the constraint that disclosure be limited to them. When a response arrives it re-checks server-side that the type matches and that every required claim is present, rather than trusting the sender to have obeyed.

A control shows the distrust is real: CONTROL that shows the distrust is real: the type is re-checked even though the request already pinned it, so the file does contain the instinct.

Not asking for more: half. The re-checks confirm every required claim is present. Nothing confirms that no other claim is. A wallet that ignores the constraint and sends every field is accepted, and the surplus flows through.

Not retaining beyond the purpose: no. The verified claims are written into the request row and no cleanup exists in that module. The expiry on a request governs whether it can still be used, which is a different question from how long its contents live.

So on the one duty we are closest to, we satisfy the asking half and fail the receiving half. That is a more useful sentence than either a pass or a fail, and it is the shape a regulator would care about: minimisation enforced when requesting and unenforced when receiving is a well-formed request followed by whatever the other side sent.