Skip to content

EAA Provider Onboarding

This guide provides EAA-specific onboarding requirements and technical integration steps for organizations that want to issue Electronic Attestations of Attributes (EAAs) in the German EUDI Wallet Ecosystem.

Start Here

This guide assumes you have already reviewed the general onboarding process. If you haven't completed the Plan stage and the Kick-off Call, please start there first.

Roles in the Ecosystem

Before diving further into the onboarding process, it helps to understand the distinct roles involved in EAA issuance and presentation. Depending on your situation, you may take on one or more of these roles.

EAA Provider (Issuer)

An EAA Provider is an organization that issues EAAs to holders. Importantly, an EAA Provider does not need to write their own Rulebook. If a publicly available Rulebook already covers your credential type, you can adopt it directly and focus your effort on the technical integration. You only need to develop a new Rulebook if no suitable one exists.

Relying Party (Verifier)

A Relying Party is an organization or service that requests and validates credentials from holders. RPs rely on published Rulebooks to understand what a credential means and how to verify it.

Schema Owner

A Schema Owner defines the technical and governance specification for a credential type — what attributes it contains, how it is issued, how it is verified, and what trust model it follows. A Schema Owner may be any organization (a standards body, sector authority, industry association, or any EAA Provider) that has created a credential type and made its credential schema, rulebook, and trust list publicly available for others to adopt.

A Schema Owner does this by publishing an entry in the catalog of attestations. The catalog of attestations contains a list of schema metadata entries. The schema metadata contains references to the rulebook, credential schema, and trust list as represented in the figure below.

Catalog of Attestations

EAA-Specific Requirements

Organizational Requirements

Requirement Reason
Document credential type and use case The use case should be achievable within the bounds of the sandbox.
Designated operational contact The Orchestrator requires a single point of contact with respect to EAA Provider operations.
Designated technical contact The Orchestrator requires a single point of contact for technical communication
Authority to issue the credential type You must have legal or organizational authority to issue the credential type you're proposing

Technical Requirements

Requirement Reason
Implement an Issuer Component using OpenID4VCI You are expected to bring your own software solution to the Sandbox. You can either develop your own solution, integrate an open source component, or employ a third party service provider.
Run secure HTTPS network services All issuance endpoints need to be secured using HTTPS.
Access to authentic data sources You must have access to authoritative sources for the attributes you plan to issue

Security & Compliance Requirements

Requirement Reason
Implement data minimization and purpose binding EAA Providers must have a clear purpose for each credential and implement appropriate privacy protections
Follow the ecosystem policies Aside from the technical requirements, Sandbox participation involves behavioral rules that support an open and collaborative ecosystem

Your Roadmap as an EAA Provider

Each phase below links to the page that owns the detail. You do not need to read everything at once — follow the roadmap and branch at phase 2.

Phase What you do Where
1. Plan & confirm readiness Define your use case and confirm you meet the requirements above. This page · Joining the Ecosystem
2. Choose your Rulebook Decide whether to adopt an existing Rulebook or create a new one, then act on that choice. Rulebooks: Adopt or Create
3. Implement issuance Build your OpenID4VCI issuer according to your Rulebook, and test it end to end. EAA Issuance · worked examples: low-fidelity, high-assurance (HAIP)
4. Test & operate Validate in the sandbox, then run the credential lifecycle: refresh, revocation, key rotation, and incident response. Credential Lifecycle & Operations · Joining the Ecosystem — Operate

Where this fits in the general onboarding

Choosing a Rulebook and implementing issuance are the EAA-specific part of the Integrate stage of the general onboarding process; planning sits in Plan, and testing and operations in Operate. See the general onboarding guide for what each stage involves across all roles.

Additional Resources