EAA, QEAA and PuB-EAA: the three attestation types

The question a relying party has to answer about a European Digital Identity (EUDI) Wallet credential is not whether it came from a wallet. It is which kind of attestation it is, because that determines who stood behind the statement and what weight it carries.

Under the revised electronic identification and trust services framework, usually called eIDAS 2.0, there are three kinds of electronic attestation of attributes, plus person identification data, which is a separate thing again. Teams that collapse them into "wallet credentials" end up building verification logic that cannot distinguish a government register from a gym membership.

An attestation of attributes is a signed statement about someone, not an identity

An attribute is a characteristic: a date of birth, a professional qualification, a company registration number, an authorisation to act for an organisation. An electronic attestation of attributes is a signed electronic statement asserting one or more of those characteristics about a given subject.

It is deliberately not identification. A relying party can verify a specific fact about a person or organisation without receiving a general-purpose identity document, and often without learning anything else. That separation is why selective disclosure matters, and why "the wallet proves who you are" is a poor mental model.

Person identification data is the identity layer, and it sits apart

Person identification data, usually shortened to PID, is the set of data that establishes the identity of the wallet holder. It is issued in connection with the notified electronic identification scheme behind the wallet, and it is the thing that makes the wallet an identification means rather than a credential folder.

Attestations of attributes are layered on top of that. A qualification attestation says something about a person; who that person is comes from the identity layer underneath. Keep the two separate in your own data model, or you end up unable to answer which issuer asserted which fact.

An electronic attestation of attributes is the general, unqualified case

The base case is the electronic attestation of attributes, abbreviated EAA. Any issuer can produce one. A professional body, an employer, a university, a membership organisation, or a commercial service can all issue attestations about attributes they are in a position to assert.

An EAA is not thereby untrustworthy. It carries exactly the trust that its issuer carries, which for a well-known professional register may be considerable. What it does not carry is a presumption established by the regulation itself. The relying party decides how much weight to give it, on the basis of who issued it and what the relying party knows about that issuer.

A qualified attestation is issued by a qualified trust service provider

A qualified electronic attestation of attributes, or QEAA, is issued by a qualified trust service provider operating under the supervisory regime that eIDAS establishes for trust services. The provider is supervised, is subject to conformity assessment, and appears on a national trusted list.

That supervisory chain is what the "qualified" prefix buys. The relying party is not being asked to assess the issuer on its own; it can rely on the fact that the issuer is supervised and listed, and verify that status independently.

This is why a QEAA is not simply "a better EAA". The difference is institutional rather than cryptographic: both may be signed with equivalent technology, and what differs is the accountability behind the signature.

A public sector attestation carries the authority of an authentic source

The third category is the attestation issued by, or on behalf of, a public sector body responsible for an authentic source. It is usually written as PuB-EAA.

An authentic source is the register treated, in law, as the correct place to establish a given fact: a commercial register for company existence, a professional register for a licence. A PuB-EAA carries that authority into the wallet.

The distinction from a QEAA is worth holding onto. A QEAA's weight comes from the supervision of its issuer as a trust service provider. A PuB-EAA's weight comes from the fact that the issuing body is the authoritative source of the attribute in the first place. They are different kinds of claim to authority, and they are not interchangeable.

What this means when you build verification

Three consequences follow for anyone building a relying-party integration.

• Record the attestation type, not just the attribute value. "Registration number 12345678, asserted by a PuB-EAA from the commercial register" is an auditable record. "Registration number 12345678, from the wallet" is not.
• Make your acceptance policy explicit per attribute. For a given business decision, decide which attestation types you will accept for which attribute, and write it down. Different decisions warrant different thresholds, and an implicit policy becomes an inconsistent one.
• Verify issuer status at the time of use. A qualified status is a current fact, not a permanent property. Checking it against the relevant trusted list at verification time is the point of the mechanism.

It also changes the question you put to a provider. Not "do you support the wallet", which is close to meaningless, but "which attestation types can you verify, how do you record the type alongside the value, and how do you check issuer status".

Parts of this are still being built, and it is better to say so

The legal framework for these categories is settled. Much of the operational machinery is not: certification schemes for wallets, the registers that let a relying party confirm who may request what, and the availability of public sector attestations across member states are all at different stages.

That is a reason to design for the distinction now. The categories are stable, and verification logic that records which category a claim arrived in will survive the build-out; logic that treats every wallet credential as equivalent will not.

Anyone planning against specific dates or specific availability should check the current position directly rather than relying on a summary, including this one.

What to do now

For each verification your business actually performs, write down the attribute you need, the decision resting on it, and the attestation types you would accept. That exercise usually shows a handful of decisions needing public sector or qualified attestations and most needing neither.

Then check that your identity integration surfaces the attestation type to your application rather than flattening it away. That is the design decision that is expensive to reverse.

Semansys works on credential verification and organisational identity alongside e-invoicing and regulatory reporting, within one service environment. Would you like to work through which attestation types your verification flows should accept? See our approach to standards and interoperability, review our identity capabilities, or book a discovery call.

The European Commission publishes the European Digital Identity Wallet Architecture and Reference Framework, which is the authoritative description of how these attestation types are issued, presented, and verified in practice, and which is revised as the specification develops.

_{This article explains the structure of the attestation categories. It does not state when any obligation applies or which products are certified. Confirm the current position against the Architecture and Reference Framework before designing to it. General information only; not legal advice.}