Skip to content

EAA Provider Technical Integration

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 Stage A (Plan) and Stage B.1 (Kick-off Call), please start there first.

Roles in the Ecosystem

Before diving 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
Documented credential type and use case The use case should be achievable within the bounds of the sandbox.
Legal entity registered in Germany According to eIDAS, organizations must register in the country where they are established (Art. 5b(1)).
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

EAA Integration Steps

These steps constitute the EAA-specific portion of Stage B: Integrate from the general onboarding process:

Step 1: Rulebook Adoption or Creation

The Rulebook is the definitive specification for your credential type: it defines what the credential contains, how it is issued, and how it is verified. This step has two distinct paths depending on whether a suitable Rulebook already exists.

Check for an Existing Rulebook

Before investing effort in creating a new Rulebook, check whether a published Rulebook already covers your credential type. An existing Rulebook is suitable if:

  • It covers the same credential type you intend to issue
  • Its trust model, attribute structure, and end-to-end assurance target fit your use case
  • You are willing and able to meet its EAA Provider requirements

If a suitable Rulebook exists, you can adopt it directly and skip to Step 2.

Path A — Adopting an Existing Rulebook

If a suitable Rulebook is available, your responsibilities are:

  • Review the Rulebook in full and confirm it fits your use case
  • Confirm you meet the EAA Provider requirements defined in the Rulebook
  • Request to be added as a provider by the rulebook author (this will result in your addition to the trust list for authorized issuers)
  • Implement your issuance service according to the Rulebook's technical specification and governance expectations
  • Reference the schema metadata entry from the catalog of attestations in your credential issuer configuration

Path B — Creating a New Rulebook

If no suitable Rulebook exists, you will need to develop one. This is the more involved path and becomes the most critical phase of your EAA Provider journey. Before setting off, it is beneficial to coordinate with other organisations that have similar needs and/or ambitions as you, and to coordinate with consumers of your envisaged credential (relying parties). See the Creating Your Rulebook page for detailed guidance.

Activities:

Define credential purpose and scope

  • Document the purpose of your credential
  • Specify applicable regulations
  • Determine supported use cases

Design semantic structure

  • Define all attributes (mandatory and optional)
  • Specify data types and formats
  • Align with existing standards where possible
  • Consider data minimization principles

Establish trust framework and end-to-end assurance target

  • Determine credential validity period
  • Define user identification requirements (as one input into overall assurance)
  • Specify attribute verification methods and authentic sources
  • Plan revocation strategy
  • Define signature requirements

Choose credential format

  • SD-JWT VC (JSON-based, ideal for online use)
  • ISO mDoc (optimized for proximity/NFC scenarios)
  • Or both, based on your use case requirements

Document and publish rulebook

  • Create a comprehensive Rulebook document
  • Get internal review and approval
  • Prepare for external review (if required)
  • Publish the Rulebook at a stable, publicly accessible URI

Step 2: Technical Integration

Implement issuance flow

  • Develop issuance service following ARF specifications
  • Integrate with your authentic source systems
  • Implement user identification process
  • Build attribute verification logic
  • Configure credential signing

Test in sandbox

  • Issue test credentials to sandbox wallets
  • Verify credential structure and signatures
  • Test selective disclosure functionality
  • Validate revocation mechanisms
  • Conduct end-to-end testing with test relying parties
  • Test the full credential lifecycle

Handle edge cases

  • Test error scenarios and recovery
  • Validate data quality controls
  • Test update and renewal processes
  • Verify privacy and security measures

Iterate and refine

  • Incorporate feedback from testing
  • Optimize user experience
  • Improve error handling
  • Enhance documentation

Additional Resources