Skip to content

Relying Party Technical Integration

This guide provides Relying Party-specific requirements and technical integration steps for organizations that want to verify credentials 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.

Relying Party-Specific Requirements

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)). This is not a requirement for joining the sandbox, but it is for entering production.
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

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.

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.

Relying Party Integration Steps

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

Step 1: Define Your Verification Use Case

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.

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

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

Integration Options:

  • Build from scratch using OpenID4VP specifications
  • Use open-source verifier libraries (see Open Source Libraries)
  • Employ a commercial service provider

Step 3: Test and Validate

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

Key Testing Areas:

  • Credential request flows (same-device and cross-device)
  • Attribute validation and processing
  • Error handling and edge cases
  • User experience and presentation clarity
  • Selective disclosure functionality
  • Certificate and trust chain validation

Step 4: Operate and Maintain

Maintain Service Manage certificate lifecycle and operational logs. See Logging and Monitoring for approaches in the sandbox and for operations.

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

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

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

Additional Resources

Expanding Your Role

Many Relying Parties joining the sandbox later become EAA Providers themselves, offering varied opportunities to consume new types of credentials to enable new business flows. If you're interested in issuing credentials in addition to verifying them, see the EAA Provider guide.