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.

1. Before You Start¶

To participate in the German EUDI Wallet Ecosystem Sandbox, your organization should meet the following prerequisites:

You are based in Germany and operate a digital service or platform requiring user verification.
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. What is a Relying Party?¶

A Relying Party (RP) is any organization that verifies digital credentials presented by users through their EUDI Wallet. RPs rely on trusted Issuers and the ecosystem trust framework for credential authenticity and validity.

Common Examples

Public service portals verifying identity before granting access
Telecom providers verifying a customer's address or age
Universities verifying prior education certificates
Financial services verifying KYC attributes

Example: A bank verifying a customer’s identity to open a digital account.

3. Why Participate¶

Participating in the ecosystem provides organizations with:

Reduced manual verification effort
Faster onboarding and improved user experience
Secure access to verified attributes
Alignment with EU Digital Identity regulations (eIDAS)
Trusted participation in a growing digital identity ecosystem

Note: For a full list of benefits, see the Ecosystem Blueprint.

4. Participation Requirements¶

4.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

4.2 Technical Requirements¶

Requirement	Reason
Integrate a Verifier Component using OpenID4VP	You are expected to bring your own software solution to the Sandbox. A minimum requirement for the sandbox is that you can consume a PID Presentation in line with the PID Rulebook. 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.

4.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.

5. 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 1: Plan	Define service use case and requirements & organisational alignment	Filled in use case template
Stage 2: Integrate	Build out technical components	Verified sandbox integration
Stage 3: 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 engage with the technical part of the onboarding, starting with a kick-off call.

Starting in Q1 2026, there will be a new Kick-off call every month, allowing new RPs to get started when they are ready. The kick-off call is the entry point for access to the National EUDI Wallet Closed Beta. 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.

Stage 1: Plan¶

1.1 Define Verification Use Case
Document where verification occurs, why it is required, and which level of assurance is needed.

1.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.

1.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).

1.4 Register
Fill out and submit the Use Case form. After registration, you can await resource access and an invitation for kick-off.

Stage 2: Integrate¶

2.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 German EUDI Ecosystem Sandbox Registrar.. The 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.

2.1 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.

2.2 Configure Presentation Requests
Translate your use case into presentation requests specifying the required attributes.

Stage 3: Operate¶

3.1 Test in Sandbox
Validate request and response flows using the provided Wallet and the credentials issued to it.

3.2 Maintain Service
Manage certificate lifecycle and operational logs.

3.3 Prepare for Production
Fine-tune logging, preparation for scaling, and compliance processes.

Note: Use this stage to document lessons learned and operational improvements.

6. 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: Annex B details suggestions for logging and monitoring approaches in the sandbox and for operations.

7. Support & Resources¶

Common support resources are currently under development. As they become available, they shall be listed and/or linked to here.

RP Operational Documentation: Including this guide and the documentation portal.
RP Developer Documentation: Step-by-step integration guidance for implementers. For now limited to the example in Annex A.
National EUDI Wallet Access: Test verifier components and credential requests with the National EUDI Wallet. Registration is required for access to the National EUDI Wallet Closed Beta
Technical Support: Contact points for integration and troubleshooting.
Community & Knowledge Sharing: Connect with other Relying Parties and learn from each other.
Updates & Notifications: Stay informed of credential types, protocol updates, and policy changes.

8. Annex A – End-to-End Example: Berlin Digital Bank¶

Organization Overview¶

Field	Description
Name	Berlin Digital Bank (BDB)
Sector	Financial Services
Use Case	Digital account opening (Level of Assurance: High)
Goal	Verify the identity of new customers using the EUDI Wallet

Stage 1: Plan¶

Use Case Definition
Berlin Digital Bank (BDB) enables digital account opening for new customers with a high level of assurance (LoA High). During onboarding, BDB must verify a customer’s name, date of birth, and residence using their Personal Identification Data (PID) credential from an EUDI Wallet.

Protocol and Profile Selection
Since the use case requires a high LoA, BDB’s presentation request must conform to the High Assurance Interoperability Profile (HAIP). For the EUDI Wallet Ecosystem, the full PID presentation flow is described in the EUDI Architecture & Concept documentation. Since customers may hold their PID in either SD-JWT VC or mDoc format, the verifier must accept both formats.

Attribute Selection

SD-JWT format: given_name, family_name, date_of_birth, address
mDoc format: given_name, family_name, date_of_birth, resident_address

BDB has defined its use case, identified required attributes, and determined the applicable interoperability and assurance requirements.

Stage 2: Integrate¶

2.1 Wallet Invocation Setup¶

BDB has designed an account-registration flow that will lead a new customer into a PID presentation. To make the presentation request available to customers, an OpenID4VP Authorization Request is signed and hosted by BDB at its request_uri, following the EUDI Wallet Ecosystem flow rules. The presentation request is hosted as a Pushed Authorization Request.

BDB uses a deeplink to invoke the EUDI Wallet from its onboarding webpage. The deeplink uses a custom URI scheme defined by ETSI:

haip-vp://https://berlin.digitalbank.example/presentation_request

Note: In the HAIP, the custom uri scheme haip:// is required. This is not a requirement for the sandbox environment today.

2.2 Integrate OpenID4VP Verifier Component; SD-JWT and mDoc parsing enabled¶

There are open source OpenID4VP libraries available that support usually different profiles. BDB researches which open source libraries could support their use case. Berlin Digital Bank finds an open source library that supports PID presentation conforming to HAIP. The library helps BDB to perform the steps as described in the EUDI Wallet Ecosystem PID Presentation. This includes:

Generating keys
Generating an Authorization Request
Signing an Authorization Request
Decrypting an Authorization Response
Parsing and verifying an Authorization Response

2.3 Configure credential requests for required attributes only¶

Subsequently, BDB designs an example of what their authorization request could look like:

{
  "iss": "https://berlin.digitalbank.example",
  "aud": "https://wallet.example.org", 
  "iat": 1698163200,
  "exp": 1698166800,
  "client_id": "x509_hash:007ac9762a0e74d0a1a3cfd37e3cc3f2bd97055fcad79ef6355d7a4f0aaeb8da", // The value behind the colon is a hash of "berlin.digitalbank.example"
  "response_type": "vp_token",
  "response_mode": "direct_post.jwt",
  "scope": "openid",
  "nonce": "n-abcdef1234567890",
  "state": "s-xyz987654321",
  "redirect_uri": "https://berlin.digitalbank.example/post-registration",
  "client_metadata": {
    "jwks": {
      "keys": [
        {
          "kty": "EC",
          "kid": "ec-key-1",
          "use": "enc",
          "alg": "ES256",
          "crv": "P-256",
          "x": "f83OJ3D2xF4yG9mXQnKkT7H5Y3WZxR5m7yZy2P1XQ0",
          "y": "x_FEzRu9zM6T5nHcJZJx4Z3VtP4yKQz5xA6cD7E8F9"
        }
      ]
    }
  },    
  "verifier_info":{
    "data": "eY43rfc..."
    "format": "registration_cert"
  }
  ,
  "response_uri": "https://response.example"
  "dcql_query": {
    "credentials": [
        // PID in SD-JWT format
        {
            "id": "pid",
            "format": "dc+sd-jwt",
            "meta": {
                "vct_values": ["https://demo.pid-provider.bundesdruckerei.de/credentials/pid/1.0"]
                },
            "claims": [
                {"path": ["given_name"]},
                {"path": ["family_name"]},
                {"path": ["address", "street_address"]},
                {"path": ["birthdate"]}
            ]
        },
        // PID in mDoc format
        {
            "id": "pid-mdoc",
            "format": "mso_mdoc",
            "meta": {
                  "doctype_value": "eu.europa.ec.eudi.pid.1"
            },
            "claims": [
                  {
                    "id": "first_name",
                "path": ["eu.europa.ec.eudi.pid.1", "given_name"]
              },
              {
                    "id": "last_name",
                "path": ["eu.europa.ec.eudi.pid.1", "family_name"]
              },
              {
                    "id": "resident_address",
                "path": ["eu.europa.ec.eudi.pid.1", "resident_address"]
              },
                    "id": "date_of_birth",
                "path": ["eu.europa.ec.eudi.pid.1", "birth_date"]
            ]
        },
    ]
  },
    "credential_sets": [
    {
      "purpose": "Identification",
      "options": [
        [ "pid" ],
        [ "pid-mdoc" ]
      ]
    },
    ]
}

Pay extra attention to:

client_id: The prefix for the client_id used in this example is x509_hash, which describes the client_id_scheme used in the presentation.

client_metadata: Includes the JWKS for encryption; other metadata is provided in the Registration Certificate.

credential_sets: Allows acceptance of equivalent credentials in SD-JWT or mDoc format.

verifier_info: Contains the encoded Registration Certificate, establishing verifier trust.

vct_values: Please note that the current vct_values for an sd-jwt request is subject to change. In the future, we expect to use the value urn:eudi:pid:de:1 for the German PID Provider. In the long run, relying parties across Europe can query for a PID from any member state using the vct_value urn:eudi:pid:1.

At this point, BDB has integrated an OpenID4VP component that can take care of all the key actions taken during a PID presentation, and knows how to generate properly configured Authorization Requests.

The OpenID4VP library helps to decrypt and parse the content, now BDB needs to make sure that they can handle the data relayed in the Presentation Response. As such, BDB once again relies on the PID Rulebook to understand German EUDI Wallet specific handling of special characters. Finally, BDB implements validator code that checks whether the response follows the PID schema and all required attributes have been relayed correctly.

2.4 Sandbox Entry¶

With a clearly defined use case. BDB fills in the Use Case Form and submits it. BDB is invited to a Kick-Off call, after which they obtain access to the National EUDI Wallet Closed Beta by email invitation, and the German EUDI Ecosystem Sandbox Registrar.

Logging into the Sandbox registrar, BDB configures and issues an access certificate and a registration certificate.

Now that BDB have issued their access certificate and registration certificate, they can update their Authorization Request to include them. As soon as they do, they will be recognisable as a Relying Party in the EUDI Wallet Sandbox.

Stage 3: Operate¶

Test in Sandbox with the National EUDI Wallet
Explore & expand future services (e.g., mortgage applications)
Maintain service, manage logs and certificate lifecycle
Prepare for production with logging and monitoring

8. Annex B – Logging and Monitoring¶

Effective logging and monitoring are critical for transparency, security, and compliance within the EUDI Wallet Ecosystem. The following guidance distinguishes between sandbox and production environments.

1. Sandbox Logging¶

Purpose:
To support troubleshooting, integration testing, and conformance validation without handling live personal data.

Best Practices:

Log only pseudonymized or synthetic data.
Record all OpenID4VP and OpenID4VCI message exchanges for test sessions.
Include timestamps, request IDs, and status codes, trace id, for each transaction.
Capture cryptographic validation results (e.g., signature verification success/failure).
Avoid storing wallet identifiers or end-user personal data.
Rotate logs frequently (e.g., daily) and purge automatically after 14–30 days.
Provide structured log export (JSON).

2. Production Logging¶

Purpose:
To ensure service reliability, detect anomalies, and support audits — while maintaining GDPR and ARF compliance.

Key Principles:

Data Minimization: Log only what is strictly necessary for operational or security purposes.
Pseudonymization: Replace or hash any user identifiers before storage.
Purpose Limitation: Logs may only be used for security, audit, or compliance purposes — not profiling or analytics.
Storage Limitation: Retain logs for the minimum period required (e.g., 90 days operational, 12 months audit).
Access Control: Restrict access to authorized DevOps and compliance personnel only.
Integrity & Confidentiality: Protect logs using encryption in transit (TLS 1.3) and at rest (AES-256).
Traceability: Maintain a verifiable chain of custody for all log archives.
Incident Reporting: Log security-related events in real-time to the Orchestrator’s incident interface.

Recommended Data Points:

Timestamp and unique transaction/session ID
Request type (presentation/issuance)
Wallet invocation method (deeplink, QR, API)
Cryptographic validation outcome (success/failure, certificate used)
Error or exception messages (without sensitive payloads)
System performance metrics (latency, uptime, throughput)

3. Sandbox Monitoring¶

Objective:
Monitor integration health and readiness for compliance certification.

Recommended Metrics:

API responsiveness and uptime
Request/response validation rate
Credential format interoperability (SD-JWT vs mDoc)
Wallet invocation success ratio
Transaction pass/fail rates

4. Production Monitoring¶

Objective:
Ensure ongoing trustworthiness, performance, and security of the RP’s integration in compliance with GDPR and ARF operational guidelines.

Recommended Metrics:

Service uptime (target ≥ 99.9%)
Average response time and load latency
Presentation success rate per credential format
Error rates by category (validation, cryptographic, transport)
Certificate validity and expiration tracking
Real-time security event alerts (e.g., replay attempts, unauthorized access)

Monitoring Practices:

Deploy a secure, privacy-preserving monitoring solution with centralized observability (e.g., Prometheus + Grafana).
Anonymize event identifiers before transmission to third-party monitoring services.
Configure automated alerts for expiring Access/Registration Certificates.
Support incident notification and trust status reporting to the Orchestrator.
Document monitoring responsibilities in the RP’s Data Protection Impact Assessment (DPIA).

9. Annex C – 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