Zaakceptowanie prezentacji z EUDI Wallet to decyzja o zaufaniu, a podejmuje się ją w kodzie Twojej integracji. Ten artykuł jest przeznaczony dla relying parties, czyli samorządów i dostawców usług, które będą przyjmować prezentacje z portfela, a nie dla zespołów budujących same portfele. Znajdziesz tu pytania, na które chcielibyśmy znać odpowiedź, zanim portfel zostanie włączony dla prawdziwych użytkowników. To lista kontrolna do przeglądu, a nie gotowy projekt rozwiązania.
Ustal, wobec jakiej specyfikacji budujesz integrację
Podstawą techniczną jest Architecture and Reference Framework (ARF). Jest opublikowany w publicznym repozytorium GitHub i rozwijany w ramach Common Union Toolbox. Według repozytorium najnowszą wiążącą wersją jest ostatnie otagowane wydanie. Gałąź repozytorium ani podsumowanie na blogu nie są wiążącym źródłem.
Podstawę prawną stanowi rozporządzenie (UE) nr 910/2014 zmienione rozporządzeniem (UE) 2024/1183 wraz z rozporządzeniami wykonawczymi Komisji. ARF wskazuje aktualną listę tych aktów w sekcjach Introduction i References.
Pierwsze pytania mają więc charakter administracyjny, ale są ważne:
- Na podstawie którego wydania ARF Twój dostawca lub integrator zbudował rozwiązanie?
- Kto po Twojej stronie śledzi nowe otagowane wydania i rozporządzenia wykonawcze oraz jak zmiany trafiają do Twojego backlogu?
- Czy umowa z dostawcą tożsamości wskazuje konkretną wersję, czy tylko ogólne sformułowanie „zgodne z eIDAS 2.0"?
Pytania o asercję
Portfel przekazuje Twojej usłudze prezentację. Zanim stanie się ona sesją, musisz wiedzieć, co dokładnie zweryfikowano.
- Kto ją wystawił? Usługa powinna przyjmować prezentacje wyłącznie od wystawców, którym zdecydowałeś się zaufać, i tylko dla typów atrybutów, które zdecydowałeś się akceptować. „Dowolny poprawny podpis" nie jest polityką. Spisz listę akceptowanych wystawców, wskaż właściciela i określ, jak dodaje się i usuwa wpisy.
- Czy jest powiązana z tą transakcją? Prezentacja, którą można odtworzyć (replay) na Twoim endpoincie logowania, to przejęte poświadczenie czekające na wykorzystanie. Ustal z dostawcą, jak prezentacja jest wiązana z Twoją sesją, i sprawdź testem, że stara prezentacja zostaje odrzucona.
- Co się dzieje, gdy weryfikacja się nie powiedzie lub jest niedostępna? Zdecyduj, czy system działa w trybie fail closed. Sprawdź, czy obsługa błędów i warunki dużego obciążenia nie kierują użytkowników na słabszą ścieżkę awaryjną.
- Co logujesz? Potrzebujesz wystarczająco dużo danych, by zbadać incydent, ale bez przechowywania danych osobowych, które portfel miał ograniczać do minimum.
Uwaga do pierwszego punktu: polityka akceptacji wystawców i atrybutów to kontrola, którą rekomendujemy. Nie jest to wymóg zacytowany z ARF.
Pytania o atrybuty
Komisja opisuje portfel jako narzędzie, które pozwala użytkownikom ujawniać tylko niezbędne informacje, takie jak wiek czy obywatelstwo, i nie ujawniać innych danych osobowych. To wyznacza oczekiwanie, któremu Twoja integracja jako relying party musi sprostać.
Jeśli usługa musi wiedzieć, że ktoś jest pełnoletni lub ma określony wiek, poproś o ten fakt, a nie o datę urodzenia. Jeśli potrzebujesz mieszkańca swojej gminy, poproś o atrybut, który to potwierdza, a nie o pełny adres. Każdy dodatkowy atrybut zwiększa ilość danych, które musisz chronić i uzasadnić we własnej ocenie skutków dla prywatności.
Następnie zapytaj, co dany atrybut faktycznie potwierdza. Atrybut od wystawcy publicznego i atrybut od wystawcy prywatnego mogą znajdować się w tym samym portfelu i w Twoim kodzie wyglądać podobnie. Przypisz każdy z nich do decyzji, którą wspiera. Numer karty bibliotecznej nie powinien dawać dostępu do rozliczeń podatkowych.
Pojedynczy wiersz polityki akceptacji może wyglądać tak. Wartości ilustrują format i nie są rekomendacją:
| Wystawca | Atrybut | Decyzja relying party | Właściciel | Interwał przeglądu |
|---|---|---|---|---|
| Krajowy wystawca dowodów tożsamości (przykład) | Wiek powyżej 18 lat | Zezwól na dostęp do usługi z ograniczeniem wiekowym; nie przechowuj daty urodzenia | Właściciel usługi | Co sześć miesięcy |
Jeśli nie potrafisz wypełnić wszystkich pięciu kolumn dla danego wpisu, nie jest on gotowy, by trafić na listę.
W zastosowaniach organizacyjnych piloty testują tożsamości cyfrowe organizacji jako przypadek użycia: wykazanie, że dana osoba jest uprawnionym przedstawicielem organizacji. Jeśli obsługujesz firmy, zdecyduj już teraz, jak potraktujesz osobę działającą w imieniu przedsiębiorstwa i skąd dowiesz się, że jej umocowanie wygasło.
Pytania o przepływy podpisywania
Podpisywanie umów to jeden ze scenariuszy pilotażowych, więc potraktuj je jako osobny przypadek zapewnienia wiarygodności, odrębny od logowania.
- Od jakich usług zależy Twój przepływ podpisywania lub pieczętowania i kto je obsługuje?
- Co przechowujesz jako dowód złożenia podpisu i jak długo?
- Jeśli za dwa lata ktoś zakwestionuje podpis, czy pokażesz, co zostało wtedy przedstawione i zweryfikowane?
Nie zakładaj, że udane logowanie oznacza poprawny łańcuch podpisu. To osobne kontrole z odrębnymi scenariuszami awarii. Zespoły prawny i bezpieczeństwa powinny uzgodnić, co jest akceptowalnym dowodem, zanim zostanie podpisana pierwsza umowa.
Testuj integrację, a potem testuj ją jeszcze raz
Prototypowy portfel Komisji zawiera biblioteki kodu i przykładową aplikację, a implementacja referencyjna jest open source. Repozytorium ARF odsyła do witryny z testami zgodności. Korzystaj z tych zasobów do testów, a nie jako z zależności produkcyjnej, której nigdy nie przejrzałeś.
W pilotażach na dużą skalę uczestniczy ponad 350 podmiotów z 26 państw członkowskich, Norwegii, Islandii i Ukrainy, a obejmują one m.in. usługi publiczne, bankowość i płatności. Twoje własne endpointy, ścieżki awaryjne i obsługa sesji nadal wymagają osobnych testów.
Potraktuj integrację jak nowy kod uwierzytelniania. Oznacza to model zagrożeń, testy przypadków nadużyć obejmujące replay, zniekształcone prezentacje i nieoczekiwanych wystawców oraz test penetracyjny gotowego przepływu przed uruchomieniem. Cokolwiek przetestował dostawca portfela, Twoja usługa relying party wymaga własnego przeglądu.
Od czego zacząć
- Zdefiniuj punkt odniesienia: zapisz wydanie ARF i rozporządzenia wykonawcze, wobec których budujesz integrację, i wyznacz osobę, która będzie śledzić zmiany.
- Spisz politykę akceptacji: wymień wystawców i typy atrybutów, którym zaufasz, decyzję wspieraną przez każdy z nich, właściciela i interwał przeglądu.
- Ogranicz żądania atrybutów do minimum potrzebnego każdej usłudze i odnotuj wynik we własnej ocenie skutków dla prywatności.
- Przygotuj plan testów na bazie implementacji referencyjnej i zasobów do testów zgodności, w tym przypadki replay, niewłaściwego wystawcy, scenariuszy awarii i ścieżek awaryjnych.
- Oddziel logowanie od podpisywania: zdecyduj, jakie dowody przechowujesz w każdym z nich i kto je zatwierdza.
- Zleć niezależny przegląd przed uruchomieniem produkcyjnym. Jeśli potrzebujesz pomocy w określeniu jego zakresu, porozmawiaj z naszym zespołem doradczym.
