eID Integration Guide
Complete Developer Documentation
Step-by-step technical guide for integrating your system with the DÁP eIdentification service as a Relying Party.
Table of Contents
Overview
In the eIdentification process, the Accepting Party – referred to as Relying Party in the DÁP documentation terminology – is responsible for being able to receive digital identification in their own system, verify the presented PID and other attribute certificates, and meet the necessary cryptographic and security requirements.
This summary is based on the Hungarian Technical Connection Documentation 1.6-1.
1. Registration and Prerequisites
The accepting party can connect to the eIdentification ecosystem if they meet the following requirements:
- Register on the SZEÜSZ Portal in the Relying Party (RP) role, where they are recorded and receive the necessary certificates
- Complete the development, run the connection process, and upload the protocol documenting successful tests
- Have an X.509 standard signing certificate, which is used to sign requests submitted in OpenID4VP processes
The certificate must be issued by a certification authority listed on the RP Access CA Trusted List.
2. OpenID4VP Client Implementation
The Hungarian eIdentification is based on the OpenID for Verifiable Presentations (OID4VP) standard, so the RP must implement:
- The compilation and signing of the OpenID4VP authorization request with mandatory parameters: client_id, request_uri, request_uri_method=post
- Serving the Request Object via HTTPS POST, ensuring the request_uri domain matches the DNS in client_id
- Receiving and using Wallet Metadata for Request Object preparation
- Secure reception and processing of the authorization response message (VP + SD-JWT attributes)
In practice, this means the RP must run an OpenID4VP-compatible "Verifier client" implementation in their own system.
Looking for a ready-made solution?
Check out our eID connection packages - we offer SDK and turnkey solutions to simplify your integration.
View eID Packages3. Cryptographic Verification of Presented Data
After the presentation, the RP is responsible for performing the following verifications.
3.1 PID and Attribute Certificate Verification
The following must be performed on the PID document:
- Verification of the PID Provider certificate (validity, revocation, authenticity)
- Verification of the PID signature
- Examination of the PID validity period
- Verification of the PID revocation status through the PID ARL list
3.2 Device Binding
The wallet signs the challenge given by the RP with the private key belonging to the PID, thus proving that the presentation is from the same device to which the PID was originally issued.
3.3 Wallet Instance Attestation (WIA) Verification
The RP must verify:
- The authenticity of the wallet provider's certificate based on the Wallet Provider Trust List
- The validity and revocation status of the WIA
- The device binding of the WIA
4. Using Trust and Revocation Lists
The RP must be able to automatically and regularly verify trust and revocation lists.
Trust Lists (ETSI TS 119 612)
PID Provider, Wallet Provider, RP Access CA Trust Lists
Revocation Lists (ARL)
PID ARL and WIA ARL for filtering invalid credentials
These are necessary for filtering out revoked, forged, or invalid wallets and credentials.
5. Same-Device and Cross-Device Flows
The RP must support both OpenID4VP presentation modes:
Same-device flow
The mobile application starts with a deeplink
Cross-device flow
The user connects via QR code from the web interface
In both cases, the same OID4VP request-response mechanism runs.
6. Sandbox and Test Environment
The RP must test before connection in both environments:
Sandbox Environment
Component and error branch testing. Client certificate required for entry. Request_uri domain bound to registered domain.
Test Environment
Mobile application-based realistic testing. Signing certificate is sufficient. Test PID provided instead of real PID.
7. Message Format and Error Handling
The RP must handle:
- Request Object and Authorisation Response JWT / JWE structures
- The format of official error codes and error responses
- Validation of the presentation_submission element
8. Integration Tasks - Developer Checklist
The following practical checklist summarizes the complete RP-side task list:
Registration and Certificates:
- RP registration on the SZEÜSZ Portal
- CSR submission for X.509 signing certificate
- Obtaining client certificate for sandbox
OID4VP Process Implementation:
- Authorization request compilation (client_id, request_uri, request_uri_method=post)
- Request Object signing
- Request Object POST endpoint implementation
- Wallet Metadata reception and interpretation implementation
- Authorization response (VP + SD-JWT + WIA) reception and processing
Cryptographic Verifications:
- PID signature verification
- PID Provider certificate validity
- PID validity period examination
- PID revocation (PID ARL) verification
- WIA certificate verification
- WIA revocation status examination
- Device Binding examination (challenge PoP)
Trust Infrastructures and ARLs:
- Regular PID Provider Trust List download
- Wallet Provider Trust List download
- RP Access CA Trust List management
- Regular PID ARL and WIA ARL updates
Testing and Environments:
- Sandbox test execution with full functionality
- Realistic process testing in test environment
- Comprehensive testing of error branches and invalid presentations
- Auditable logging of all verifications
Ready to integrate?
Contact us and we'll help you connect to the eIdentification service.