Designing Well-Made EAAs¶

Overview¶

While signature and revocation mechanisms are not legally mandated for EAAs, a well-designed EAA should incorporate them. This page provides recommendations for creating EAAs that are secure, interoperable, and trustworthy.

Design principle

A well-made EAA should look like a QEAA in its technical implementation, even if it does not carry the legal weight of one.

The Rulebook Concept¶

Every EAA issuer must provide a rulebook (also called a credential scheme) that defines how the credential works. The rulebook serves as:

A technical specification for the credential's design
A trust framework for relying parties to evaluate the credential
A governance document defining issuer responsibilities

Mandatory Rulebook Contents¶

Element	Description
`id`	Unique identifier for the rulebook
`version`	Version number for change tracking
`rulebookURI`	Canonical URL where the rulebook is published
`supportedFormats`	Which credential formats are supported (SD-JWT VC, mDoc)
`schemaURIs`	References to attribute schema definitions
`trustedAuthorities`	Trust anchors for issuer verification
`attestationLoA`	Level of assurance for the credential
`bindingType`	How the credential is bound to the holder

Optional Rulebook Contents¶

Applicable regulations and legal basis
Issuer requirements and qualifications
Verification procedures for relying parties
Revocation policies and update frequencies
Contact information and support channels

Validity Period Design¶

The validity period balances security against usability:

Longer Validity	Shorter Validity
✅ Better user experience	✅ Lower risk of stale data
✅ Fewer reissuance interactions	✅ Faster response to changes
❌ Higher risk of outdated data	❌ More frequent user interaction
❌ Longer exposure if compromised	❌ Higher operational load

Recommendations¶

Maximum validity: Typically ≤ 36 months
Match underlying evidence: If the source document has a validity period, align with it
Enable updates: Issuers should retain underlying data to support credential refresh
Automate where possible: Implement automated update processes to reduce user burden

Mental model

Treat EAAs as credible digital copies rather than permanent originals, unless you specifically implement long-term storage and validation capabilities.

User Identification Requirements¶

How strongly must the issuer identify the user before issuance? This depends on the credential's purpose and risk profile.

Identification Levels¶

Level	Description	Use Cases
None	No identity verification required	Low-value credentials, loyalty cards
Account-based	User has existing account with 2FA	Membership cards, subscriptions
High-assurance	PID presentation or eIDAS Art. 24 process	Official documents, professional credentials

Documentation Requirements¶

The rulebook must specify:

Which identification method is required
The trust level achieved by that method
Whether prior identification may be reused (and under what conditions)
How identification evidence is stored (if at all)

Attribute Verification¶

How does the issuer know the attributes are correct?

Verification Approaches¶

Approach	Description	Trust Level
Self-attested	User provides information without verification	Low
Document-based	User presents documents, issuer verifies	Medium
Authentic source	Issuer retrieves data from authoritative registry	High
Issuer is source	Issuer generated the data themselves	High

Recommendations for High-Trust EAAs¶

Use authentic source verification aligned with eIDAS-secure procedures
Document the verification method in the rulebook
Record the date of verification if reusing prior verification
Specify the trust level achieved

Issuer Requirements¶

Who may issue this EAA? The rulebook must define issuer qualifications.

Possible Issuer Qualifications¶

Public authority status
Professional chamber membership
Industry license or certification
Contractual relationship with scheme operator
Technical certification (e.g., security audit)

Trust Anchor Definition¶

The rulebook must specify how relying parties verify the issuer:

Option A: Trust List

Scheme operator maintains a list of authorized issuers
Relying parties check the list during verification
Dynamic: issuers can be added/removed

Option B: Root Certificate

Scheme defines a root certificate
Issuer certificates chain to this root
Relying parties verify the certificate chain
More static, requires certificate lifecycle management

Applicable Regulations¶

The rulebook should reference specific regulations that influence the credential—but only where they add value.

Include¶

Industry-specific regulations affecting issuance or use
Sector regulations defining required trust levels
Legal requirements for specific attribute types

Exclude¶

Generic regulations that apply universally:

GDPR (applies to all personal data processing)
NIS2 (applies to all relevant organizations)
eIDAS baseline (provides the ecosystem framework)

These provide no additional guidance for the specific credential design.

Signature Recommendations¶

For Standard EAAs¶

Use certificates linked to the trust anchor defined in the rulebook
Follow current BSI/ENISA cryptographic recommendations
Use JAdES for SD-JWT VC credentials
Use CBAdES for ISO mDoc credentials

For High-Trust EAAs¶

Use Qualified Electronic Signatures (QES) or Qualified Electronic Seals
This provides the same technical assurance as QEAA without the regulatory overhead
Relying parties gain confidence even without EU Trusted List inclusion

Post-Quantum Considerations¶

Monitor NIST/BSI guidance on post-quantum algorithms
Plan migration paths for long-lived credentials
Consider hybrid approaches during transition period

Revocation Recommendations¶

When to Implement Revocation¶

Credential Characteristic	Revocation Needed?
Validity < 7 days	Usually not
Attributes may change	Yes
Misuse risk is significant	Yes
Credential represents access rights	Yes

Implementation Guidelines¶

Use status lists (not OCSP) to prevent usage tracking
Update lists at least daily for high-trust credentials
Provide clear revocation policies in the rulebook
Implement revocation within 24 hours for high-trust credentials

Never revoke signing certificates

Revoking a signing certificate invalidates all credentials signed with it. Always use credential-level revocation.

Checklist: Well-Made EAA¶

Use this checklist to evaluate your EAA design: