Relying Party Onboarding Guide¶
Living Document
This guide is part of the German EUDI Wallet Ecosystem onboarding materials and provides a practical introduction for organizations that want to join the ecosystem as Relying Parties. This document will be developed iteratively, taking into account developments in the ecosystem as well as the feedback and needs of the Relying Parties. The content is therefore subject to change.
Upcoming Kick-off Calls Kick-off calls are held on a monthly schedule.
Kick-off calls are planned for the following dates:
- Thursday March 12th, 2026
The schedule will continue into April and beyond, but exact dates are still to be confirmed.
1. Before You Start¶
To participate in the German EUDI Wallet Ecosystem Sandbox, your organization should meet the following prerequisites:
One of the following must be true: - You are based in Germany and operate a digital service or platform requiring user verification. - You are a service provider actively serving or expecting to serve Relying Parties registered in Germany.
All of the following must be true:
- You can integrate web-based APIs and manage secure HTTPS endpoints.
- You are able to designate a technical contact for integration activities.
- You are able to designate an operational contact for compliance communication.
- You are authorized to process user identity or attribute data under applicable law.
Sandbox Environment
The ecosystem is under constant development. Solutions developed in the sandbox today may require modifications before entering the production environment when it becomes available.
Initial Functionality
The sandbox initially launches with PID functionality only. Therefore, PID-related use cases will be prioritized for support in the earliest stages.
2. Participation Requirements¶
2.1 Organizational Requirements¶
| Requirement | Reason |
|---|---|
| Documented service use case for credential verification | 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 RP operations. |
| Designated technical contact | The Orchestrator requires a single point of contact for technical communication |
2.2 Technical Requirements¶
| Requirement | Reason |
|---|---|
| Integrate a Verifier Component using OpenID4VP | 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 Presentation Requests need to be secured using HTTPS. |
2.3 Security & Compliance Requirements¶
| Requirement | Reason |
|---|---|
| Implement data minimization and purpose binding | Relying Parties must not request data attributes that are not needed for the completion of the business flow. Presentation Requests should be configured to clearly present the purpose of the data request to the Wallet User. |
| Follow the ecosystem policies | Aside from the technical requirements, Sandbox participation involves behavioral rules that support an open and collaborative ecosystem. |
3. Onboarding Stages¶
The onboarding process involves you getting a formal introduction and access to support resources, culminating in a trusted status in the EUDI Wallet Ecosystem Sandbox.
We define the process in three main stages:
| Stage | Goal | Output |
|---|---|---|
| Stage A: Plan | Define service use case and requirements & organisational alignment | Internal alignment & resource allocation |
| Stage B: Integrate | Build out technical components | Verified sandbox integration |
| Stage C: Operate | Use case expansion, lifecycle management | Sandbox operations |
The first stage is meant for prospective RP's to research the support materials, get organised internally, index the needs they have, and reserve the necessary resources for participation.
When the planning stage has been completed, RP's can reach out to us and start engaging with the technical part of the onboarding.
Kick-off calls happen on a monthly schedule, and upcoming dates are posted in the Ecosystem Knowledge Center. The kick-off call is the entry point for access to the Support Resources associated with the sandbox. This process allows us to scale the sandbox in a controlled way, as we roll out our support features. Additionally, there will be regularly recurring sessions for technical support and Q&A. Once the technical integration has been achieved, RP's can move on to operating in the sandbox.
3.1 Stage A: Plan¶
A.1 Define Verification Use Case
Document where verification occurs, why it is required, and which level of assurance is needed.
A.2 Identify Integration Point
Specify when verification occurs in the service flow (login, registration, checkout, access request). Identify the type(s) of interactions you need to support. For example, same device and/or cross-device flows, or in-person/remote interactions.
A.3 Select Credential Types
Request only necessary attributes (e.g., identity data, age confirmation, or proof of address). Choose a supported credential format (SD-JWT VC or mDoc).
A.4 Organize internally As you have decided the initial scope of your work. We ask you to align your team and resources before seeking contact with us.
A.5 Declare your intent to join Please declare your intent to join the sandbox and share the working title of your use case via the intent form. Per use case, one intent form should be submitted. Once you have submitted the form, our team will reach out to you.
3.2 Stage B: Integrate¶
B.1 Attend a Kick-Off Call and gain access After attending the kick-off call, you will be offered access to the EUDI Wallet Closed Beta. Additionally, you will gain access to the German EUDI Ecosystem Sandbox Registrar. Access to this environment allows you to configure and issue access and registration certificate(s) to include in your presentation requests. The certificates enable the use of your RP with the Wallet.
B.2 Integrate Verifier Component
Deploy or integrate a Verifier Component supporting OpenID4VP and SD-JWT and mDoc credential formats. This verifier component can be built from scratch, leverage open-source software, or be provided by a commercial service provider. When consuming a PID presentation, your implementation must comply with the German PID Rulebook.
3.3 Stage C: Operate¶
The Sandbox is a place for you to iterate and collaborate.
C.1 Test in Sandbox
Validate request and response flows using the provided Wallet and the credentials issued to it.
C.2 Maintain Service
Manage certificate lifecycle and operational logs.
C.3 Prepare for Production
Fine-tune logging, preparation for scaling, and compliance processes.
C.4 Collaborate on new use cases with other participants
Many Relying Parties joining the sandbox may become EAA providers themselves, offering varied opportunities to consume new types of credentials to enable new business flows.
Note: Use this stage to document lessons learned and operational improvements.
4. Compliance Responsibilities¶
Relying Parties must adhere to a minimum set of operational responsibilities:
| Requirement | Responsibility |
|---|---|
| Secure Operation | HTTPS endpoints, secure key and credential management |
| Purpose Limitation | Request only attributes necessary for the service |
| Logging & Auditing | Maintain minimal logs, pseudonymize identifiers, do not store full credential data |
| RP Credential Management | Renew and revoke Access Certificates as required |
| Trust Registry Updates | Maintain status in the RP Registry |
| Policy Adherence | Agree to terms and conditions |
Note: See Logging and Monitoring for approaches in the sandbox and for operations.
5. Terms & Definitions¶
- Relying Party (RP): Organization verifying credentials
- Issuer: Entity issuing verifiable credentials
- Access Certificate: Digital credential authorizing RP participation
- Registration Certificate: Certificate confirming RP registration in Trust Registry
- OpenID4VP: OpenID for Verifiable Presentations protocol
- SD-JWT: Selective Disclosure JSON Web Token format
- mDoc: Mobile Document format used in wallets