Rozporządzenie wykonawcze Komisji (UE) 2024/2979 z dnia 28 listopada 2024 r. ustanawiające zasady stosowania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 w odniesieniu do integralności i podstawowych funkcji europejskich portfeli tożsamości cyfrowej

Artykuł 1

Przedmiot i zakres stosowania

W niniejszym rozporządzeniu ustanawia się przepisy dotyczące integralności i podstawowych funkcji portfeli; przedmiotowe przepisy podlegają 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) „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;

2) „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;

3) „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;

4) „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;

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

6) „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;

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

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

9) „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;

10) „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;

11) „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;

12) „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;

13) „operacja kryptograficzna portfela” oznacza mechanizm kryptograficzny niezbędny w kontekście uwierzytelniania użytkownika portfela oraz wydawania lub prezentacji danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów;

14) „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;

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

Artykuł 3

Integralność jednostki portfela

1. Jednostki portfela nie mogą wykonywać żadnych funkcji wymienionych w art. 5a ust. 4 rozporządzenia (UE) nr 910/2014, z wyjątkiem uwierzytelniania użytkownika portfela w celu uzyskania dostępu do jednostki portfela, do czasu gdy jednostka portfela skutecznie uwierzytelni użytkownika portfela.

Artykuł 4

Instancje portfela

1. Instancje portfela wykorzystują co najmniej jedno bezpieczne urządzenie kryptograficzne portfela do zarządzania aktywami krytycznymi.

2. Dostawcy portfela zapewniają integralność, autentyczność i poufność komunikacji między instancjami portfela a bezpiecznymi aplikacjami kryptograficznymi portfela.

3. W przypadku gdy aktywa krytyczne odnoszą się do przeprowadzania identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa, operacje kryptograficzne portfela lub inne operacje przetwarzania aktywów krytycznych przeprowadza się zgodnie z wymogami dotyczącymi cech charakterystycznych i konstrukcji środków identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa, jak określono w rozporządzeniu wykonawczym Komisji (UE) 2015/1502 (

1

).

Artykuł 5

Bezpieczne aplikacje kryptograficzne portfela

1. Dostawcy portfela zapewniają, aby bezpieczne aplikacje kryptograficzne portfela:

a) wykonywały operacje kryptograficzne portfela wykorzystujące aktywa krytyczne, które nie są wymagane do uwierzytelniania użytkownika portfela, przechowywane w bezpiecznym urządzeniu kryptograficznym portfela wyłącznie w przypadkach, gdy aplikacje te skutecznie uwierzytelniły użytkowników portfela;

b) jeżeli uwierzytelniają użytkowników portfela w kontekście przeprowadzania identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa; dokonywały uwierzytelnienia użytkowników portfela zgodnie z wymogami dotyczącymi cech charakterystycznych i konstrukcji środków identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa określonymi w rozporządzeniu wykonawczym (UE) 2015/1502;

c) były w stanie bezpiecznie generować nowe klucze kryptograficzne;

d) były w stanie w bezpieczny sposób usuwać aktywa krytyczne;

e) były w stanie wygenerować dowód posiadania kluczy prywatnych;

f) chroniły klucze prywatne generowane przez te bezpieczne aplikacje kryptograficzne portfela podczas funkcjonowania kluczy;

g) spełniały wymogi dotyczące cech charakterystycznych i konstrukcji środków identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa określone w rozporządzeniu wykonawczym (UE) 2015/1502;

h) były jedynymi komponentami zdolnymi do wykonywania operacji kryptograficznych portfela i wszelkich innych operacji z wykorzystaniem aktywów krytycznych w kontekście przeprowadzania identyfikacji elektronicznej na wysokim poziomie bezpieczeństwa.

2. W przypadku gdy dostawcy portfeli zdecydują się dostarczyć bezpieczną aplikację kryptograficzną portfela dla wbudowanego bezpiecznego elementu, przedmiotowi dostawcy portfeli opierają swoje rozwiązanie techniczne na specyfikacjach technicznych wymienionych w załączniku I lub na innych równoważnych specyfikacjach.

Artykuł 5a

Mechanizmy kryptograficzne

Do celów art. 4 ust. 2 dostawcy portfela stosują wyłącznie mechanizmy kryptograficzne, o których mowa w załączniku Ia.

Artykuł 6

Autentyczność i ważność jednostki portfela

1. Dostawcy portfela wydają poświadczenia jednostki portfela dla każdej jednostki portfela. Dostawcy portfela podpisują lub opatrują pieczęcią poświadczenia jednostki portfela w sposób umożliwiający walidację podpisów lub pieczęci za pomocą certyfikatu wymienionego w wykazie zgodnie z sekcją 2 pkt 1 lit. h) załącznika II do rozporządzenia wykonawczego (UE) 2024/2980.

2. Dostawcy portfela zapewniają zgodność poświadczeń jednostki portfela, o których mowa w ust. 1, ze specyfikacjami technicznymi określonymi w załączniku Ib.

3. Dostawcy portfela:

a) informują użytkowników portfela o ich prawach i obowiązkach w odniesieniu do ich jednostki portfela;

b) zapewniają użytkownikom portfela bezpieczne mechanizmy identyfikacji i uwierzytelniania, które są niezależne od jednostek portfela;

c) zapewniają użytkownikom portfela prawo do żądania unieważnienia poświadczeń jednostki portfela przy użyciu mechanizmów uwierzytelniania, o których mowa w lit. b).

Artykuł 7

Unieważnienie poświadczeń jednostki portfela

1. Dostawcy portfela są jedynymi podmiotami uprawnionymi do unieważnienia poświadczeń jednostki portfela wydanych jednostkom portfela, które dostarczyli.

2. Dostawcy portfela ustanawiają publicznie dostępną politykę określającą warunki i ramy czasowe unieważniania poświadczeń jednostki portfela.

3. W przypadku gdy dostawcy portfela unieważnią poświadczenia jednostki portfela, informują o tym użytkowników portfela, których to dotyczy, w ciągu 24 godzin od unieważnienia ich jednostek portfela, m.in. podając przyczynę unieważnienia oraz jego konsekwencje dla użytkownika portfela. Informacje te należy przekazać w formie zwięzłej, łatwo dostępnej oraz używając jasnego i przystępnego języka.

4. W przypadku gdy dostawcy portfela unieważnili poświadczenia jednostki portfela, udostępniają publicznie status ważności poświadczenia jednostki portfela w sposób zapewniający ochronę prywatności i opisują lokalizację tych informacji w poświadczeniu jednostki portfela.

Artykuł 8

Formaty danych identyfikujących osobę i elektronicznych poświadczeń atrybutów

Dostawcy portfela zapewniają, aby rozwiązania w zakresie portfela umożliwiały korzystanie z danych identyfikujących osobę i elektronicznych poświadczeń atrybutów wydanych zgodnie z wykazem norm określonym w załączniku II.

Artykuł 9

Dzienniki transakcji

1. Niezależnie od tego, czy transakcja zakończyła się pomyślnie, instancje portfela rejestrują wszystkie transakcje ze stronami ufającymi portfela i innymi jednostkami portfela, w tym składanie podpisów i pieczęci elektronicznych.

2. Zarejestrowane informacje muszą obejmować co najmniej:

a) czas i datę transakcji;

b) imię i nazwisko lub nazwę, dane kontaktowe oraz niepowtarzalny identyfikator odpowiedniej strony ufającej portfela i państwo członkowskie, w którym strona ta ma siedzibę;

c) rodzaj lub rodzaje danych żądanych i przedstawionych w ramach transakcji;

d) w przypadku transakcji nieukończonych – przyczynę braku ich ukończenia.

3. Dostawcy portfela zapewniają integralność, autentyczność i poufność zarejestrowanych informacji.

4. Instancje portfela rejestrują zgłoszenia przesłane przez użytkownika portfela organom ochrony danych za pośrednictwem jednostki portfela.

5. Rejestry, o których mowa w ust. 1 i 2, są dostępne dla dostawcy portfela, jeżeli jest to konieczne do świadczenia usług portfela, na podstawie wyraźnej uprzedniej zgody użytkownika portfela.

6. Rejestry, o których mowa w ust. 1 i 2, pozostają dostępne tak długo, jak wymagają tego przepisy Unii lub prawo krajowe.

7. Dostawcy portfela umożliwiają użytkownikom portfela eksportowanie zarejestrowanych informacji, o których mowa w ust. 2.

Artykuł 10

Wbudowane ujawnianie

1. Dostawcy portfela zapewniają, aby elektroniczne poświadczenia atrybutów wydawane zgodnie ze specyfikacjami technicznymi mającymi zastosowanie do wspólnych wbudowanych reguł ujawniania określonymi w załączniku III mogły być przetwarzane przez jednostki portfela, które dostarczają.

2. Instancje portfela są w stanie przetwarzać i prezentować wbudowane reguły ujawniania, o których mowa w ust. 1, w połączeniu z danymi otrzymanymi od strony ufającej portfela.

3. Instancje portfela weryfikują, czy strona ufająca portfela spełnia wymogi zawarte we wbudowanych regułach ujawniania informacji, i informują użytkownika portfela o wyniku takiej weryfikacji.

Artykuł 11

Kwalifikowane podpisy i pieczęcie elektroniczne

1. Dostawcy portfela zapewniają, aby użytkownicy portfela mogli otrzymywać kwalifikowane certyfikaty kwalifikowanych podpisów lub pieczęci elektronicznych, które są powiązane z kwalifikowanymi urządzeniami do składania podpisu lub pieczęci mającymi charakter lokalny, zewnętrzny albo zdalny względem instancji portfela.

2. Dostawcy portfela zapewniają, aby rozwiązania w zakresie portfela były w stanie bezpiecznie łączyć się z jednym z następujących rodzajów kwalifikowanych urządzeń do składania podpisu lub pieczęci: lokalnymi, zewnętrznymi lub zdalnie zarządzanymi kwalifikowanymi urządzeniami do składania podpisu lub pieczęci na potrzeby korzystania z kwalifikowanych certyfikatów, o których mowa w ust. 1.

3. Dostawcy portfela zapewniają, aby użytkownicy portfela będący osobami fizycznymi otrzymali – przynajmniej do celów nieprofesjonalnych – bezpłatny dostęp do aplikacji służących do składania podpisu, które umożliwiają tworzenie bezpłatnych kwalifikowanych podpisów elektronicznych z wykorzystaniem certyfikatów, o których mowa w ust. 1.

Artykuł 12

Aplikacje służące do składania podpisu

1. Aplikacje służące do składania podpisu wykorzystywane przez jednostki portfela mogą być dostarczane przez dostawców portfela, dostawców usług zaufania albo przez strony ufające portfela.

2. Aplikacje służące do składania podpisu pełnią takie funkcje, jak:

a) podpisywanie lub opatrywanie pieczęcią danych przekazanych przez użytkownika portfela;

b) podpisywanie lub opatrywanie pieczęcią danych przekazanych przez stronę ufającą portfela;

c) składanie podpisów lub pieczęci zgodnie co najmniej z obowiązkowym formatem podpisu lub pieczęci, o którym mowa w załączniku IV;

d) informowanie użytkowników portfela o wynikach procesu składania podpisu lub pieczęci.

3. Aplikacje służące do składania podpisu mogą być zintegrowane z instancjami portfela albo mieć względem nich charakter zewnętrzny.

4. Aplikacje służące do składania podpisu wykorzystywane przez jednostki portfela obsługują co najmniej interfejs programowania aplikacji, o którym mowa w załączniku IV.

Artykuł 13

Eksport i możliwość przenoszenia danych

Jednostki portfela – w przypadku gdy jest to technicznie wykonalne i z wyjątkiem aktywów krytycznych – obsługują bezpieczny eksport i możliwość przenoszenia danych osobowych użytkownika portfela, aby umożliwić mu migrację danych do jednostki portfela w ramach innego rozwiązania w zakresie portfela w sposób zapewniający wysoko poziom ochrony, jak określono w rozporządzeniu wykonawczym (UE) 2015/1502.

Artykuł 14

Pseudonimy

2. Jednostki portfela obsługują generowanie – na żądanie strony ufającej portfela – pseudonimu charakterystycznego i niepowtarzalnego dla tej strony ufającej portfela oraz przekazują ten pseudonim stronie ufającej portfela – sam albo w połączeniu z danymi identyfikującymi osobę lub z elektronicznym poświadczeniem atrybutów, których żąda strona ufająca portfela.

Artykuł 14a

Unijny znak zaufania dla portfela tożsamości cyfrowej

1. Dostawcy portfela zapewniają, aby jednostki portfela wyświetlały unijny znak zaufania dla portfela tożsamości cyfrowej. Unijny znak zaufania dla portfela tożsamości cyfrowej ma formę określoną w załącznikach VI i VII.

2. Dostawcy portfela zapewniają, aby jednostki portfela umożliwiały użytkownikom portfela dostęp do informacji pozwalających im zweryfikować status certyfikacji danego rozwiązania w zakresie portfela. W tym celu dostawcy portfela zapewniają, aby po rejestracji rozwiązania w zakresie portfela odpowiednie jednostki portfela zawierały adresy URL podane przez Komisję Europejską na potrzeby takiej weryfikacji. Dostawcy portfela zapewniają swoim jednostkom portfela dostęp do danych dotyczących unijnego znaku zaufania dla portfela tożsamości cyfrowej, które są zgodne ze specyfikacjami technicznymi określonymi w załączniku VIII.

3. Kolorami referencyjnymi unijnego znaku zaufania dla portfela tożsamości cyfrowej są kolory Pantone nr 661 i Pantone nr 116; lub kolory niebieski (100 % cyjanu + 67 % magenty + 0 % żółtego + 40 % czarnego) i żółty (0 % cyjanu + 20 % magenty + 100 % żółtego + 0 % czarnego) w przypadku stosowania druku czterokolorowego; w przypadku stosowania kolorów RGB kolorami referencyjnymi są niebieski (0 czerwony + 51 zielony + 153 niebieski) i żółty (255 czerwony + 204 zielony + 0 niebieski).

4. Jedynie w przypadku gdy użycie koloru nie jest możliwe, można stosować czarno-biały unijny znak zaufania dla portfela tożsamości cyfrowej, jak określono w załączniku VII.

5. W przypadku gdy unijny znak zaufania dla portfela tożsamości cyfrowej umieszczany jest na ciemnym tle, można zastosować go w negatywie z użyciem tego samego koloru tła. W przypadku gdy unijny znak zaufania dla portfela tożsamości cyfrowej stosowany jest w kolorze na kolorowym tle, co sprawia, że nie jest on dobrze widoczny, można otoczyć unijny znak zaufania dla portfela tożsamości cyfrowej zewnętrzną linią odgraniczającą, aby zwiększyć kontrast z kolorami tła.

6. Minimalny rozmiar unijnego znaku zaufania dla portfela tożsamości cyfrowej wynosi 64 × 85 pikseli w rozdzielczości 150 dpi.

7. Dostawcy portfela zapewniają, aby unijny znak zaufania dla portfela tożsamości cyfrowej był używany w sposób umożliwiający wyraźne wskazanie jednostki portfela, do której się odnosi. Unijny znak zaufania dla portfela tożsamości cyfrowej może być powiązany z elementami graficznymi lub tekstowymi wyraźnie wskazującymi jednostkę portfela, dla której jest używany, pod warunkiem że nie zmieniają one jego rozpoznawalności jako unijnego znaku zaufania dla portfela tożsamości cyfrowej ani nie zmieniają powiązania z wykazem certyfikowanych europejskich portfeli tożsamości cyfrowej, o którym mowa w art. 5d rozporządzenia (UE) nr 910/2014.

8. W przypadku unieważnienia poświadczenia jednostki portfela dostawcy portfela zapewniają, aby unijny znak zaufania dla portfela tożsamości cyfrowej nie był już wyświetlany przez odpowiednią jednostkę portfela.

Artykuł 15

Wejście w życie

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

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

Załącznik I

WYKAZ NORM, O KTÓRYM MOWA W ART. 5

— SAM.01 Secured Applications for Mobile - Requirements for supporting 3rd party Applets on eSIM and eSE via SAM. v1.1 2023, GSMA;

— GPC_GUI_ 217 GlobalPlatform SAM Configuration Technical specification for implementation of SAM v1.0 2024-04;

— GPC_SPE_0 34 GlobalPlatform Card Specification Technical specification for smart cards v2.3.1 2018-03;

— GPC_SPE_0 07 GlobalPlatform Amendment A Confidential Card Content Management v1.2 2019-07;

— GPC_SPE_0 13 GlobalPlatform Amendment D Secure Channel Protocol 03 v1.2 2020-04;

— GPC_SPE_0 93 GlobalPlatform Amendment F Secure Channel Protocol 11 v1.4 2024-03;

— GPD_SPE_0 75 Open Mobile API Specification OMAPI API for mobile apps to access secure elements on user devices. v3.3 2018-08, GlobalPlatform.

Załącznik Ia

MECHANIZMY KRYPTOGRAFICZNE, O KTÓRYCH MOWA W ART. 5a

Europejska Grupa ds. Certyfikacji Cyberbezpieczeństwa, podgrupa ds. kryptografii: „Uzgodnione mechanizmy kryptograficzne” opublikowane przez Agencję Unii Europejskiej ds. Cyberbezpieczeństwa („ENISA”) (

2

).

Załącznik Ib

SPECYFIKACJE TECHNICZNE DOTYCZĄCE POŚWIADCZEŃ JEDNOSTKI PORTFELA, O KTÓRYCH MOWA W ART. 6 UST. 2a

1. Poświadczenie jednostki portfela musi obejmować co najmniej jedno poświadczenie instancji portfela oraz co najmniej jedno poświadczenie klucza.

2. Poświadczenie instancji portfela i poświadczenia klucza muszą spełniać następujące wymogi:

a) Wymagania dotyczące formatu

— FR-WIA-1: Poświadczeniem instancji portfela jest JSON Web Token (JWT), jak określono w RFC 7519 (

3

), podpisany lub opatrzony pieczęcią przez dostawcę portfela za pomocą kompaktowego podpisu podstawowego JAdES B.

— FR-WIA-1.1: Poświadczenie instancji portfela jest poświadczeniem portfela określonym w dodatku E do OpenID for Verifiable Credential Issuance v1.0 (

4

) („OID4VCI”) i rozszerzonym, jak określono w C-WIA-1 i C-WIA-2 poniżej.

— FR-KA-1: Poświadczeniem klucza jest JWT określone w RFC 7519, podpisane lub opatrzone pieczęcią przez dostawcę portfela za pomocą kompaktowego podpisu podstawowego JAdES B.

— FR_KA_1.1: Poświadczeniem klucza jest poświadczenie klucza określone w dodatku D do OID4VCI, rozszerzone zgodnie z C_KA-1 i C_KA-2 poniżej

b) Wymagania w zakresie transportu

— TR-WIA-1: Jednostka portfela korzysta z poświadczenia instancji portfela podczas wydawania danych identyfikujących osobę, kwalifikowanych lub niekwalifikowanych elektronicznych poświadczeń atrybutów lub elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu.

— TR-WIA-2: Dostawca portfela weryfikuje integralność instancji portfela oraz podpisuje lub opatruje pieczęcią poświadczenie instancji portfela.

— TR-WIA-2.1: W przypadku gdy dostawca portfela wydaje poświadczenie instancji portfela, różnica między czasem, w którym dostawca portfela zweryfikował integralność instancji portfela, a czasem, który wskaże w parametrze nagłówka „exp” wydanego poświadczenia instancji portfela, musi wynosić mniej niż 24 godziny.

— TR-WIA-2.2: Dostawca portfela zapewnia, aby jednostka portfela zawierała poświadczenia instancji portfela niezbędne do wydawania danych identyfikujących osobę oraz elektronicznych poświadczeń atrybutów.

— TR-WIA-3: W trakcie wydawania jednostka portfela przekazuje poświadczenie instancji portfela do serwera autoryzacji zarówno w ramach żądania autoryzacji typu pushed, jak i żądania tokenu, jak określono w OID4VCI.

— TR-WIA-3.1: Jednostka portfela przesyła poświadczenie instancji portfela wraz z dowodem posiadania („PoP”), jak określono w dodatku E do OID4VCI.

— TR-WIA-3.2: Jednostka portfela przekazuje to samo poświadczenie instancji portfela tylko jednemu serwerowi autoryzacji.

— TR-WIA-3.2.1: W przypadku gdy dostawca portfela korzysta z opcji „per-issuer reuse” określonej w R_WIA_1 poniżej, jednostka portfela może przekazywać poświadczenie instancji portfela temu samemu serwerowi autoryzacji wielokrotnie.

— TR-WIA-3.2.2: W przypadku gdy dostawca portfela nie korzysta z opcji „per-issuer reuse”, jednostka portfela wykorzystuje poświadczenie instancji portfela w co najwyżej jednym procesie wydawania.

— TR-WIA-4: W przypadku gdy serwer autoryzacji otrzymuje poświadczenie instancji portfela, weryfikuje podpis tego poświadczenia instancji portfela przy użyciu klucza publicznego zawartego w certyfikacie podpisującym uwzględnionym w parametrze „x5c” nagłówka JOSE poświadczenia instancji portfela.

— TR-WIA-4.1: Serwer autoryzacji weryfikuje również, czy certyfikat podpisu można zweryfikować za pomocą kotwicy zaufania znajdującej się w wykazie dostawców portfela, o którym mowa w art. 5 rozporządzenia wykonawczego (UE) 2024/2980, potencjalnie z wykorzystaniem certyfikatów pośrednich zawartych w parametrze „x5c”.

— TR-WIA-4.2: Serwer autoryzacji weryfikuje, czy poświadczenie instancji portfela nie wygasło.

— TR-WIA-4.3: Serwer autoryzacji weryfikuje podpis PoP przy użyciu klucza publicznego zawartego w elemencie danych „cnf”.

— TR_KA-1: Jednostka portfela wykorzystuje poświadczenie klucza podczas wydawania danych identyfikujących osobę oraz podczas wydawania powiązanych z urządzeniem kwalifikowanych lub niekwalifikowanych elektronicznych poświadczeń atrybutów lub elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu.

— TR_KA-1.1: Jednostka portfela nie wykorzystuje poświadczenia klucza podczas wydawania niepowiązanych z urządzeniem kwalifikowanych lub niekwalifikowanych elektronicznych poświadczeń atrybutów ani elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu.

— TR_KA-2: Dostawca portfela zapewnia jednostce portfela różne poświadczenia klucza dla WSCD jednostki portfela i dla każdego z jej magazynów kluczy.

— TR_KA-2.1: Dostawca portfela podpisuje lub opatruje pieczęcią poświadczenie klucza po uprzednim zweryfikowaniu, że klucze objęte poświadczeniem są przechowywane w WSCD jednostki portfela lub w magazynie kluczy opisanym w tym poświadczeniu klucza.

— TR_KA-2.2: Poświadczenie klucza musi zawierać co najmniej jeden poświadczony klucz publiczny. Liczba kluczy w poświadczeniu klucza przekazywanym wystawcy poświadczenia nie powinna przekraczać maksymalnej wielkości partii określonej przez tego wystawcę poświadczenia w jego metadanych wydawcy poświadczenia; zob. ETSI TS 119 472-3 (

5

), parametr „credential_configurations_supported. credential_metadata.credential_reuse_policy.options.batch_size”.

— TR_KA-2.3: Dostawca portfela umieszcza klucz publiczny (odpowiadający kluczowi prywatnemu przechowywanemu w WSCD lub w magazynie kluczy jednostki portfela) w co najwyżej jednym poświadczeniu klucza.

— TR_KA-2.4: Jednostka portfela wykorzystuje poświadczenie klucza w co najwyżej jednym procesie wydawania lub ponownego wydawania poświadczenia.

— TR_KA-2.5: Dostawca portfela zapewnia, aby jednostka portfela posiadała poświadczenia klucza niezbędne do wydawania danych identyfikujących osobę oraz powiązanych z urządzeniem elektronicznych poświadczeń atrybutów.

— TR_KA-3: W razie potrzeby podczas wydawania jednostka portfela zamieszcza poświadczenie klucza w polu „proofs” żądania poświadczenia skierowanego do wystawcy poświadczenia, zgodnie z OID4VCI, w postaci dowodu typu „jwt” lub typu „attestation”.

— TR_KA_3.1: W przypadku gdy jednostka portfela zawiera poświadczenie klucza w elemencie „jwt”, podpisuje lub opatruje pieczęcią to poświadczenie klucza przy użyciu klucza prywatnego odpowiadającego kluczowi publicznemu znajdującemu się pod indeksem 0 w tablicy „attested_keys” w obiekcie „key_attestation”.

— TR_KA-4: W przypadku gdy wystawca poświadczenia wydaje dane uwierzytelniające powiązane z urządzeniem, wskazuje on w parametrze „proof_types_supported” w swoich metadanych uwierzytelniających wystawcy, jak określono w pkt 12.2.4 OID4VCI, że obsługuje zarówno typ dowodu „jwt”, jak i „attestation” dla poświadczeń klucza, które obejmują obiekt „key_attestations_required”.

— TR_KA-4.1: W przypadku gdy wystawca poświadczenia wydaje dane uwierzytelniające niepowiązane z urządzeniem, pomija parametry „proof_types_supported” oraz „cryptographic_binding_methods_supported” w metadanych uwierzytelniających wystawcy.

— TR_KA-5: W przypadku gdy wystawca poświadczenia otrzymuje poświadczenie klucza w typie dowodu „jwt” lub „attestation”, weryfikuje podpis poświadczenia klucza przy użyciu klucza publicznego zawartego w certyfikacie podpisu zawartym w parametrze „x5c” w nagłówku JOSE poświadczenia klucza oraz sprawdza, czy ten certyfikat podpisu zawiera kotwicę zaufania w wykazie dostawców portfela, o którym mowa w art. 5 rozporządzenia wykonawczego (UE) 2024/2980, potencjalnie z wykorzystaniem certyfikatów pośrednich zawartych w parametrze „x5c”.

— TR_KA-6: W przypadku gdy wystawca poświadczenia otrzymuje poświadczenie klucza w typie dowodu „jwt”, weryfikuje podpis elementu „jwt” przy użyciu klucza znajdującego się pod indeksem 0 w tablicy „attested_keys” w obiekcie „key_attestation” zawartym w elemencie „jwt”.

— TR_KA-6.1: Wystawca poświadczenia weryfikuje, czy pole „nonce” elementu „jwt” zawiera prawidłową wartość c_nonce z jego punktu końcowego nonce_endpoint, jak określono w OID4VCI.

— TR_KA-7: W przypadku gdy wystawca poświadczenia otrzymuje poświadczenie klucza w typie dowodu „attestation”, weryfikuje, czy obiekt „key_attestation” zawiera prawidłową wartość c_nonce z jego punktu końcowego nonce_endpoint.

— TR_KA-8: Dostawca danych identyfikujących osobę zapewnia, aby dane identyfikujące osobę były powiązane z kluczem publicznym pochodzącym z poświadczenia klucza odnoszącego się do WSCD.

c) Wymagania w odniesieniu do treści

— C_WIA-1: Poświadczenie instancji portfela zawiera co najmniej:

— element danych „wallet_name” określony w dodatku E do OID4VCI, którego wartością jest identyfikator rozwiązania w zakresie portfela, który można znaleźć w wykazie dostawców portfela, o którym mowa w art. 5 rozporządzenia wykonawczego (UE) 2024/2980;

— element danych „wallet_version”

(

6

), będący ciągiem znaków, którego wartością jest wersja rozwiązania w zakresie portfela;

— element danych „wallet_solution_certification_information”, będący obiektem JSON zawierającym informacje o jednostce oceniającej zgodność, która certyfikowała rozwiązanie w zakresie portfela, numer certyfikacji (w stosownych przypadkach) oraz inne istotne szczegóły dotyczące certyfikacji;

— element danych „client_status”, zawierający dwa podpola:

— „status”: odniesienie do wykazu statusów określone w dodatku E do OID4VCI, które odzwierciedla status unieważnienia instancji portfela. Szczegółowe informacje znajdują się w lit. e) poniżej;

— „exp”: wartość NumericDate, określona w RFC 7519, wskazująca czas, do którego dostawca portfela będzie utrzymywał status unieważnienia pod indeksem wykazu statusów wskazanym w polu „status”;

— element danych „exp” określony w dodatku E do OID4VCI.

— UWAGA: Element danych „client_status.status” w poświadczeniu instancji portfela odzwierciedla status unieważnienia instancji portfela, a nie status unieważnienia samego poświadczenia. Jak opisano w R_WIA-1 poniżej, dostawca portfela może zdecydować o ograniczeniu zakresu każdego poświadczenia instancji portfela do konkretnego serwera autoryzacji na podstawie faktu, że wszystkie poświadczenia przekazywane do tego serwera zawierają tę samą wartość indeksu w polu „client_status.status”.

— UWAGA: Wartość „idx” w elemencie danych „status” może być wykorzystywana jako niepowtarzalny identyfikator (w parach) instancji portfela oraz jednostki portfela.

— C_WIA-2: Poświadczenie instancji portfela powinno również zawierać element danych „wallet_link” określony w dodatku E do OID4VCI, przy czym wartością tego elementu jest URI, pod którym można uzyskać dalsze informacje na temat rozwiązania w zakresie portfela.

— C_WIA-3: Serwer autoryzacji nie interpretuje parametru „exp” na najwyższym poziomie poświadczenia instancji portfela jako końca okresu utrzymywania statusu unieważnienia instancji portfela.

— UWAGA: Parametr „exp” na najwyższym poziomie poświadczenia instancji portfela oznacza moment wygaśnięcia samego poświadczenia.

— C_KA-1: Poświadczenie klucza obejmuje:

— elementy danych „key_storage” i „user_authentication” określone w dodatku D do OID4VCI;

— atrybuty „key_storage” i „user_authentication” przyjmują wartość „iso_18045_high”, jeżeli poświadczenie klucza odnosi się do WSCD;

— element danych „certification” określony w dodatku D do OID4VCI, zawierający adres URL, pod którym można uzyskać informacje na temat certyfikacji osiągniętej przez WSCD lub magazyn kluczy, orientacyjnie schemat, taki jak Common Criteria lub GlobalPlatform, ocenione wymagania, takie jak mający zastosowanie profil zabezpieczeń, oraz poziom oceny;

— na podstawie tych informacji musi być możliwe ustalenie, czy przechowywanie kluczy odbywa się w WSCD;

— element danych „key_storage_status”, zawierający dwa podpola:

— „status”: odniesienie do wykazu statusów określone w dodatku D.1 do OID4VCI. Wartość ta odzwierciedla albo status unieważnienia WSCD lub typu magazynu kluczy wykorzystywanego do przechowywania poświadczonych kluczy, albo – w ramach opcji „per-key-attestation index” – status unieważnienia indywidualnego WSCD lub magazynu kluczy jednostki portfela. Zob. R_KA_1 poniżej, aby zapoznać się z dostępnymi opcjami przypisania indeksów;

— „exp”: wartość NumericDate, określona w RFC 7519, wskazująca czas, do którego dostawca portfela będzie utrzymywał status unieważnienia pod indeksem wykazu statusów wskazanym w polu „status”;

— element danych „exp” określony w dodatku D do OID4VCI.

— UWAGA dotycząca wartości „idx” w elemencie danych „key_storage_status.status” w poświadczeniu klucza: w przypadku gdy dostawca portfela korzysta z opcji „type-shared index” (zob. R_KA_1 poniżej), wszystkie poświadczenia klucza dla tego samego typu WSCD lub magazynu kluczy współdzielą ten sam indeks wykazu statusów. W związku z tym wartość „idx” nie jest niepowtarzalna dla jednostki portfela. Natomiast w przypadku gdy dostawca portfela korzysta z opcji „per-key-attestation index”, wartość „idx” jest niepowtarzalna dla każdej jednostki portfela (lub niepowtarzalna dla każdej pary jednostki portfela i wystawcy poświadczenia). W żadnym przypadku wystawca poświadczenia nie wykorzystuje jednak wartości „idx” w poświadczeniu klucza jako identyfikatora jednostki portfela, lecz zamiast tego wykorzystuje wartość „idx” w poświadczeniu instancji portfela.

— C_KA-2: W przypadku gdy poświadczenie klucza jest przekazywane w typie dowodu „attestation”, zawiera ono również prawidłową wartość c_nonce, jak określono w dodatku F.3 do OID4VCI.

— C_KA-3: Wystawca poświadczenia nie interpretuje parametru „exp” na najwyższym poziomie poświadczenia klucza jako końca okresu utrzymywania statusu unieważnienia WSCD lub magazynu kluczy.

— UWAGA: Parametr „exp” na najwyższym poziomie poświadczenia klucza oznacza moment wygaśnięcia samego poświadczenia klucza.

d) Wymagania dotyczące cyklu życia

— W niniejszym załączniku określono następujące parametry metadanych wystawcy poświadczenia:

— „preferred_client_status_period”: OPTIONAL. Liczba całkowita określająca preferowany pozostały okres utrzymywania statusu poświadczenia instancji portfela, który jednostka portfela ma przedstawić podczas wydawania, wyrażony w sekundach. Pozostały okres utrzymywania statusu definiuje się jako różnicę między wartością „client_status.exp” w poświadczeniu a momentem otrzymania poświadczenia.

— „preferred_key_storage_status_period”: OPTIONAL. Liczba całkowita określająca preferowany pozostały okres utrzymywania statusu poświadczenia klucza, który jednostka portfela ma przedstawić podczas wydawania, wyrażony w sekundach. Pozostały okres utrzymywania statusu definiuje się jako różnicę między wartością „key_storage_status.exp” w poświadczeniu a momentem otrzymania poświadczenia.

— LC_WIA-1: Serwer autoryzacji może przekazywać swoje preferencje dotyczące pozostałego okresu utrzymywania statusu w poświadczeniach instancji portfela poprzez uwzględnienie parametru metadanych „preferred_client_status_period” w swoim punkcie końcowym metadanych wystawcy poświadczenia, jak określono w pkt 12.2.2 OID4VCI.

— LC_WIA-1.1: Pole to należy umieścić na najwyższym poziomie metadanych wystawcy poświadczenia.

— LC_WIA_2: Serwer autoryzacji nie interpretuje parametru „exp” na najwyższym poziomie poświadczenia instancji portfela jako końca okresu utrzymywania statusu unieważnienia instancji portfela.

— LC_WIA_3: W przypadku gdy dostawca portfela podpisuje lub opatruje pieczęcią poświadczenie instancji portfela, utrzymuje on status unieważnienia odpowiedniej instancji portfela do momentu upływu wartości „wallet_instance_status.exp” wskazanej w tym poświadczeniu.

— LC_KA-1: W przypadku gdy wymagane jest poświadczenie klucza, wystawca poświadczenia może przekazywać swoje preferencje dotyczące pozostałego okresu utrzymywania statusu w poświadczeniach klucza poprzez uwzględnienie parametru metadanych „preferred_key_storage_status_period” w swoim punkcie końcowym metadanych wystawcy poświadczenia, jak określono w pkt 12.2.2 OID4VCI.

— LC_KA-1.1: Pole to należy umieścić w obiekcie „key_attestations_required”, jak określono w pkt 12.2.4 OID4VCI.

— LC_KA-2: Dostawca portfela określa techniczny okres ważności wydawanych przez siebie poświadczeń klucza.

— LC_KA-3: W przypadku gdy dostawca portfela podpisuje lub opatruje pieczęcią poświadczenie klucza, utrzymuje on status unieważnienia odpowiedniego WSCD lub magazynu kluczy do momentu upływu wartości „key_storage_status.exp” wskazanej w tym poświadczeniu.

— LC_GEN-1: Dostawca portfela zapewnia, aby jednostka portfela mogła zawsze przedstawiać poświadczenia jednostki portfela oraz poświadczenia klucza, których wartości „client_status.exp” i „key_storage_status.exp” (odpowiednio) przypadają co najmniej 31 dni po momencie ich przedstawienia serwerowi autoryzacji lub wystawcy poświadczenia.

— UWAGA: Gwarantuje to, że dostawcy danych identyfikujących osobę mogą polegać na mechanizmie łańcuchowego sprawdzania unieważnienia bez konieczności wydawania krótkoterminowych danych identyfikujących osobę.

— LC_GEN-2: Dostawca portfela zapewnia, aby jednostka portfela pobierała metadane wystawcy poświadczenia w trakcie wydawania.

— LC_GEN_2.1: Jeżeli pole „preferred_key_storage_status_period” jest zawarte w tych metadanych, jednostka portfela przekazuje poświadczenie klucza, dla którego wartość („key_storage_status.exp” – czas bieżący) – „preferred_key_storage_status_period” jest możliwie najmniejsza, lecz nie jest ujemna. Jeżeli jednostka portfela nie ma dostępu do takiego poświadczenia klucza, musi uzyskać nowe poświadczenie klucza od dostawcy portfela, które spełnia warunek „key_storage_status.exp” – czas bieżący ≥ „preferred_key_storage_status_period”.

— LC_GEN_2.2: Jeżeli w tych metadanych znajduje się pole „preferred_client_status_period”, jednostka portfela przekazuje poświadczenie instancji portfela, dla którego wartość („client_status.exp” – czas bieżący) – „preferred_client_status_period” jest możliwie najmniejsza, lecz nie jest ujemna. Jeżeli jednostka portfela nie ma dostępu do takiego poświadczenia instancji portfela, zwraca się do dostawcy portfela o wydanie nowego poświadczenia instancji portfela spełniającego warunek „client_status.exp” – czas bieżący ≥ „preferred_client_status_period”.

— LC_GEN-3: Techniczny okres ważności danych identyfikujących osobę kończy się przed upływem zarówno wartości „client_status.exp” poświadczenia instancji portfela, jak i „key_storage_status.exp” poświadczenia klucza przekazanych dostawcy danych identyfikujących osobę w procesie wydawania.

— LC_GEN-4: Dostawca danych identyfikujących osobę, którego dane identyfikujące osobę mają techniczny okres ważności dłuższy niż 24 godziny, sprawdza status unieważnienia zarówno poświadczenia instancji portfela, jak i poświadczenia klucza otrzymanych w trakcie wydawania co najmniej raz na 24 godziny przez cały techniczny okres ważności danych identyfikujących osobę. W przypadku unieważnienia któregokolwiek z nich dostawca unieważnia dane identyfikujące osobę.

e) Wymogi dotyczące unieważniania

— R_GEN-1: Dostawca portfela stosuje wykazy statusów tokenów (określone w wykazie statusów tokenów opracowanym przez IETF) jako mechanizm unieważniania zarówno poświadczeń klucza, jak i poświadczeń instancji portfela, jak określono odpowiednio w dodatkach D i E do OID4VCI.

— UWAGA: W celu poprawy skalowalności swoich wykazów statusów dostawca portfela może skorzystać z następujących optymalizacji:

— podział wykazu statusów na wiele części, w przypadku gdy dostawcy portfela posiadają znaczną liczbę użytkowników i wydanych poświadczeń. Istnieje wiele strategii podziału na części, na przykład opartych na stałej wielkości lub na okresach. Wybór strategii podziału na części pozostawia się uznaniu dostawcy portfela. Przy wyborze należy uwzględnić rozmiar wykazu statusów przeznaczonego do pobrania oraz prywatność użytkownika;

— posiadanie wielu wykazów statusów;

— kompresja wykazu statusów w celu zmniejszenia jego rozmiaru.

— R_WIA-1: Dostawca portfela może przypisywać tę samą wartość do elementu danych „idx” w elemencie danych „client_status.status” we wszystkich poświadczeniach instancji portfela, które dana jednostka portfela przedstawia temu samemu serwerowi autoryzacji. Opcję tę określa się jako „per-issuer reuse”. W przypadku korzystania z tej opcji:

— R_WIA-1.1: Jednostka portfela przechowuje informacje o tym, jakiej wartości indeksu użyła dla każdego serwera autoryzacji, z którym wcześniej wchodziła w interakcję, oraz przy ponownej interakcji z tym samym serwerem żąda poświadczenia instancji portfela zawierającego tę samą wartość indeksu.

— R_WIA-1.2: W przypadku gdy dostawca portfela otrzymuje wniosek o wydanie poświadczenia instancji portfela zawierającego określoną wartość indeksu, weryfikuje on, czy wnioskująca jednostka portfela wcześniej otrzymała tę wartość indeksu, przed wydaniem nowego poświadczenia instancji portfela z tą wartością.

— R_WIA-1.3: Jednostka portfela nie wykorzystuje tej samej wartości indeksu w interakcjach z różnymi serwerami autoryzacji.

— UWAGA: W przypadku stosowania opcji „per-issuer reuse” dostawca portfela może ustalić, z iloma serwerami autoryzacji dana jednostka portfela wchodziła w interakcję oraz jak często wchodzi w interakcję z każdym z nich.

— R_WIA-2: Dostawca portfela dokumentuje w swojej polityce prywatności, czy stosuje opcję „per-issuer reuse” w odniesieniu do unieważniania instancji portfela.

— R_WIA-3: W przypadku gdy dostawca portfela nie stosuje opcji „per-issuer reuse”, przypisuje on nową, niemożliwą do powiązania wartość indeksu do każdego wydawanego poświadczenia instancji portfela.

— R_WIA-4: W przypadku gdy jednostka portfela musi zostać unieważniona, dostawca portfela unieważnia wartości indeksu w elemencie danych „client_status.status” we wszystkich poświadczeniach instancji portfela powiązanych z tą jednostką portfela.

— R_WIA-5: Dostawca portfela uwzględnia skalę wdrożenia oraz architekturę systemu przy określaniu rozmiaru wykazów statusów poświadczeń instancji portfela, zapewniając, aby były one wystarczająco duże, by zapobiegać korelacji i chronić prywatność użytkowników. W miarę możliwości wykaz statusów powinien odnosić się do co najmniej 10 000 poświadczeń.

— R_KA_1: Dostawca portfela wybiera jedną z następujących opcji przypisywania indeksów dla elementu danych „key_storage_status.status” w poświadczeniu klucza:

— opcja 1 („type-shared index”): wszystkie poświadczenia klucza odnoszące się do kluczy przechowywanych w tym samym typie WSCD lub magazynie kluczy zawierają tę samą wartość indeksu w „key_storage_status.status”;

— opcja 2 („per-key-attestation index”): poświadczenie klucza odnoszące się do kluczy przechowywanych w indywidualnym WSCD lub w magazynie kluczy zawiera niepowtarzalną wartość indeksu dla każdej pary jednostki portfela i wystawcy poświadczenia w „key_storage_status.status”.

— UWAGA: W przypadku gdy dostawca portfela korzysta z opcji 1, pojedyncze działanie unieważniające powoduje unieważnienie wszystkich poświadczeń klucza danego typu we wszystkich jednostkach portfela. Ponadto, ponieważ wszystkie poświadczenia klucza dla tego samego typu WSCD lub magazynu kluczy współdzielą jeden indeks wykazu statusów, liczba wpisów w wykazie statusów poświadczeń klucza odzwierciedla liczbę typów WSCD lub magazynów kluczy obsługiwanych przez dostawcę portfela, a nie liczbę wdrożonych jednostek portfela. Względy ochrony prywatności uzasadniające minimalny rozmiar wykazów statusów dla wykazów statusów instancji portfela nie mają zatem zastosowania do wykazów statusów poświadczeń klucza w ramach opcji 1, pod warunkiem że wystarczająco wiele jednostek portfela korzysta z tego samego typu WSCD lub magazynu kluczy.

— UWAGA: W przypadku gdy dostawca portfela korzysta z opcji 2, każdy indeks odzwierciedla stan unieważnienia konkretnego WSCD lub magazynu kluczy poświadczonego w danym poświadczeniu klucza.

— UWAGA: W przypadku gdy dostawca portfela korzysta z opcji 2, określone WSCD lub określony magazyn kluczy mogą również zostać unieważnione na wniosek użytkownika.

— R_KA-2: W przypadku gdy dostawca portfela korzysta z opcji 2, może on fakultatywnie stosować opcję „per-issuer reuse” opisaną w R_WIA-1. Jeżeli dostawca portfela korzysta z tej opcji, wymagania R_WIA-1–R_WIA-3 stosuje się odpowiednio.

— R_KA-3: W przypadku gdy dostawca portfela korzysta z opcji 2, uwzględnia on skalę wdrożenia oraz architekturę systemu przy określaniu rozmiaru wykazów statusów poświadczeń klucza, zapewniając, aby były one wystarczająco duże, aby zapobiec korelacji i chronić prywatność użytkowników. W miarę możliwości wykaz statusów powinien odnosić się do co najmniej 10 000 poświadczeń klucza.

— R_KA-4: W przypadku gdy dostawca portfela korzysta z opcji 1 (type-shared index), unieważnia on wpis „key_storage_status.status” wyłącznie w przypadku, gdy dany typ WSCD lub magazynu kluczy wykazuje podatność na zagrożenia bezpieczeństwa.

f) Wymagania dotyczące algorytmów podpisu

— SA-1: Do podpisywania poświadczeń instancji portfela, poświadczeń klucza, powiązanych dowodów posiadania oraz wykazów statusów tokenów stosuje się jeden z następujących algorytmów:

— ES256 (ECDSA z SHA-256 i P-256)

— ES384 (ECDSA z SHA-384 i P-384)

— ES512 (ECDSA z SHA-512 i P-521)

— SA-2: Dostawca portfela wybiera, który z algorytmów wymienionych w SA-1 będzie stosował.

— SA-3: Serwer autoryzacji lub wystawca poświadczenia (zgodnie z OID4VCI) obsługuje wszystkie algorytmy wymienione w SA-1.

Załącznik II

WYKAZ NORM, O KTÓRYM MOWA W ART. 8

Zastosowanie mają specyfikacje techniczne określone w pkt 2–6 ETSI TS 119 472 -1 V1.2.1 (2026–02). Odczytuje się je z uwzględnieniem następujących dostosowań:

1) 2.1.

Normative references

— [16] ETSI EN 319 412 -1 V1.6.1 (2025-06): „Podpisy elektroniczne i infrastruktura (ESI); Profile certyfikatu; Część 1: Opis ogólny oraz ogólne struktury danych”.

— [17] ETSI TS 119 412 -6 V1.1.1 (2025-09): „Podpisy elektroniczne i infrastruktura zaufania (ESI); Profile certyfikatu; Część 6: Wymagania dotyczące profili certyfikatów dla dostawców PID, portfela, EAA, QEAA i PSBEAA”.

— [25] Wykaz statusów tokenów (Token Status List – TSL) opracowany przez IETF, draft-ietf-oauth-status-list-20: „Token Status List”, 20 kwietnia 2026 r.

2) 4.2.11.1.

General requirements

— EAA-4.2.11.1-06: W przypadku gdy element statusu jest stosowany w odniesieniu do danych identyfikujących osobę, kwalifikowanych elektronicznych poświadczeń atrybutów lub elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu, wskazuje on jedynie, czy poświadczenie zostało unieważnione, czy nie, i nie obsługuje żadnych innych wartości statusu, np. zawieszenia.

— EAA-4.2.11.1-06.1: W przypadku gdy poświadczenie zostało unieważnione, unieważnienie takie ma charakter trwały.

3) 4.2.13.

EAA short-lived

— EAA-4.2.13-03: W przypadku gdy poświadczenia krótkoterminowe są wydawane z okresem ważności nieprzekraczającym 24 godzin, unieważnianie nie jest wymagane.

4) 4.6.3.

Wymogi dotyczące EU EAA wydane przez organ sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu (PuB-EAA)

— PuB-EAA-4.6.2-03: nieważny.

— Pub-EAA-4.6.2-04: nieważny.

— PuB-EAA-4.6.3-03: Podpis cyfrowy PuB-EAA powinien zawierać kwalifikowany certyfikat potwierdzający podpis cyfrowy PuB-EAA.

— PuB-EAA-4.6.3-04: Kwalifikowany certyfikat potwierdzający podpis cyfrowy PuB-EAA musi spełniać wymogi pkt 8 normy ETSI TS 119412-6 v1.1.1 i zawierać QcType qcStatement określone w normie ETSI EN 319 412-5 v2.5.1, o wartości id-etsi-qct-eidaspsbeaa określonej w następujący sposób:

id-etsi-qct-eidaspsbeaa OBJECT IDENTIFIER::= {id-etsi-eidas2-qct-extensions 3} – certyfikat, o którym mowa w art. 45f ust. 1 lit. b), potwierdzający kwalifikowany podpis elektroniczny lub kwalifikowaną pieczęć elektroniczną podmiotu sektora publicznego, o którym mowa w art. 3 pkt 46 rozporządzenia (UE) nr 910/2014.

5) 5.2.10.1.

General requirements

— EAA-5.2.10.1-04: nieważny.

— EAA-5.2.10.1-05: nieważny.

— EAA-5.2.10.1-06: Element statusu może zawierać element status_list, jak określono w pkt 6.2 IETF draft-ietf-oauth-status-20 [25].

— EAA-5.2.10.1-07: nieważny.

— EAA-5.2.10.1-08: nieważny.

— EAA-5.2.10.1-09: nieważny.

— EAA-5.2.10.1-10: nieważny.

— EAA-5.2.10.1-11: nieważny.

— EAA-5.2.10.1-12: nieważny.

6) 6.2.10.1.

General requirements

— EAA-6.2.10.1-01: Jeżeli elektroniczne poświadczenie atrybutów zgodne z normą ISO/IEC mdoc wykorzystuje mechanizm wykazu statusów poświadczeń określony w EAA-6.2.10.1-02.2 lub mechanizm wykazu unieważnień poświadczeń określony w EAA-6.2.10.1-02.3, jego obiekt bezpieczeństwa mobilnego (MSO) zawiera strukturę statusu określoną w EAA-6.2.10.1-17, obejmującą informacje o unieważnieniu MSO.

— EAA-6.2.10.1-01.1: W przypadku stosowania mechanizmu wykazu identyfikatorów element statusu zawiera element „identifier_list” określony w EAA-6.2.10.1-11.

— EAA-6.2.10.1-01.2: W przypadku stosowania mechanizmu wykazu statusów element statusu zawiera element „status_list” określony w EAA-6.2.10.1-13.

— UWAGA:

— Struktura statusu zawiera odniesienie do wykazu unieważnień MSO.

— Wykaz unieważnień MSO stanowi strukturę COSE_Sign1 wskazującą, czy dany MSO został unieważniony.

— Struktura statusu zawiera wszystkie informacje niezbędne stronie ufającej portfela do ustalenia autentyczności wykazu unieważnień MSO.

— EAA-6.2.10.1-02: Dostawca danych identyfikujących osobę, dostawca kwalifikowanych elektronicznych poświadczeń atrybutów lub dostawca elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu stosuje jedną z następujących metod unieważniania danych identyfikujących osobę, kwalifikowanych elektronicznych poświadczeń atrybutów lub elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu:

— EAA-6.2.10.1-02.1: W przypadku gdy krótkoterminowe elektroniczne poświadczenia atrybutów są wydawane z okresem ważności nieprzekraczającym 24 godzin, unieważnianie nie jest wymagane.

— EAA-6.2.10.1-02.2: W celu zakodowania informacji o unieważnieniu jako wykaz statusów stosuje się mechanizm wykazu statusów poświadczeń.

— EAA-6.2.10.1-02.2.1: Mechanizm wykazu statusów powoduje unieważnienie obiektu bezpieczeństwa mobilnego (MSO) w zależności od tego, czy bit na pozycji określonej przez wystawcę w MSO ma wartość „true” w wykazie statusów.

— EAA-6.2.10.1-02.2.2: Mechanizm wykazu statusów określono w specyfikacji wykazu statusów tokenów (draft-ietf-oauth-status-list-20).

— EAA-6.2.10.1-02.3: W celu zakodowania informacji o unieważnieniu jako wykaz identyfikatorów stosuje się mechanizm wykazu unieważnień poświadczeń.

— EAA-6.2.10.1-02.3.1: Mechanizm wykazu identyfikatorów powoduje unieważnienie obiektu bezpieczeństwa mobilnego (MSO) w zależności od tego, czy identyfikator określony przez wystawcę w MSO znajduje się w wykazie identyfikatorów.

— EAA-6.2.10.1-02.3.2: EAA-6.2.10.1-06, EAA-6.2.10.1-08, EAA-6.2.10.1-09, EAA-6.2.10.1-10 i EAA-6.2.10.1-11 określają mechanizm wykazu identyfikatorów oparty na wymaganiach specyfikacji wykazu statusów tokenów, w tym na wspólnych elementach mechanizmu wykazu statusów i wykazu identyfikatorów.

— EAA-6.2.10.1-03: W przypadku gdy element statusu jest stosowany w odniesieniu do danych identyfikujących osobę, kwalifikowanych elektronicznych poświadczeń atrybutów lub elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu, stosuje się wyłącznie status „revoked”.

— EAA-6.2.10.1-03.1: W przypadku wykazu statusów oznacza to, że stosuje się wyłącznie wartości „valid” i „invalid”, jak określono w specyfikacji wykazu statusów tokenów.

— EAA-6.2.10.1-03.2: W przypadku wykazu identyfikatorów w wykazie umieszcza się wyłącznie unieważnione obiekty bezpieczeństwa mobilnego (MSO), a nie MSO zawieszone tymczasowo.

— EAA-6.2.10.1-04: W przypadku unieważnienia obiektu bezpieczeństwa mobilnego (MSO) unieważnienie ma charakter trwały.

— EAA-6.2.10.1-05: Weryfikacja wykazu unieważnień MSO jest nieobowiązkowa dla strony ufającej portfela i, w stosownych przypadkach, musi odbywać się zgodnie z wymaganiami weryfikacji określonymi w specyfikacji wykazu statusów tokenów oraz w specyfikacji struktury statusu określonej w EAA-6.2.10.1-01.

— EAA-6.2.10.1-05.1: W przypadku gdy strona ufająca portfela musi mieć możliwość weryfikacji statusu unieważnienia danych identyfikujących osobę lub elektronicznych poświadczeń atrybutów, obsługuje ona zarówno mechanizm wykazu statusów poświadczeń, jak i mechanizm wykazu unieważnień poświadczeń określone w EAA-6.2.10.1-02.

— EAA-6.2.10.1-06: Elementy „identifier_list” i „status_list” w MSO mogą zawierać element „certificate”.

— EAA-6.2.10.1-06.1: W przypadku gdy element „certificate” jest obecny, zawiera on certyfikat obejmujący klucz publiczny użyty do podpisania lub opatrzenia pieczęcią certyfikatu najwyższego poziomu w elemencie „x5chain” w strukturze wykazu unieważnień MSO.

— EAA-6.2.10.1-06.1.1: Instancja strony ufającej portfela wykorzystuje ten certyfikat jako kotwicę zaufania do weryfikacji elementu „x5chain” w strukturze wykazu unieważnień MSO.

— EAA-6.2.10.1-06.2: W przypadku gdy element „certificate” nie występuje, certyfikat najwyższego poziomu w elemencie „x5chain” w strukturze wykazu unieważnień MSO zostaje podpisany lub opatrzony pieczęcią przy użyciu certyfikatu zastosowanego do podpisania certyfikatu w elemencie „x5chain” MSO.

— EAA-6.2.10.1-06.2.1: Instancja strony ufającej portfela wykorzystuje ten certyfikat jako kotwicę zaufania do weryfikacji elementu „x5chain” w strukturze wykazu unieważnień MSO.

— EAA-6.2.10.1-07: Wykaz unieważnień MSO wdraża się zgodnie ze specyfikacją wykazu statusów tokenów jako token wykazu statusów w formacie CWT.

— EAA-6.2.10.1-08: W odniesieniu do wykazu unieważnień MSO stosowanego w mechanizmie wykazu identyfikatorów i wykazu statusów zastosowanie mają następujące wymogi:

— element danych „exp” musi być obecny;

— element danych „ttl” może być obecny;

— element danych „aggregation_uri” w elemencie danych IdentifierList lub StatusList może być obecny, a dostawca danych identyfikujących osobę, dostawca kwalifikowanych elektronicznych poświadczeń atrybutów lub dostawca elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego odpowiedzialny za źródło autentyczne lub w jego imieniu może wykorzystywać ten element do wskazania obsługi mechanizmu agregacji określonego w specyfikacji wykazu statusów tokenów;

— CWT stanowi obiekt COSE_Sign1 wykorzystujący jeden z następujących algorytmów do obliczenia podpisu:

a) „ES256” (ECDSA z krzywą NIST P-256 i SHA-256);

b) „ES384” (ECDSA z krzywą NIST P-384 i SHA-384);

c) „ES512” (ECDSA z krzywą NIST P-521 i SHA-512);

d) „ESB256” (ECDSA z krzywą brainpoolP256r1 i SHA-256);

e) „ESB384” (ECDSA z krzywą brainpoolP384r1 i SHA-384);

f) „ESB512” (ECDSA z krzywą brainpoolP512r1 i SHA-512);

— CWT zawiera element „x5chain” w chronionym nagłówku, obejmujący certyfikat lub łańcuch certyfikatów umożliwiających weryfikację podpisu wykazu unieważnień MSO;

— rozszerzone użycie klucza identyfikatora obiektu określonego w specyfikacji wykazu statusów tokenów może być stosowane w certyfikacie podpisującym wykaz statusów i wykaz identyfikatorów, a instancje strony ufającej portfela mogą obsługiwać rozszerzone użycie klucza identyfikatorów obiektów określonych w tej specyfikacji; w odniesieniu do identyfikatora obiektu, dostawca kwalifikowanych elektronicznych poświadczeń atrybutów lub dostawca elektronicznych poświadczeń atrybutów wydanych przez podmiot sektora publicznego lub w jego imieniu nie oznacza pola „extended key usage” jako krytycznego w przypadku stosowania identyfikatora OID określonego w specyfikacji wykazu statusów tokenów.

— EAA-6.2.10.1-09: W drodze odstępstwa od wymogów specyfikacji wykazu statusów tokenów w odniesieniu do mechanizmu wykazu identyfikatorów zastosowanie mają następujące wymogi:

— wartość elementu danych „type” wynosi „application/identifierlist+cwt”;

— element danych „StatusList” nie występuje w zbiorze elementów danych CWT;

— struktura „IdentifierList” określona w EAA-6.2.10.1-11 występuje jako element danych w zbiorze elementów danych CWT przy użyciu klucza 65530.

— EAA-6.2.10.1-10: Struktura „IdentifierList” stanowi strukturę CBOR o następującej notacji CDDL:

IdentifierList = {

'identifiers': { * Identifier => IdentifierInfo },

? 'aggregation_uri': Aggregation_uri

* tstr => RFU

}

IdentifierInfo = { tstr/int => RFU }

Identifier = bstr

Aggregation_uri = tstr

— EAA-6.2.10.1-10.1: W przypadku gdy identyfikator w strukturze „IdentifierList” jest obecny, obiekt bezpieczeństwa mobilnego (MSO), który zawiera ten identyfikator w elemencie statusu, uznaje się za unieważniony.

— EAA-6.2.10.1-10.2: Element danych „Aggregation_uri” określono w pkt 9.2 specyfikacji wykazu statusów tokenów.

— EAA-6.2.10.1-10.3: Typ zawartości wykazu identyfikatorów ma postać „application/identifierlist+cwt”, zgodnie z wymogami określonymi w pkt 8.2 specyfikacji wykazu statusów tokenów.

— EAA-6.2.10.1-11: Do elementu „identifier_list” w MSO mają zastosowanie następujące wymogi (zob. EAA-6.2.10.1-17).

— EAA-6.2.10.1-11.1: Element „identifier_list” stanowi strukturę CBOR o następującej notacji CDDL:

IdentifierListInfo = {

'id': Identifier ,

'uri': URI,

? 'certificate': Certificate

* tstr => RFU

}

URI = tstr

Certificate = bstr

— EAA-6.2.10.1-11.2: REV-11.2: Aby zapobiec wykorzystywaniu identyfikatora jako korelacji między prezentacjami, musi on być niepowtarzalny dla każdego MSO.

— EAA-6.2.10.1-12: Do wykazu statusów mają zastosowanie następujące wymogi:

— EAA-6.2.10.1-12.1: Element „bits” w strukturze „StatusList” ma wartość 1.

— EAA-6.2.10.1-13: Do elementu „status_list” w MSO mają zastosowanie następujące wymogi (zob. EAA-6.2.10.1-17):

— EAA-6.2.10.1-13.1: Element „status_list” musi być zgodny z wymogami dotyczącymi struktury „StatusListInfo” określonymi w specyfikacji wykazu statusów tokenów i dodaje się opcjonalny element certyfikatu określony w EAA-6.2.10.1-06.

— EAA-6.2.10.1-13.2: Aby zapobiec wykorzystaniu indeksu statusu do korelacji między prezentacjami, kombinacja indeksu statusu i URI musi być niepowtarzalna dla każdego MSO.

— EAA-6.2.10.1-14: Dostawca portfela stosuje drugą (EAA-6.2.10.1-02.2) lub trzecią (EAA-6.2.10.1-02.3) spośród metod określonych w EAA-6.2.10.1-02 w celu unieważnienia poświadczenia instancji portfela oraz unieważnienia poświadczenia klucza.

— EAA-6.2.10.1-15: Dostawca portfela wdraża mechanizmy unieważniania poświadczeń określone w EAA-6.2.10.1-02 w swoim rozwiązaniu w zakresie portfela.

— EAA-6.2.10.1-16: Dostawca danych identyfikujących osobę i dostawca elektronicznych poświadczeń atrybutów muszą obsługiwać zarówno mechanizm wykazu statusów poświadczeń, jak i mechanizm wykazu unieważnień poświadczeń określone w EAA-6.2.10.1-02 na potrzeby weryfikacji statusu unieważnienia poświadczenia instancji portfela i poświadczenia klucza.

— EAA-6.2.10.1-17: Struktura „status” w MSO stanowi strukturę CBOR o następującej notacji CDDL:

Status = {

? 'identifier_list': IdentifierListInfo,

? 'status_list': StatusListInfo,

* tstr => RFU

}

Załącznik III

SPECYFIKACJE TECHNICZNE, O KTÓRYCH MOWA W ART. 10

— Specyfikacje techniczne:

— pkt 4.2.5 normy ETSI TS 119 472 -3 V1.1.1 (2026-03).

Załącznik IV

FORMATY PODPISU I PIECZĘCI, O KTÓRYCH MOWA W ART. 12

1. Obowiązkowy format podpisu lub pieczęci:

a) PAdES (ang. PDF Advanced Electronic Signature, zaawansowany podpis elektroniczny do podpisywania plików w formacie PDF), jak określono w normie ETSI EN 319 142 -1 V1.2.1 (2024-01); Podpisy elektroniczne i infrastruktura (ESI); Podpisy cyfrowe PAdES; Część 1: Elementy składowe i podstawowe profile podpisów PAdES.

2. Wykaz opcjonalnych formatów podpisu lub pieczęci:

a) XAdES – jak określono w „ETSI EN 319 132-1 V1.2.1 (2022-02) Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures (XAdES)” – do podpisywania plików w formacie XML;

b) JAdES – jak określono w „ETSI TS 119 182-1 V1.2.1 (2024-07) Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 1: Building blocks and JAdES baseline signatures” – do podpisywania plików w formacie JSON;

c) CAdES (ang. CMS Advanced Electronic Signature, zaawansowany podpis elektroniczny CMS) – jak określono w „ETSI EN 319 122-1 V1.3.1 (2023-06) Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures” – do podpisywania plików w formacie CMS;

d) ASiC (ang. Associated Signature Container, podpis elektroniczny wykorzystujący konteneryzację) – jak określono w „ETSI EN 319 162-1 V1.1.1 (2016-04) Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 1: Building blocks and ASiC baseline containers” oraz „ETSI EN 319 162-2 V1.1.1 (2016-04) Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC); Part 2: Additional ASiC containers” – do podpisywania kontenerów.

3. Interfejs programowania aplikacji:

ETSI TS 119 432 v1.3.1 (2026-03), pkt 6.4.3, A.6, A.7 i A.8.

Załącznik VI

UNIJNY ZNAK ZAUFANIA DLA PORTFELA TOŻSAMOŚCI CYFROWEJ W WERSJI KOLOROWEJ

Załącznik VII

UNIJNY ZNAK ZAUFANIA DLA PORTFELA TOŻSAMOŚCI CYFROWEJ W WERSJI CZARNO-BIAŁEJ

Załącznik VIII

DANE DOTYCZĄCE UNIJNEGO ZNAKU ZAUFANIA DLA PORTFELA TOŻSAMOŚCI CYFROWEJ

Dane

Opis

Kodowanie

Status

TrustMarkResourceURL

Adres URL grafiki unijnego znaku zaufania dla portfela tożsamości cyfrowej oraz zasobów informacyjnych dla użytkownika w interfejsie użytkownika portfela.

URL

obowiązkowe

ListOfCertifiedWalletsURL

Adres URL publicznego wykazu certyfikowanych rozwiązań w zakresie portfela w UE określonego w rozporządzeniu wykonawczym Komisji (UE) 2025/849 (1).

URL

obowiązkowe

ListOfCertifiedWalletsQRCode

QR Code zawierający informacje z ListOfCertifiedWalletsURL.

ISO-8859-1 Byte mode QR code

opcjonalne

WalletSolutionInfoPageURL

Adres URL strony informacyjnej certyfikowanego rozwiązania w zakresie portfela na stronie wykazu certyfikowanych rozwiązań w zakresie portfela, stanowiący ListOfCertifiedWalletsURL uzupełniony znakiem „?” oraz identyfikatorem WalletSolutionID danego rozwiązania w zakresie portfela.

URL

obowiązkowe

WalletSolutionInfoPageQRCode

Kod QR zawierający informacje o WalletSolutionInfoPageUR.

ISO-8859-1 Byte mode QR code

opcjonalne

WalletVerifierToolURL*

Adres URL prowadzący do punktu końcowego narzędzia weryfikacji portfela /.well-known/openid-credential-issuer, wykorzystywanego do pobierania metadanych dostawcy poświadczeń.

URL

opcjonalny

(1) Rozporządzenie wykonawcze Komisji (UE) 2025/849 z dnia 6 maja 2025 r. ustanawiające zasady stosowania rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 910/2014 w odniesieniu do przekazywania informacji Komisji i grupie współpracy na potrzeby wykazu certyfikowanych europejskich portfeli tożsamości cyfrowej (Dz.U. L, 2025/849, 7.5.2025, ELI: http://data.europa.eu/eli/reg_impl/2025/849/oj).

(

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

(

2

)

https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_pl.

(

3

) RFC 7519: JSON Web Token (JWT), maj 2015 r.

(

4

) OpenID for Verifiable Credential Issuance v1.0, https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html.

(

5

) ETSI, „Podpisy elektroniczne i infrastruktura (ESI); Podpisy cyfrowe JAdES; Część 3: poziomy i profile bazowe JAdES”, ETSI TS 119 472-3, V1.1.1, marzec 2026 r.

(

6

) Ten element danych jest zdefiniowany w tym wspólnym repozytorium danych umożliwiających identyfikację, ponieważ nie jest częścią specyfikacji OID4VCI.