Załącznik II

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

}