Rozporządzenie wykonawcze Komisji (UE) 2024/2982 z dnia 28 listopada 2024 r. ustanawiające zasady stosowania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 w odniesieniu do protokołów i interfejsów, które mają być obsługiwane przez europejskie ramy tożsamości cyfrowej

Artykuł 1

Przedmiot i zakres stosowania

W niniejszym rozporządzeniu ustanawia się zasady dotyczące protokołów i interfejsów rozwiązań w zakresie portfela w odniesieniu do:

1) wydawania danych identyfikujących osobę i elektronicznych poświadczeń atrybutów do jednostek portfela;

2) prezentacji atrybutów danych identyfikujących osobę i elektronicznych poświadczeń atrybutów stronom ufającym portfela;

3) przekazywania żądań usunięcia danych stronom ufającym portfela;

4) zgłaszania stron ufających portfela organom nadzorczym ustanowionym na podstawie art. 51 rozporządzenia (UE) 2016/679;

podlegają one regularnej aktualizacji w celu zapewnienia zgodności z rozwojem technologii i opracowywanymi normami oraz z pracami prowadzonymi na podstawie zalecenia Komisji (UE) 2021/946, w szczególności z architekturą i ramami odniesienia.

Artykuł 2

Definicje

Do celów niniejszego rozporządzenia stosuje się następujące definicje:

1) „strona ufająca portfela” oznacza stronę ufającą, która zamierza polegać na jednostkach portfela w celu świadczenia usług publicznych lub prywatnych za pośrednictwem cyfrowej interakcji;

2) „użytkownik portfela” oznacza użytkownika, który kontroluje jednostkę portfela;

3) „rozwiązanie w zakresie portfela” oznacza połączenie oprogramowania, sprzętu, usług, ustawień i konfiguracji, z uwzględnieniem instancji portfela, co najmniej jednej bezpiecznej aplikacji kryptograficznej portfela oraz co najmniej jednego bezpiecznego urządzenia kryptograficznego portfela;

4) „jednostka portfela” oznacza niepowtarzalną konfigurację rozwiązania w zakresie portfela, która obejmuje instancje portfela, bezpieczne aplikacje kryptograficzne portfela i bezpieczne urządzenia kryptograficzne portfela dostarczane przez dostawcę portfela indywidualnemu użytkownikowi portfela;

5) „dostawca portfela” oznacza osobę fizyczną lub prawną, która dostarcza rozwiązania w zakresie portfela;

6) „instancja portfela” oznacza aplikację zainstalowaną i skonfigurowaną na urządzeniu lub w środowisku użytkownika portfela, która jest częścią jednostki portfela i z której użytkownik portfela korzysta do interakcji z daną jednostką portfela;

7) „bezpieczna aplikacja kryptograficzna portfela” oznacza aplikację, która zarządza aktywami krytycznymi, łącząc się z funkcjami kryptograficznymi i niekryptograficznymi zapewnianymi przez bezpieczne urządzenie kryptograficzne portfela oraz korzystając z tych funkcji;

8) „bezpieczne urządzenie kryptograficzne portfela” oznacza urządzenie odporne na manipulacje, które zapewnia otoczenie połączone z bezpieczną aplikacją kryptograficzną portfela i przez nią wykorzystywane, aby chronić aktywa krytyczne i zapewniać funkcje kryptograficzne na potrzeby bezpiecznego wykonywania operacji krytycznych;

9) „aktywa krytyczne” oznaczają aktywa wewnątrz jednostki portfela lub z nią związane o tak istotnym znaczeniu, że naruszenie ich dostępności, poufności lub integralności miałoby bardzo poważny, szkodliwy wpływ na zdolność do polegania na danej jednostce portfela;

10) „certyfikat dostępu strony ufającej portfela” oznacza certyfikat pieczęci lub podpisów elektronicznych uwierzytelniający i walidujący stronę ufającą portfela, wydany przez dostawcę certyfikatów dostępu strony ufającej portfela;

11) „dostawca certyfikatów dostępu strony ufającej portfela” oznacza osobę fizyczną lub prawną upoważnioną przez państwo członkowskie do wydawania certyfikatów dostępu strony ufającej stronom ufającym portfela zarejestrowanym w tym państwie członkowskim;

12) „poświadczenie jednostki portfela” oznacza obiekt danych, który opisuje komponenty jednostki portfela lub umożliwia uwierzytelnienie oraz walidację tych komponentów;

13) „wbudowane reguły ujawniania” oznaczają zbiór zasad wbudowanych w elektronicznym poświadczeniu atrybutów przez dostawcę tego poświadczenia; zasady te określają warunki, jakie musi spełnić strona ufająca portfela, aby uzyskać dostęp do elektronicznego poświadczenia atrybutów;

14) „certyfikat rejestracji strony ufającej portfela” oznacza obiekt danych, który wskazuje atrybuty, które zarejestrowała strona ufająca z zamiarem ich żądania od użytkowników;

15) „dostawca danych identyfikujących osobę” oznacza osobę fizyczną lub prawną odpowiedzialną za wydanie i unieważnienie danych identyfikujących osobę oraz za zapewnienie, aby dane identyfikujące osobę odnoszące się do użytkownika były powiązane kryptograficznie z jednostką portfela;

16) „powiązanie kryptograficzne” oznacza metodę łączenia danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów z jednostkami portfela za pomocą środków kryptograficznych.

Artykuł 3

Przepisy ogólne

W odniesieniu do protokołów i interfejsów, o których mowa w art. 4 i 5, dostawcy portfela muszą zapewnić, aby jednostki portfela:

1) uwierzytelniały i walidowały certyfikaty dostępu strony ufającej portfela w przypadku interakcji ze stronami ufającymi portfela, nie powierzając wykonania tych procesów przeglądarce systemu operacyjnego lub innej aplikacji pośredniczącej;

3) uwierzytelniały i walidowały żądania przekazane za pomocą certyfikatów dostępu strony ufającej portfela;

4) uwierzytelniały i walidowały certyfikat rejestracji strony ufającej portfela;

5) wyświetlały użytkownikom portfela informacje zawarte w certyfikatach dostępu strony ufającej portfela;

6) wyświetlały użytkownikom portfela, w stosownych przypadkach, atrybuty, które użytkownicy portfela mają obowiązek przedstawić;

7) w stosownych przypadkach, wyświetlały użytkownikom portfela informacje zawarte w certyfikacie rejestracji strony ufającej portfela;

9) nie przedstawiały stronom ufającym portfela żadnych żądanych atrybutów do czasu zakończenia następujących etapów:

a) weryfikacji, czy wbudowane reguły ujawniania zostały przetworzone w jednostce portfela zgodnie z art. 10 rozporządzenia wykonawczego (UE) 2024/2979;

b) weryfikacji, czy użytkownicy portfela zatwierdzili prezentację częściowo lub w całości;

10) umożliwiły stosowanie technik ochrony prywatności, które zapewniają brak możliwości powiązania, w przypadku gdy elektroniczne poświadczenia atrybutów nie wymagają identyfikacji użytkownika portfela przy przedstawianiu poświadczeń lub danych identyfikujących osobę w różnych stronach ufających portfela.

Artykuł 4

Wydawanie danych identyfikujących osobę i elektronicznych poświadczeń atrybutów do jednostek portfela

1. Dostawcy portfela dopilnowują, aby rozwiązania w zakresie portfela obsługiwały protokoły i interfejsy określone w załączniku I na potrzeby wydawania danych identyfikujących osobę i elektronicznych poświadczeń atrybutów jednostkom portfela.

2. Dostawcy portfela zapewniają, aby jednostki portfela zwracały się o wydanie danych identyfikujących osobę i elektronicznych poświadczeń atrybutów wyłącznie do stron posiadających autentyczny i ważny certyfikat dostępu strony ufającej portfela, uwierzytelniający strony jako:

a) dostawcę danych identyfikujących osobę;

b) dostawcę kwalifikowanego elektronicznego poświadczenia atrybutów;

c) dostawcę elektronicznego poświadczenia atrybutów wydanego przez podmiot sektora publicznego odpowiedzialny za oryginalne źródło lub w jego imieniu; lub

d) dostawcę niekwalifikowanego elektronicznego poświadczenia atrybutów.

3. W odniesieniu do wydawania danych identyfikujących osobę i elektronicznych poświadczeń atrybutów jednostce portfela dostawcy portfela muszą zapewnić, aby spełnione zostały następujące wymogi:

a) w przypadku gdy użytkownicy portfela korzystają ze swojej jednostki portfela w celu zwrócenia się o wydanie danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów do dostawców danych identyfikujących osobę lub dostawców elektronicznych poświadczeń atrybutów, którzy umożliwiają wydawanie danych identyfikujących osobę lub poświadczeń elektronicznych w więcej niż jednym formacie, jednostka portfela składa wniosek o wydanie tych danych we wszystkich formatach, o których mowa w art. 8 rozporządzenia wykonawczego (UE) 2024/2979 ustanawiającego zasady stosowania rozporządzenia (UE) nr 910/2014 w odniesieniu do integralności i podstawowych funkcji europejskich portfeli tożsamości cyfrowej;

b) w przypadku gdy użytkownicy portfela korzystają ze swojej jednostki portfela w celu interakcji z dostawcami danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów, jednostki portfela umożliwiają uwierzytelnianie i walidację komponentów jednostek portfela, przedstawiając poświadczenia jednostki portfela dostawcom na ich wniosek;

c) rozwiązania w zakresie portfela obsługują mechanizmy umożliwiające dostawcom danych identyfikujących osobę weryfikację wydania, dostarczenia i aktywacji zgodnie z wymogami dotyczącymi wysokiego poziomu bezpieczeństwa określonymi w rozporządzeniu wykonawczym Komisji (UE) 2015/1502 (

1

);

d) jednostki portfela weryfikują autentyczność i ważność danych identyfikujących osobę oraz elektronicznych poświadczeń atrybutów.

Artykuł 5

Prezentacja atrybutów stronom ufającym portfela

1. Dostawcy portfela zapewniają, aby rozwiązania w zakresie portfela obsługiwały protokoły i interfejsy do celów prezentacji atrybutów stronom ufającym portfela, zdalnie i, w stosownych przypadkach, zbliżeniowo, zgodnie ze specyfikacjami technicznymi określonymi w załączniku II.

2. Dostawcy portfela dopilnowują, aby – na wniosek użytkowników – jednostki portfela odpowiadały na skutecznie uwierzytelnione i zwalidowane żądania stron ufających portfela, o których mowa w art. 3, zgodnie ze specyfikacjami technicznymi określonymi w załączniku II.

3. Dostawcy portfela zapewniają, aby jednostki portfela obsługiwały potwierdzenie posiadania kluczy prywatnych odpowiadających kluczom publicznym wykorzystywanym w powiązaniach kryptograficznych.

4. Dostawcy portfela dopilnowują, aby rozwiązania w zakresie portfela obsługiwały selektywne ujawnianie atrybutów danych identyfikujących osobę oraz elektronicznych poświadczeń atrybutów.

Artykuł 6

Przekazywanie żądań usunięcia danych

1. Dostawcy portfela zapewniają, aby jednostki portfela obsługiwały protokoły i interfejsy umożliwiające użytkownikom portfela zwrócenie się do stron ufających portfela, z którymi kontaktowali się oni za pośrednictwem tych jednostek portfela, o usunięcie ich danych osobowych przekazanych za pośrednictwem tych jednostek portfela, zgodnie z art. 17 rozporządzenia (UE) 2016/679.

2. Protokoły i interfejsy, o których mowa w ust. 1, muszą umożliwiać użytkownikom portfela wybór stron ufających portfela, którym będą przekazywane żądania usunięcia danych.

3. Jednostki portfela wyświetlają użytkownikowi portfela uprzednio przekazane żądania usunięcia danych złożone za pośrednictwem tych jednostek portfela.

Artykuł 7

Zgłaszanie stron ufających portfela organom nadzorczym ustanowionym na podstawie art. 51 rozporządzenia (UE) 2016/679

1. Dostawcy portfela dopilnowują, aby jednostki portfela umożliwiały użytkownikom portfela łatwe zgłaszanie stron ufających portfela organom nadzorczym ustanowionym na podstawie art. 51 rozporządzenia (UE) 2016/679.

2. Dostawcy portfela wdrażają protokoły i interfejsy na potrzeby zgłaszania stron ufających portfela zgodnie z krajowymi przepisami proceduralnymi państw członkowskich.

3. Dostawcy portfela zapewniają, aby jednostki portfela umożliwiały użytkownikom portfela uzasadnienie sprawozdań, w tym przez załączenie odpowiednich informacji w celu identyfikacji stron ufających portfela, oraz oświadczeń użytkowników portfela w formacie nadającym się do odczytu maszynowego.

Artykuł 8

Wejście w życie

Niniejsze rozporządzenie wchodzi w życie dwudziestego dnia po jego opublikowaniu w Dzienniku Urzędowym Unii Europejskiej.

Art. 3 ust. 4 stosuje się od dnia 11 sierpnia 2028 r.

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich państwach członkowskich.

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich państwach członkowskich.

Załącznik I

Protokoły i interfejsy, o których mowa w art. 4

Specyfikacja techniczna ETSI TS 119 472 -3 V1.1.1 (2026-03) ma zastosowanie z następującymi dostosowaniami:

1) 4.1.

General requirements

— GEN-REQ-4.1-05: nieważny.

— UWAGA: nieważny.

2) 4.2.3.

Provision of registration certificates of PID/EAA Provider to EUDI Wallet

— ISS-MDATA-REG_CERT-4.2.3-04: Jeden z elementów tablicy parametrów issuer_info musi zawierać certyfikat rejestracji dostawcy PID/EAA.

— ISS-MDATA-REG_CERT-4.2.3-07: nieważny

— ISS-MDATA-REG_CERT-4.2.3-08: nieważny

— ISS-MDATA-REG_CERT-4.2.3-09: nieważny

— ISS-MDATA-REG_CERT-4.2.3-10: nieważny

— ISS-MDATA-REG_CERT-4.2.3-11: nieważny

— ISS-MDATA-REG_CERT-4.2.3-12: nieważny

— ISS-MDATA-REG_CERT-4.2.3-13: nieważny

3) 4.2.4.2. ARF pre-defined PID/EAA reuse policy

— ISS-MDATA-EAA-REUSE-POL-4.2.4.2-09: W przypadku gdy element „id” ma wartość „arf_annex_ii”, a tablica przypisana do etykiety „details” zawiera wartość „once_only” lub „per-relying-party”, obiekt JSON zawierający tę tablicę przypisaną do etykiety „details” zawiera również liczbę JSON przypisaną do etykiety „reissue_trigger_unused”.

4) Załącznik A nie ma zastosowania.

Załącznik II

Specyfikacje techniczne, o których mowa w art. 5

Zastosowanie ma specyfikacja techniczna określona w załączniku C do normy ISO/IEC 18013-7:2025.

Specyfikacje techniczne określone w pkt 4.1, 4.2, 5, i 6 normy ETSI TS 119 472 -2 V1.2.1 (2026-03) mają zastosowanie z następującymi dostosowaniami, z uwzględnieniem dodania nowego pkt 4.3:

1) 1.

Scope

— Niniejszy dokument określa dwa profile protokołów umożliwiające stronom ufającym (zwanym dalej „RP”) żądanie EAAP lub danych identyfikujących osobę (zwanych dalej „PID”) od europejskiego portfela tożsamości cyfrowej oraz umożliwiające mu przekazanie żądanych EAAP/PID do RP. Każdy z profili obsługuje dwa mechanizmy transmisji, mianowicie: z wykorzystaniem API oraz bez wykorzystania API, jak przedstawiono poniżej:

a) Profil opiera się na:

— ISO/IEC 18013-5 [10] wyłącznie w odniesieniu do mechanizmu transmisji bez wykorzystania API, oraz

— załączniku C do ISO/IEC 18013-7 [16] w odniesieniu do mechanizmu transmisji z wykorzystaniem API.

Profil ten nosi nazwę profilu ISO/IEC-mdoc i jest określony w pkt 5 niniejszego dokumentu.

b) Profil opiera się na:

OpenID4VC-HAIP [11] w odniesieniu do obu mechanizmów transmisji (z wykorzystaniem API i bez wykorzystania API), w następujący sposób:

— pkt 5, 5.1, 5.3, 7 i 8 [11] w odniesieniu do transmisji poprzez przekierowania lub mechanizm bez wykorzystania API, oraz

— pkt 5, 5.2, 5.3, 7 i 8 [11] w odniesieniu do mechanizmu transmisji z wykorzystaniem API.

Profil ten nosi nazwę profilu OpenID4VC-HAIP i jest określony w pkt 6 niniejszego dokumentu.

2) 2.1.

Normative references

— [15] ISO 639: „Language code”.

— [16] ISO/IEC 18013-7:2025 „Personal identification – ISO – compliant driving licence – Part 7: Mobile driving licence (mDL) add-on functions”.

3) 4.1.

EAAP implementation based on SD-JWT VC

— EAAP-SD-JWT VC-04: nieważny.

4) 4.2.

EAAP implementation based on ISO/IEC-mdoc

— EAAP-ISO/IEC-mdoc-01: nieważny.

— Note2: nieważny.

— EAAP-ISO/IEC-mdoc-02: nieważny.

5) 4.3.

EAAP implementation with mediating API

— EAAP-API-GEN-01: Europejski portfel tożsamości cyfrowej musi obsługiwać pośredniczący API, który obsługuje oba protokoły określone w pkt 5.2 [11] i w załączniku C do [16].

— UWAGA: W przypadku gdy urządzenie, na którym zainstalowano europejski portfel tożsamości cyfrowej, nie obsługuje obu protokołów, wymóg ten nie może zostać spełniony i powoduje niezgodność ze względu na fakt, że podstawowe systemy operacyjne i przeglądarki nie wdrażają niezbędnych funkcji interoperacyjności.

— EAAP-API-GEN-02: Europejski portfel tożsamości cyfrowej obsługuje API pośredniczący co najmniej w odniesieniu do rodzajów PID i EAA zarejestrowanych w katalogu systemów określonym w rozporządzeniu wykonawczym (UE) 2025/1569 oraz co najmniej w odniesieniu do wszystkich formatów określonych w załączniku II do rozporządzenia wykonawczego (UE) 2024/2979.

— UWAGA 1: Wymóg ten nie może zostać spełniony, jeżeli podstawowy system operacyjny, przeglądarka, pośredniczące API lub jakakolwiek inna warstwa techniczna pozostająca poza kontrolą europejskiego portfela tożsamości cyfrowej limituje, filtruje, wstępnie wybiera lub w inny sposób ogranicza formaty poświadczeń oraz rodzaje PID i EAA zarejestrowane w katalogu systemów. W przypadku gdy takie ograniczenie uniemożliwia europejskiemu portfelowi tożsamości cyfrowej obsługę zarejestrowanego rodzaju lub formatu poświadczenia, wynikającą z tego niezgodność można przypisać niedostarczeniu niezbędnych funkcji interoperacyjności przez te podstawowe systemy operacyjne, przeglądarki, pośredniczący API lub inną odpowiednią warstwę techniczną.

6) 4.4.

Walidacja strony ufającej portfela i kontrole nadmiernych zapytań

— WRP-VALIDATION-01: Europejski portfel tożsamości cyfrowej zatwierdza certyfikat rejestracji strony ufającej portfela otrzymany w żądaniu przed przedstawieniem żądanego PID lub elektronicznego poświadczenia atrybutów użytkownikowi portfela do zatwierdzenia.

— WRP-VALIDATION-02: W przypadku gdy walidacja certyfikatu rejestracji strony ufającej portfela nie powiedzie się, w tym w przypadku gdy certyfikat wygasł, został cofnięty, nie został wydany przez ważnego zaufanego dostawcę certyfikatów rejestracji strony ufającej portfela, został zniekształcony lub nie może zostać zweryfikowany kryptograficznie, europejski portfel tożsamości cyfrowej ostrzega użytkownika portfela, że strona ufająca portfela nie mogła zostać zwalidowana, i nie może przedstawić wniosku jako pomyślnie zwalidowanego. Użytkownik portfela wyraźnie zatwierdza wniosek strony ufającej. Milczenie lub domyślnie zaznaczone pola nie wystarczają do wyraźnego zatwierdzenia.

— WRP-VALIDATION-03: Dostawca portfela określa, na podstawie swojej analizy ryzyka i polityki bezpieczeństwa, czy i na jakich warunkach użytkownik portfela może ominąć określone nieudane kontrole walidacyjne.

— WRP-OVERASKING-01: Europejski portfel tożsamości cyfrowej porównuje poświadczenia i atrybuty wymagane przez stronę ufającą portfela z zarejestrowanymi poświadczeniami i atrybutami w certyfikacie rejestracji strony ufającej portfela.

— WRP-OVERASKING-02: W przypadku gdy strona ufająca portfela żąda PID lub elektronicznych poświadczeń atrybutów lub elementów, które nie są objęte certyfikatem rejestracji strony ufającej portfela, europejski portfel tożsamości cyfrowej wyraźnie ostrzega użytkownika portfela przed jakimkolwiek ujawnieniem. W ostrzeżeniu wskazuje się, że strona ufająca portfela żąda więcej informacji, niż zarejestrowała. Użytkownik portfela wyraźnie zatwierdza wniosek strony ufającej. Milczenie lub domyślnie zaznaczone pola nie wystarczają do wyraźnego zatwierdzenia.

— WRP-OVERASKING-03: Dostawca portfela określa, na podstawie swojej analizy ryzyka, polityki bezpieczeństwa i mającego zastosowanie prawa, czy użytkownik portfela może kontynuować działalność pomimo takiego ostrzeżenia, czy można ujawnić jedynie podzbiór żądanych danych objętych certyfikatem rejestracji, czy też wniosek należy odrzucić.

7) 5.1.

Introduction

— Pkt 5 oraz jego podpunkty określają profil protokołu umożliwiającego stronie ufającej (RP) żądanie EAAP lub danych identyfikujących osobę (PID) od europejskiego portfela tożsamości cyfrowej oraz umożliwiającego mu przekazywanie żądanych EAAP/PID do RP przy użyciu mechanizmu transmisji bez wykorzystania API, opartego na ISO/IEC 18013-5 [10], lub mechanizmu transmisji z wykorzystaniem API, opartego na załączniku C do ISO/IEC 18013-7 [16], służącego do przekazywania struktur danych określonych w ISO/IEC 18013-5 [10] w odpowiednio opakowanej postaci.

— Pozostała część pkt 5 ma następującą strukturę:

— w pkt 5.2 określono wymagania dotyczące obsługi profilu i mechanizmów transmisji przez strony ufające (RP) i europejski portfel tożsamości cyfrowej;

— w pkt 5.3 określono wymagania właściwe dla mechanizmu transmisji bez wykorzystania API;

— pkt 5.4 oraz jego podpunkty określają wymagania właściwe dla mechanizmu transmisji z wykorzystaniem API.

8) 5.2.

Requirements on EUDI Wallet and RP support

— ISO/IEC 18013-SUPPORT-01: Jednostki portfela, dostawcy PID, dostawcy poświadczeń, dostawcy portfela i strony ufające nie obsługują pobierania z serwera określonego w ISO/IEC 18013-5 [10] na potrzeby żądania i prezentacji PID lub atrybutów poświadczeń.

— ISO/IEC 18013-SUPPORT-02: Europejski portfel tożsamości cyfrowej musi spełniać wymagania określone w pkt 5.3 i 5.4 niniejszego dokumentu.

— ISO/IEC 18013-SUPPORT-04: Strona ufająca powinna wdrożyć profil określony w pkt 5.4 niniejszego dokumentu.

9) 5.3.2.

ISO/IEC-mdoc EAAP Request contents

— ISO/IEC 18013-5-REQ-04: Żądania urządzenia przesyłane do europejskich portfeli tożsamości cyfrowej zawierają parę klucz–wartość „requestInfo” określoną w pkt 8.3.2.1.2.1 [10]. Wartość tej pary musi być typu RequestInfo.

— ISO/IEC 18013-5-REQ-05: Typ RequestInfo jest zgodny z poniższą definicją CDDL.

RequestInfo = {

'euWrprc': bstr; zawiera certyfikat rejestracji (zob. wymogi poniżej)

}

— ISO/IEC 18013-5-REQ-06: Wspomniany element requestInfo zawiera element z oznaczeniem „euWrprc”.

— ISO/IEC 18013-5-REQ-07: Wartość „euWrprc” jest zakodowanym w CBOR zaświadczeniem o rejestracji.

— ISO/IEC 18013-5-REQ-08: nieważny.

— UWAGA 3: nieważny.

— ISO/IEC 18013-5-REQ-09: nieważny.

— ISO/IEC 18013-5-REQ-10: nieważny.

— ISO/IEC 18013-5-REQ-11: nieważny.

10) 5.3.3

ISO/IEC-mdoc EAAP Response profile

— W tym punkcie określono wymagania dotyczące typu komunikatu DeviceResponse, wspólne dla obu typów mechanizmów transmisji (z wykorzystaniem API i bez wykorzystania API).

— UWAGA 1: W przypadku stosowania mechanizmu bez wykorzystania API, opartego na ISO/IEC 18013-5 [10], odpowiedź EAAP stanowi dokładnie instancję DeviceResponse zgodnie z profilem określonym w tym punkcie. W przypadku stosowania mechanizmu z wykorzystaniem API, opartego na załączniku C do ISO/IEC 18013-7 [16], instancja DeviceRequest jest opakowana zgodnie z załącznikiem C do [16].

— ISO/IEC 18013-5-RESP-02: Dostawca danych identyfikujących osobę i elektronicznych poświadczeń atrybutów nie włącza żadnych elementów danych do mapy KeyAuthorizations w obiekcie bezpieczeństwa mobilnego wydawanych przez siebie danych identyfikujących osobę i elektronicznych poświadczeń atrybutów, z wyjątkiem elementów danych dostarczonych przez stronę ufającą portfela w danych transakcyjnych w żądaniu mdoc, przeznaczonych do podpisania lub opieczętowania przez jednostkę portfela z wykorzystaniem klucza prywatnego danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów.

— UWAGA 2: W rezultacie jednostki portfela nie mogą przedstawiać stronom ufającym portfela żadnych elementów danych podpisanych przez urządzenie, z wyjątkiem podpisania danych dostarczonych przez stronę ufającą portfela, na przykład w przypadkach wykorzystania do bezpiecznego uwierzytelniania użytkownika.

— UWAGA 3: Norma ISO/IEC 18013-5:2021 nie określa, w jaki sposób strony ufające portfela mogą włączać dane transakcyjne do żądania mdoc. Włączenie danych transakcyjnych do żądania mdoc następuje poprzez dodanie specyfikacji technicznych.

— ISO/IEC 18013-5-RESP-03: Dostawcy danych identyfikujących osobę nie zezwalają na wykorzystywanie klucza prywatnego danych identyfikujących osobę do podpisywania elementów danych dostarczonych przez stronę ufającą portfela w danych transakcyjnych w żądaniu mdoc.

11) 5.4

Requirements for API mediated mechanism

5.4.1

ISO/IEC 18013-7-related requirements

W tym punkcie określono wymogi dotyczące mechanizmu transmisji z wykorzystaniem API, powiązane z wymogami określonymi w załączniku C do [16].

— ISO/IEC 18013-7-API-01: Profil obsługujący prezentacje z wykorzystaniem API musi spełniać wymagania określone w załączniku C do ISO/IEC 18013-7 [16], zgodnie z dalszym uszczegółowieniem w pkt 5.3 i 5.4 niniejszego dokumentu.

— ISO/IEC 18013-7-API-02: Wszystkie obowiązkowe wymagania określone w załączniku C [16] mają zastosowanie zgodnie z dalszym uszczegółowieniem w pkt 5.3 i 5.4 niniejszego dokumentu.

— ISO/IEC 18013-7-API-03: Wszystkie wymagania fakultatywne określone w załączniku C do [16] pozostają nieobowiązkowe, chyba że niniejszy dokument stanowi inaczej.

12) 5.4.2.

Dodatkowe wymagania

— W tym punkcie określono dodatkowe wymagania dotyczące mechanizmu transmisji z wykorzystaniem API.

— ISO/IEC 18013-ADD-API-01: Europejski portfel tożsamości cyfrowej domyślnie ujawnia pośredniczącemu API działającemu zgodnie z załącznikiem C do [16] informację o obecności wszystkich przechowywanych typów elektronicznych poświadczeń atrybutów, jednak nie ujawnia atrybutów ani ich wartości w tych elektronicznych poświadczeniach atrybutów.

— UWAGA 1: Ograniczenie dotyczące wartości atrybutów ma zastosowanie nawet wtedy, gdy takie ujawnienie mogłoby usprawnić usługi świadczone przez system operacyjny na rzecz europejskiego portfela tożsamości cyfrowej, na przykład wybór poświadczeń w kontekście pośredniczącego API.

— Z systemami operacyjnymi i przeglądarkami wiążą się pewne aspekty niepodlegające kontroli podmiotów wdrażających, które można uwzględnić, jak wskazano w poniższych uwagach 2–4:

— UWAGA 2: Żądanie prezentacji od strony ufającej portfela stosującej załącznik C do [16] może być przetwarzane przez przeglądarkę lub system operacyjny w celu wyszukiwania dostępnych elektronicznych poświadczeń atrybutów (EAA).

— UWAGA 3: Oczekuje się, że żądanie prezentacji od strony ufającej portfela stosującej załącznik C do [16] będzie przetwarzane przez przeglądarkę lub system operacyjny w celach zapewnienia bezpieczeństwa użytkownika.

— UWAGA 4: Oczekuje się, że żądanie prezentacji od strony ufającej portfela stosującej załącznik C do [16] nie będzie przetwarzane przez przeglądarkę ani system operacyjny w celach analizy rynku (w tym jako cel drugorzędny) ani do celów wewnętrznych przeglądarki lub systemu operacyjnego.

— ISO/IEC 18013-ADD-API-02: W przypadku gdy europejski portfel tożsamości cyfrowej usuwa na żądanie użytkownika PID lub EAA uprzednio ujawnione pośredniczącemu API, które działa zgodnie z załącznikiem C do [16], europejski portfel tożsamości cyfrowej informuje pośredniczące API, że nie przechowuje już tych danych.

— ISO/IEC 18013-ADD-API-03: Jeżeli użytkownik odinstaluje swój europejski portfel tożsamości cyfrowej, europejski portfel tożsamości cyfrowej informuje pośredniczące API działające zgodnie z załącznikiem C do [16], że nie przechowuje już żadnych wcześniej ujawnionych PID ani EAA.

— ISO/IEC 18013-ADD-API-04: Europejski portfel tożsamości cyfrowej zapewnia globalne ustawienia użytkownika umożliwiające wyłączenie ujawniania przechowywanych EAA za pośrednictwem pośredniczącego API, zgodnie z normą ISO/IEC 18013-ADD-API-01. Jeżeli ustawienie to jest wyłączone, europejski portfel tożsamości cyfrowej nie ogłasza ani nie odpowiada na żądania prezentacji lub wydania realizowane z wykorzystaniem API.

— ISO/IEC 18013-ADD-API-05: Europejskie portfele tożsamości cyfrowej weryfikują w przepływach między urządzeniami za pomocą API pośredniczącego, czy urządzenie wchodzące w interakcję znajduje się w bliskiej odległości fizycznej od europejskiego portfela tożsamości cyfrowej, korzystając z bezpiecznego, bezpośredniego i kierowanego przez użytkownika lokalnego kanału komunikacji, takiego jak technologia komunikacji bezprzewodowej bliskiego zasięgu, w celu przeprowadzenia kontroli fizycznej bliskości.

— UWAGA: CTAP 2.3 umożliwia wykorzystanie BLE do przeprowadzenia kontroli bliskiej odległości fizycznej, a po wdrożeniu przez oba urządzenia umożliwia również przesyłanie danych między urządzeniami za pomocą technologii transmisji krótkiego zasięgu. Podstawowe systemy operacyjne, przeglądarki, pośredniczące API lub wszelkie inne warstwy techniczne pozostające poza kontrolą europejskiego portfela tożsamości cyfrowej powinny preferować przeprowadzanie zarówno kontroli bliskiej odległości fizycznej, jak i przekazywanie danych między tymi dwoma urządzeniami przy użyciu lokalnego kanału komunikacji, co umożliwia CTAP 2.3, przed korzystaniem z usług hybrydowego tunelu CTAP.

13) 6.2.

Wymagania dotyczące europejskiego portfela tożsamości cyfrowej i wsparcia dla stron ufających

— OIDFVP-HAIP-SUPPORT-02: Europejski portfel tożsamości cyfrowej musi spełniać wymogi określone w pkt 6.5 niniejszego załącznika.

— OIDFVP-HAIP-SUPPORT-03: Europejski portfel tożsamości cyfrowej nie powinien obsługiwać mechanizmu opartego na przekierowaniach określonego w pkt 6.4 w odniesieniu do przepływów prezentacji między urządzeniami.

— UWAGA 3: Korzystanie z tego mechanizmu jest podatne na ataki, np. ataki typu „session fixation”. Łagodzenie takich ataków leży w gestii stron ufających. Wdrożenie tego mechanizmu nie powinno prowadzić do niezgodności z przepisami.

— OIDFVP-HAIP-SUPPORT-05: Strona ufająca musi spełniać wymagania określone w pkt 6.5 niniejszego załącznika.

— UWAGA 5: nieważny.

14) 6.3.1.

General requirements

— OIDFVP-HAIP-GEN-01: Stosuje się wszystkie obowiązkowe wymagania określone w pkt 5, 5.3, 7 i 8 HAIP [11].

— UWAGA 1:

„HAIP [11] sekcja 5” odnosi się wyłącznie do wymagań, które znajdują się bezpośrednio pod nagłówkiem sekcji 5. Nie obejmuje to sekcji 5.1, 5.2 i 5.3.

— OIDFVP-HAIP-GEN-03: Jeżeli niniejszy załącznik zmienia wymaganie z OpenID4VC-HAIP [11], pierwszeństwo ma zmienione wymaganie określone w niniejszym załączniku.

— UWAGA 2: Pozwala to na przykład przekształcić wymaganie opcjonalne z OpenID4VC-HAIP [11] w wymaganie obowiązkowe lub rozszerzyć wymagania obowiązkowe.

— OIDFVP-HAIP-GEN-04: Jeżeli format żądanego poświadczenia jest zgodny z [10], strony ufające oraz europejskie portfele tożsamości cyfrowej muszą być zgodne z profilem „ISO mdocs” określonym w pkt 6 [11].

— UWAGA 3: Dla jasności: „profil mdocs ISO” w HAIP oznacza, że strony ufające oraz europejskie portfele tożsamości cyfrowej muszą spełniać mające zastosowanie wymagania określone w załączniku B.2 [7].

— OIDFVP-HAIP-GEN-05: Jeżeli format wymaganego poświadczenia jest zgodny z [2], strony ufające oraz europejskie portfele tożsamości cyfrowej muszą być zgodne z profilem „IETF SD-JWT VCs” określonym w pkt 6 [11].

— UWAGA 4: Dla jasności: „profil IETF SD-JWT VCs” oznacza, że strony ufające oraz europejskie portfele tożsamości cyfrowej muszą spełniać wymagania określone w załączniku B.3 do [7], a także wymagania określone w pkt 6.1 [11].

15) 6.3.2.1.

General requirements

— OIDFVP-HAIP-COMMON-REQ-01: nieważny.

16) 6.3.2.2.

Wymagania dotyczące obiektu żądania

— OIDFVP-HAIP-COMMON-REQ-RO-02: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-03: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-04: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-05: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-06: nieważny.

— OIDFVP-HAIP-COMMON-REQ-RO-07: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-08: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-09: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-10: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-11: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-12: nieważny

— Uwaga 2: nieważny

— OIDFVP-HAIP-COMMON-REQ-RO-13: Jeden z elementów parametru verifier_info obejmuje certyfikat rejestracji.

— OIDFVP-HAIP-COMMON-REQ-RO-23: Certyfikat końcowy wskazany w pkt 5.9.3 OpenID4VP do stosowania z „x509_hash Client Identifier Prefix” jest certyfikatem dostępu RP, jak określono w ETSI TS 119 475 [14].

17) 6.3.3.

Authorization Response (EAAP response) profile

— OIDFVP-HAIP-COMMON-RESP-01: nieważny.

18) 6.4.1.

General requirements

— OIDFVP-HAIP-REDIRECTS-04: nieważny.

— UWAGA: nieważny.

19) 6.5.2.

Additional requirements

— OIDFVP-HAIP-ADD-API-01: Europejski portfel tożsamości cyfrowej domyślnie ujawnia pośredniczącemu API działającemu zgodnie z pkt 5.2 [11] informację o obecności wszystkich przechowywanych typów EAA, jednak nie ujawnia atrybutów ani ich wartości w tych poświadczeniach.

— OIDFVP-HAIP-ADD-API-04: Jeżeli europejski portfel tożsamości cyfrowej obsługuje pośredniczące API działające zgodnie z OIDFVP-HAIP-ADD-API-01, zapewnia on globalne ustawienie użytkownika umożliwiające wyłączenie ujawniania przechowywanych EAA za pośrednictwem tego API. Po ustawieniu wyłączenia ujawniania europejski portfel tożsamości cyfrowej powinien następnie umożliwić użytkownikowi wybór poszczególnych poświadczeń do ujawnienia pośredniczącemu API.

— OIDFVP-HAIP-ADD-API-05: Europejskie portfele tożsamości cyfrowej weryfikują w przepływach między urządzeniami, za pomocą API pośredniczącego, czy urządzenie wchodzące w interakcję znajduje się w bliskiej odległości fizycznej od europejskiego portfela tożsamości cyfrowej, korzystając z bezpiecznego, bezpośredniego i kierowanego przez użytkownika lokalnego kanału komunikacji, takiego jak technologia komunikacji bezprzewodowej bliskiego zasięgu, w celu przeprowadzenia kontroli fizycznej bliskości.

— UWAGA 5: CTAP 2.3 umożliwia wykorzystanie BLE do przeprowadzenia kontroli bliskiej odległości fizycznej, a po wdrożeniu przez oba urządzenia umożliwia również przesyłanie danych między urządzeniami za pomocą technologii transmisji krótkiego zasięgu. Podstawowe systemy operacyjne, przeglądarki, pośredniczące API lub wszelkie inne warstwy techniczne pozostające poza kontrolą europejskiego portfela tożsamości cyfrowej powinny preferować przeprowadzanie zarówno kontroli bliskiej odległości fizycznej, jak i przekazywanie danych między tymi dwoma urządzeniami przy użyciu lokalnego kanału komunikacji, co umożliwia CTAP 2.3, przed korzystaniem z usług hybrydowego tunelu CTAP.

20) 6.5.3.

Specific requirements when requesting ISO/IEC 18013-5 EAAP

— OIDFVP-HAIP-ISO/IEC_18013_5_REQ-02: Wszystkie wymagania określone w niniejszym dokumencie mające zastosowanie do struktur żądania i odpowiedzi na żądanie dotyczące wyrobów określonych w normie ISO/IEC 18013-5 mają również zastosowanie w przypadku, gdy europejski portfel tożsamości cyfrowej otrzymuje żądanie prezentacji ISO/IEC mdoc za pośrednictwem mechanizmu transmisji z wykorzystaniem API określonego w pkt C.1 [16].

(

1

) Rozporządzenie wykonawcze Komisji (UE) 2015/1502 z dnia 8 września 2015 r. w sprawie ustanowienia minimalnych specyfikacji technicznych i procedur dotyczących poziomów bezpieczeństwa w zakresie środków identyfikacji elektronicznej na podstawie art. 8 ust. 3 rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym (Dz.U. L 235 z 9.9.2015, s. 7, ELI: http://data.europa.eu/eli/reg_impl/2015/1502/oj).