W drugim artykule naszej serii przechodzimy z poziomu „co i dlaczego” do „jak”. Jeśli odpowiadasz za onboarding, KYC, podpisy elektroniczne albo dostęp do usług online, integracja z EUDI Wallet stanie się realnym zadaniem projektowym wprost powiązanym z eIDAS 2.0 i aktami wykonawczymi (implementing acts).
Jeżeli potrzebujesz szerszego tła biznesowo-regulacyjnego, zacznij od pierwszego wpisu: eIDAS 2.0 i EUDI Wallet – przewodnik od podstaw
Co dokładnie zmieniają akty wykonawcze?
Akty wykonawcze doprecyzowują:
- minimalny zakres funkcji portfela (EUDI Wallet) i proces weryfikacji atrybutów,
- standardy wymiany (OpenID4VP/CI, VC/DID),
- wymagania audytowe i interoperacyjność transgraniczną,
- role i rejestry zaufania (trust lists).
W praktyce: usługodawcy (fintech, telco, uczelnie, sektor zdrowia, QTSP) muszą przyjąć model akceptacji EUDI i dostosować ścieżki tożsamości
Dwa modele integracji: Direct RP vs Broker
Direct RP (relying party)
- Bezpośrednie wdrożenie protokołów (OpenID4VP/CI), własny backend do weryfikacji atrybutów.
- Więcej kontroli, większy ciężar utrzymania i testów konformacyjnych.
Broker / gateway
- Pośrednia warstwa ujednolicająca integrację z różnymi portfelami krajowymi.
- Szybsze „time-to-market”, ale zależność od zewnętrznego dostawcy.
Kiedy co wybrać?
- Masz silny zespół IAM i własne procesy podpisu? – Direct.
- Potrzebujesz szybko uruchomić akceptację i działać w wielu krajach? – Broker.
Standardy, o które potkniesz się jako pierwszy
- OpenID for Verifiable Presentations (OpenID4VP) – jak żądać i odbierać prezentacje atrybutów z portfela.
- OpenID for Credential Issuance (OpenID4CI) – jak wydawać poświadczenia (jeśli pełnisz tę rolę).
- Verifiable Credentials (W3C VC) i DID – format i identyfikatory.
- Podpisy i pieczęcie (np. XAdES) – zgodne z eIDAS przy dokumentach i rejestrach.
Architektura referencyjna (relying party)
Warstwa 1 – Front (signup/KYC/signature):
- przyciski „Sign up with EUDI” / „Verify with EUDI”,
- czytelne consent UX.
Warstwa 2 – RP Backend:
- klienci OpenID4VP/CI, walidacja prezentacji, zarządzanie sesją,
- data minimization: zapisujesz tylko wynik walidacji lub hash dowodu, a nie pełny dokument.
Warstwa 3 – Audyt i zgodność:
- dzienniki zdarzeń, odtwarzalna ścieżka zgód,
- opcjonalne „zakotwiczenie” hashy na łańcuchu (off-chain dane, on-chain dowód).
Warstwa 4 – Integracje: QTSP (QES/QSeal), CRM/CDP, antifraud.
PoC w 4 tygodnie: plan minimalny
Tydzień 1 – Discovery i makiety: mapowanie punktów tożsamości (login, KYC, podpis), decyzja Direct vs Broker, makiety UX consent.
Tydzień 2 – Integracja techniczna: żądania OpenID4VP, walidacja atrybutów, logika „minimal disclosure”.
Tydzień 3 – Audyt i metryki: dzienniki, alerty, dashboard (p50/p95 czasu weryfikacji, akceptacja, błędy).
Tydzień 4 – Testy i demo: scenariusze brzegowe, materiał dla compliance i productu, decyzja o rollout.
Metryki, które mają znaczenie
- Czas weryfikacji (p50/p95) – większość przypadków vs „długie ogony”.
- Współczynnik ukończenia ścieżki – czy EUDI skraca tarcie vs dotychczasowe KYC.
- Stabilność i błędy – ile prezentacji kończy się bez sukcesu i gdzie pęka łańcuch.
Najczęstsze pułapki
- Traktowanie EUDI jak uploadu skanu. To nie ten model. Cel: „potwierdzenie faktu”, nie „kopiowanie dokumentu”.
- Brak polityk retencji i minimalizacji. Trzymaj dane off-chain, zachowuj hash i zgodę.
- Pominięcie UX: zły consent potrafi zabić adopcję.
Checklista wdrożeniowa (krótko)
- Wybierz model: Direct RP czy Broker.
- Zaprojektuj consent UX i komunikaty błędów.
- Zaimplementuj OpenID4VP i walidację VC.
- Ustal retencję, audyt i sposób zakotwiczenia dowodów.
- Ustal metryki i SLO.
- Zrób PoC i dopiero później skaluj.
Dalsza lektura: jeśli nie czytałeś jeszcze wprowadzenia, zajrzyj do eIDAS 2.0 i EUDI Wallet – przewodnik od podstaw.
Potrzebujesz wsparcia przy PoC? Napisz do nas, pokażemy, jak zbić p95 i skrócić ścieżkę rejestracji bez ryzyka dla zgodności.
