An Electronic Attestation of Attributes (EAA) is a signed digital statement about one or more attributes of a person, made by an issuer other than a public identity authority, and delivered into an EUDI Wallet where the holder can present it selectively to any relying party. Unlike Person Identification Data (PID), which only a Member State can issue, an EAA can be issued by a university, an employer, a professional body, an insurer, a retailer or a platform — any organisation with a legitimate claim to know something true about someone.
eIDAS 2.0 splits attestations into two legal tiers. Qualified EAAs (QEAA) require Qualified Trust Service Provider status and carry a legal presumption of accuracy equivalent to a notarised document. Non-qualified EAAs carry no such presumption but are fully valid electronic evidence under the Regulation, verifiable the same way, and dramatically cheaper to issue. This article focuses on what an EAA actually is and does; the qualified/non-qualified trade-off is covered separately.
What an EAA is used for, by industry
- HR and staffing: proof of current employment, job title, or contractor status, presentable to landlords, banks or other employers without a reference call.
- Education: proof of enrolment, degree completion, or course credit, replacing PDF transcripts with a cryptographically verifiable claim.
- Professional services: proof of licence, bar membership, medical registration, or continuing-education hours.
- Retail and loyalty: proof of loyalty tier, verified purchase history, or subscription status, usable to unlock partner discounts.
- Insurance and mobility: proof of no-claims record, vehicle inspection status, or fleet authorisation.
- Public-adjacent services: proof of student status, senior status, or disability accommodation for discount eligibility.
The data model behind an attestation
An EAA is not a document — it is a structured, signed data object, typically encoded as an SD-JWT VC or ISO/IEC 18013-5 mdoc. Three elements define it:
- Claims: the actual attribute values — e.g. { "employment_status": "active", "job_title": "Senior Engineer" }.
- Metadata: issuer identifier, issuance date, expiry date, schema/type reference, and a link to a revocation mechanism.
- Cryptographic binding: a signature over the claims using the issuer's key, plus a holder-binding proof tying the credential to the specific wallet instance it was issued to.
Selective disclosure is what makes SD-JWT VC attractive for EAAs: the issuer signs a full claim set, but the holder can disclose only the subset a given relying party actually needs — proving "employed at Company X" without revealing salary or start date, for instance.
Lifecycle: issuance, presentation, expiry
The lifecycle has three stable phases and one that most issuers underestimate: revocation.
- Issuance: the holder authenticates to the issuer (often via their PID inside the same wallet), the issuer computes the claims, signs them, and pushes the credential to the wallet over OpenID4VCI.
- Presentation: the holder receives a presentation request from a relying party over OpenID4VP, selects the matching credential, discloses only the requested claims, and the relying party verifies the signature chain against the issuer's trust list entry.
- Expiry: EAAs should carry a bounded validity period appropriate to how fast the underlying fact can change — employment status might need a 30-day validity window; a university degree can be valid indefinitely.
- Revocation: the issuer must be able to invalidate a credential before its natural expiry — an employee resigns, a licence is suspended, a membership lapses.
Revocation mechanisms that actually work at scale
Two approaches dominate in practice. Status lists (a compact, cryptographically signed bitstring the relying party checks per verification, per the Token Status List specification) scale to millions of credentials with a single lightweight lookup. Short validity plus reissuance avoids revocation infrastructure entirely by expiring credentials fast enough that stale claims self-resolve — workable for low-stakes attributes, unworkable for anything with liability attached.
An attestation without a credible revocation story is a liability, not a product. Relying parties will ask about it before they ask about your data model.
The business value of becoming an issuer
Issuing EAAs turns a fact your organisation already holds — employment records, membership databases, purchase history — into a portable, monetisable credential. A university that issues verifiable diplomas removes itself from every future verification call. A retailer that issues verifiable loyalty-tier credentials lets partners verify tier without querying its database or signing a data-sharing agreement. The credential does the work the API integration used to do, and it does it under the user's control rather than a backend-to-backend contract.
The obstacle is rarely the use case — it is the infrastructure: OpenID4VCI issuance endpoints, key management, national trust-list registration, revocation status services, and wallet compatibility testing across ecosystems. Platforms like Arkadiz exist specifically to remove that layer, letting an organisation issue standards-compliant EAAs through an API without operating trust-service infrastructure itself.
Getting started
Start with one attribute that already has a clean source of truth inside your systems and a clear external audience that needs to verify it. Define the claim schema, decide the validity window, pick a revocation mechanism, and pilot with a single relying party before opening issuance broadly. The credential model rewards precision: fewer, well-defined claims verify faster and build more trust than a large, loosely typed attribute bundle.