Załącznik II

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

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

1) 1.

Scope

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

a) Profil opiera się na:

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

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

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

b) Profil opiera się na:

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

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

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

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

2) 2.1.

Normative references

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

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

3) 4.1.

EAAP implementation based on SD-JWT VC

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

4) 4.2.

EAAP implementation based on ISO/IEC-mdoc

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

— Note2: nieważny.

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

5) 4.3.

EAAP implementation with mediating API

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

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

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

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

6) 4.4.

Walidacja strony ufającej portfela i kontrole nadmiernych zapytań

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

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

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

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

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

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

7) 5.1.

Introduction

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

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

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

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

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

8) 5.2.

Requirements on EUDI Wallet and RP support

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

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

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

9) 5.3.2.

ISO/IEC-mdoc EAAP Request contents

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

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

RequestInfo = {

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

}

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

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

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

— UWAGA 3: nieważny.

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

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

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

10) 5.3.3

ISO/IEC-mdoc EAAP Response profile

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

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

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

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

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

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

11) 5.4

Requirements for API mediated mechanism

5.4.1

ISO/IEC 18013-7-related requirements

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

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

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

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

12) 5.4.2.

Dodatkowe wymagania

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

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

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

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

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

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

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

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

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

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

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

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

13) 6.2.

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

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

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

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

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

— UWAGA 5: nieważny.

14) 6.3.1.

General requirements

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

— UWAGA 1:

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

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

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

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

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

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

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

15) 6.3.2.1.

General requirements

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

16) 6.3.2.2.

Wymagania dotyczące obiektu żądania

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

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

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

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

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

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

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

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

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

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

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

— Uwaga 2: nieważny

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

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

17) 6.3.3.

Authorization Response (EAAP response) profile

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

18) 6.4.1.

General requirements

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

— UWAGA: nieważny.

19) 6.5.2.

Additional requirements

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

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

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

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

20) 6.5.3.

Specific requirements when requesting ISO/IEC 18013-5 EAAP

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

(

1

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