Załącznik Ib

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.