(EU) 2024/2979Prováděcí nařízení Komise (EU) 2024/2979 ze dne 28. listopadu 2024, kterým se stanoví prováděcí pravidla k nařízení Evropského parlamentu a Rady (EU) č. 910/2014, pokud jde o integritu a základní funkce evropských peněženek digitální identity

Publikováno: Úř. věst. L 2979, 4.12.2024 Druh předpisu: Prováděcí nařízení
Přijato: 28. listopadu 2024 Autor předpisu: Evropská komise
Platnost od: 24. prosince 2024 Nabývá účinnosti: 24. prosince 2024
Platnost předpisu: Ano Pozbývá platnosti:
Konsolidované znění předpisu s účinností od 11. srpna 2026

Text aktualizovaného znění s celou hlavičkou je dostupný pouze pro registrované uživatele.



Tento dokument slouží výhradně k informačním účelům a nemá žádný právní účinek. Orgány a instituce Evropské unie nenesou za jeho obsah žádnou odpovědnost. Závazná znění příslušných právních předpisů, včetně jejich právních východisek a odůvodnění, jsou zveřejněna v Úředním věstníku Evropské unie a jsou k dispozici v databázi EUR-Lex. Tato úřední znění jsou přímo dostupná přes odkazy uvedené v tomto dokumentu

►B

PROVÁDĚCÍ NAŘÍZENÍ KOMISE (EU) 2024/2979

ze dne 28. listopadu 2024,

kterým se stanoví prováděcí pravidla k nařízení Evropského parlamentu a Rady (EU) č. 910/2014, pokud jde o integritu a základní funkce evropských peněženek digitální identity

(Úř. věst. L 2979 4.12.2024, s. 1)

Ve znění:

 

 

Úřední věstník

  Č.

Strana

Datum

►M1

PROVÁDĚCÍ NAŘÍZENÍ KOMISE (EU) 2026/1731 ze dne 15. července 2026,

  L 1731

1

22.7.2026




▼B

PROVÁDĚCÍ NAŘÍZENÍ KOMISE (EU) 2024/2979

ze dne 28. listopadu 2024,

kterým se stanoví prováděcí pravidla k nařízení Evropského parlamentu a Rady (EU) č. 910/2014, pokud jde o integritu a základní funkce evropských peněženek digitální identity



KAPITOLA I

OBECNÁ USTANOVENÍ

Článek 1

Předmět a oblast působnosti

Toto nařízení stanoví pravidla pro integritu a základní funkce peněženek, která je třeba pravidelně aktualizovat, aby byla v souladu s vývojem technologií a norem a s prací prováděnou na základě doporučení (EU) 2021/946, a zejména s architekturou a referenčním rámcem.

Článek 2

Definice

Pro účely tohoto nařízení se rozumí:

1) 

„bezpečnou kryptografickou aplikací peněženky“ aplikace, která spravuje kritická aktiva prostřednictvím propojení s kryptografickými a nekryptografickými funkcemi poskytovanými bezpečným kryptografickým prostředkem peněženky a jejich využívání;

2) 

„jednotkou peněženky“ jedinečná konfigurace řešení peněženky, která zahrnuje instance peněženky, bezpečné kryptografické aplikace peněženky a bezpečné kryptografické prostředky peněženky, které poskytovatel peněženky poskytuje jednotlivému uživateli peněženky;

3) 

„kritickými aktivy“ aktiva v rámci jednotky peněženky nebo ve vztahu k ní, která jsou tak mimořádně důležitá, že ohrožení jejich dostupnosti, důvěrnosti nebo integrity by mělo velmi vážný a oslabující účinek na schopnost spoléhat se na jednotku peněženky;

4) 

„poskytovatelem osobních identifikačních údajů“ fyzická nebo právnická osoba odpovědná za vydávání a zneplatnění osobních identifikačních údajů a za zajištění kryptografického provázání osobních identifikačních údajů uživatele s jednotkou peněženky;

5) 

„uživatelem peněženky“ uživatel, který má jednotku peněženky pod kontrolou;

6) 

„stranou spoléhající se na peněženku“ spoléhající se strana, která má v úmyslu spoléhat se na jednotky peněženky při poskytování veřejných nebo soukromých služeb prostřednictvím digitální interakce;

7) 

„poskytovatelem peněženky“ fyzická nebo právnická osoba, která poskytuje řešení peněženky;

8) 

„potvrzením jednotky peněženky“ datový objekt, který popisuje komponenty jednotky peněženky nebo umožňuje autentizaci a ověření platnosti těchto komponentů;

9) 

„vloženými zásadami zpřístupňování informací“ soubor pravidel, který je součástí elektronického potvrzení atributů jeho poskytovatelem a ve kterém jsou uvedeny podmínky, jež musí strana spoléhající se na peněženku splnit, aby získala přístup k elektronickému potvrzení atributů;

10) 

„instancí peněženky“ aplikace nainstalovaná a nakonfigurovaná v zařízení nebo prostředí uživatele peněženky, která je součástí jednotky peněženky a kterou uživatel peněženky používá k interakci s jednotkou peněženky;

11) 

„řešením peněženky“ kombinace softwaru, hardwaru, služeb, nastavení a konfigurací, včetně instancí peněženky, jedné nebo více bezpečných kryptografických aplikací peněženky a jednoho nebo více bezpečných kryptografických prostředků peněženky;

12) 

„bezpečným kryptografickým prostředkem peněženky“ prostředek odolný proti neoprávněné manipulaci, který poskytuje prostředí propojené s bezpečnou kryptografickou aplikací peněženky a používaný touto aplikací k ochraně kritických aktiv a poskytování kryptografických funkcí pro bezpečné provádění kritických operací;

13) 

„kryptografickou operací peněženky“ kryptografický mechanismus nezbytný v souvislosti s autentizací uživatele peněženky a vydáváním nebo předkládáním osobních identifikačních údajů nebo elektronických potvrzení atributů;

14) 

„přístupovým certifikátem strany spoléhající se na peněženku“ certifikát pro elektronické pečetě nebo podpisy ověřující pravost a platnost strany spoléhající se na peněženku vydaný poskytovatelem přístupových certifikátů strany spoléhající se na peněženku;

15) 

„poskytovatelem přístupových certifikátů strany spoléhající se na peněženku“ fyzická nebo právnická osoba pověřená členským státem vydáváním přístupových certifikátů strany spoléhající se na peněženku stranám spoléhajícím se na peněženku registrovaným v tomto členském státě.

KAPITOLA II

INTEGRITA EVROPSKÝCH PENĚŽENEK DIGITÁLNÍ IDENTITY

Článek 3

Integrita jednotky peněženky

1.  
Jednotky peněženky nesmí provést žádnou funkci uvedenou v čl. 5a odst. 4 nařízení (EU) č. 910/2014, kromě autentizace uživatele peněženky za účelem získání přístupu k jednotce peněženky, dokud jednotka peněženky úspěšně neautentizuje uživatele peněženky.

▼M1 —————

▼B

Článek 4

Instance peněženky

1.  
Instance peněženky používají ke správě kritických aktiv alespoň jeden bezpečný kryptografický prostředek peněženky.
2.  
Poskytovatelé peněženek zajistí integritu, pravost a důvěrnost komunikace mezi instancemi peněženky a bezpečnými kryptografickými aplikacemi peněženky.
3.  
Pokud se kritická aktiva týkají provádění elektronické identifikace na vysoké úrovni záruky, musí být kryptografické operace peněženky nebo jiné operace zpracovávající kritická aktiva prováděny v souladu s požadavky na vlastnosti a formu prostředků pro elektronickou identifikaci na vysoké úrovni záruky, jak je stanoveno v prováděcím nařízení Komise (EU) 2015/1502 ( 1 ).

Článek 5

Bezpečné kryptografické aplikace peněženky

1.  

Poskytovatelé peněženek zajistí, že bezpečné kryptografické aplikace peněženky:

▼M1

a) 

provedou kryptografické operace peněženky s kritickými aktivy uloženými v bezpečném kryptografickém prostředku peněženky, která nejsou vyžadována k autentizaci uživatele peněženky, pouze v případech, kdy tyto aplikace úspěšně autentizovaly uživatele peněženky;

▼B

b) 

autentizují uživatele peněženky v rámci provádění elektronické identifikace na vysoké úrovni záruky; provedou autentizaci uživatelů peněženky v souladu s požadavky na vlastnosti a formu prostředků pro elektronickou identifikaci na vysoké úrovni záruky, jak je stanoveno v prováděcím nařízení (EU) 2015/1502;

c) 

jsou schopny bezpečně generovat nové kryptografické klíče;

d) 

jsou schopny bezpečně vymazat kritická aktiva;

e) 

jsou schopny vygenerovat důkaz o vlastnictví soukromých klíčů;

f) 

chrání soukromé klíče generované těmito bezpečnými kryptografickými aplikacemi peněženky po dobu existence těchto klíčů;

g) 

splňují požadavky na vlastnosti a formu prostředků pro elektronickou identifikaci na vysoké úrovni záruky, jak je stanoveno v prováděcím nařízení (EU) 2015/1502;

h) 

jsou jedinými komponenty schopnými provádět kryptografické operace peněženky a jakékoli jiné operace s kritickými aktivy v rámci provádění elektronické identifikace na vysoké úrovni záruky.

2.  
Pokud se poskytovatelé peněženek rozhodnou poskytnout bezpečnou kryptografickou aplikaci pro vestavěný zabezpečený prvek, založí své technické řešení na technických specifikacích uvedených v příloze I nebo na jiných rovnocenných technických specifikacích.

▼M1

Článek 5a

Kryptografické mechanismy

Poskytovatelé peněženek používají pro účely čl. 4 odst. 2 pouze kryptografické mechanismy uvedené v příloze Ia.

▼B

Článek 6

Pravost a platnost jednotky peněženky

▼M1

1.  
Poskytovatelé peněženek vydají potvrzení jednotky peněženky pro každou jednotku peněženky. Poskytovatelé peněženek podepíší nebo opatří pečetí potvrzení jednotky peněženky tak, aby platnost podpisů nebo pečetí mohla být ověřena prostřednictvím certifikátu uvedeného na seznamu v souladu s přílohou II oddílem 2 bodem 1 písm. h) prováděcího nařízení (EU) 2024/2980.
2.  
Poskytovatelé peněženek zajistí, aby potvrzení jednotky peněženky uvedená v odstavci 1 splňovala technické specifikace stanovené v příloze Ib.

▼B

3.  

Poskytovatelé peněženek:

a) 

informují uživatele peněženky o jejich právech a povinnostech v souvislosti s jejich jednotkou peněženky;

▼M1

b) 

poskytují mechanismy pro bezpečnou identifikaci a autentizaci uživatelů peněženek, které jsou nezávislé na jednotkách peněženky;

▼B

c) 

zajistí, aby uživatelé peněženky měli právo požádat o zneplatnění potvrzení jejich jednotky peněženky pomocí mechanismů autentizace uvedených v písmenu (b).

Článek 7

Zneplatnění potvrzení jednotky peněženky

1.  
Poskytovatelé peněženek jsou jedinými subjekty, které mohou zneplatnit potvrzení jednotky peněženky, která poskytli.
2.  
Poskytovatelé peněženek stanoví veřejně dostupné zásady, v nichž uvedou podmínky a časový rámec pro zneplatnění potvrzení jednotky peněženky.
3.  
Pokud poskytovatelé peněženek zneplatní potvrzení jednotky peněženky, informují o zneplatnění jednotek peněženky dotčené uživatele peněženky do 24 hodin, včetně uvedení důvodu zneplatnění a důsledků pro uživatele peněženky. Tyto informace se poskytují stručným a snadno přístupným způsobem a s využitím jasného a srozumitelného jazyka.
4.  
Pokud poskytovatelé peněženek zneplatní potvrzení jednotky peněženky, zveřejní stav platnosti potvrzení jednotky peněženky způsobem zachovávajícím soukromí a popíší umístění těchto informací v potvrzení jednotky peněženky.

KAPITOLA III

ZÁKLADNÍ FUNKCE A VLASTNOSTI EVROPSKÝCH PENĚŽENEK DIGITÁLNÍ IDENTITY

Článek 8

Formáty pro osobní identifikační údaje a elektronická potvrzení atributů

Poskytovatelé peněženek zajistí, aby řešení peněženky podporovala používání osobních identifikačních údajů a elektronických potvrzení atributů vydaných v souladu se seznamem norem uvedených v příloze II.

Článek 9

Protokoly transakcí

1.  
Bez ohledu na to, zda je transakce úspěšně dokončena, instance peněženky zaznamenávají všechny transakce se stranami spoléhajícími se na peněženku a s ostatními jednotkami peněženky, včetně elektronického podepisování a opatřování elektronickou pečetí.
2.  

Zaznamenané informace musí obsahovat alespoň:

a) 

čas a datum transakce;

▼M1

b) 

jméno, kontaktní údaje a jedinečný identifikátor příslušné strany spoléhající se na peněženku a členský stát, v němž je tato strana spoléhající se na peněženku usazena;

▼B

c) 

typ nebo typy údajů požadovaných a předkládaných v transakci;

d) 

v případě nedokončených transakcí důvod jejich nedokončení.

3.  
Poskytovatelé peněženek zajistí integritu, pravost a důvěrnost zaznamenaných informací.
4.  
Instance peněženky zaznamenávají zprávy zaslané uživatelem peněženky úřadům pro ochranu osobních údajů prostřednictvím jeho jednotky peněženky.
5.  
Protokoly uvedené v odstavcích 1 a 2 jsou přístupné poskytovateli peněženky, pokud je to nezbytné pro poskytování služeb peněženky, na základě výslovného předchozího souhlasu uživatele peněženky.
6.  
Protokoly uvedené v odstavcích 1 a 2 zůstávají přístupné po dobu, po kterou to vyžaduje právo Unie nebo členských států.
7.  
Poskytovatelé peněženek umožňují uživatelům peněženek export zaznamenaných informací uvedených v odstavci 2.

Článek 10

Vložené zpřístupňování informací

▼M1

1.  
Poskytovatelé peněženek zajistí, aby elektronická potvrzení atributů vydaná v souladu s technickými specifikacemi platnými pro obecné vložené zásady zpřístupňování informací uvedené v příloze III mohla být zpracovávána jimi poskytovanými jednotkami peněženky.

▼B

2.  
Instance peněženky jsou schopny zpracovávat a předkládat tyto vložené zásady zpřístupňování informací uvedené v odstavci 1 ve spojení s údaji obdrženými od žádající strany spoléhající se na peněženku.
3.  
Instance peněženky ověří, zda strana spoléhající se na peněženku splňuje požadavky vložených zásad zpřístupňování informací, a o výsledku informuje uživatele peněženky.

Článek 11

Kvalifikované elektronické podpisy a pečetě

1.  
Poskytovatelé peněženek zajistí, aby uživatelé peněženek mohli získat kvalifikované certifikáty pro kvalifikované elektronické podpisy nebo pečetě, které jsou spojeny s kvalifikovanými prostředky pro vytváření podpisů nebo pečetí, jež jsou ve vztahu k instancím peněženky místní, externí nebo dálkové.
2.  
Poskytovatelé peněženek zajistí, aby řešení peněženky podporovala bezpečné rozhraní k jednomu z následujících typů kvalifikovaných prostředků pro vytváření podpisů nebo pečetí: místní, externí nebo na dálku spravované kvalifikované prostředky pro vytváření podpisů nebo pečetí pro účely používání kvalifikovaných certifikátů uvedených v odstavci 1.
3.  
Poskytovatelé peněženek zajistí, aby uživatelé peněženek, kteří jsou fyzickými osobami, měli alespoň pro neprofesní účely bezplatný přístup k aplikacím pro vytváření podpisů, které umožňují vytváření bezplatných kvalifikovaných elektronických podpisů pomocí certifikátů uvedených v odstavci 1.

Článek 12

Aplikace pro vytváření podpisů

1.  
Aplikace pro vytváření podpisů používané jednotkami peněženky mohou být poskytovány poskytovateli peněženek, poskytovateli služeb vytvářejících důvěru, nebo stranami spoléhajícími se na peněženku.
2.  

Aplikace pro vytváření podpisů mají tyto funkce:

a) 

podepisování údajů poskytnutých uživatelem peněženky nebo jejich opatřování pečetí;

b) 

podepisování údajů poskytnutých spoléhající se stranou nebo jejich opatřování pečetí;

▼M1

c) 

vytváření podpisů nebo pečetí v souladu alespoň s povinným formátem podpisu nebo pečeti uvedeným v příloze IV;

▼B

d) 

informování uživatelů peněženky o výsledku procesu vytváření podpisu nebo pečeti.

▼M1

3.  
Aplikace pro vytváření podpisů mohou být buď integrovány do instancí peněženky, nebo mohou být externí.

▼M1

4.  
Aplikace pro vytváření podpisů používané jednotkami peněženky podporují alespoň aplikační programovací rozhraní uvedené v příloze IV.

▼B

Článek 13

Export a přenositelnost údajů

Jednotky peněženky musí, pokud je to technicky proveditelné a s výjimkou případů kritických aktiv, podporovat bezpečný export a přenositelnost osobních údajů uživatele peněženky, aby uživatel peněženky mohl přejít na jiné řešení peněženky způsobem, který zajišťuje vysokou úroveň záruky, jak je stanoveno v prováděcím nařízení (EU) 2015/1502.

Článek 14

Pseudonymy

▼M1 —————

▼B

2.  
Jednotky peněženky podporují na žádost strany spoléhající se na peněženku generování pseudonymu, který je specifický a jedinečný pro danou stranu spoléhající se na peněženku, a poskytnou tento pseudonym straně spoléhající se na peněženku buď samostatně, nebo v kombinaci s jakýmikoliv osobními identifikačními údaji nebo elektronickým potvrzením atributů, o nějž si tato strana spoléhající se na peněženku požádá.

▼M1

Článek 14a

Značka důvěry EU pro peněženku digitální identity

1.  
Poskytovatelé peněženek zajistí, aby jednotky peněženky zobrazovaly značku důvěry EU pro peněženku digitální identity. Značka důvěry EU pro peněženku digitální identity má podobu uvedenou v přílohách VI a VII.
2.  
Poskytovatelé peněženek zajistí, aby jednotky peněženky umožňovaly uživatelům peněženek přístup k informacím, které jim umožní ověřit stav certifikace řešení peněženky. Za tímto účelem poskytovatelé peněženek zajistí, aby po registraci řešení peněženky příslušné jednotky peněženky obsahovaly adresy URL poskytnuté Evropskou komisí pro toto ověření. Poskytovatelé peněženek zajistí, aby jejich jednotky peněženky měly přístup k údajům týkajícím se značky důvěry EU pro peněženku digitální identity, které jsou v souladu s technickými specifikacemi uvedenými v příloze VIII.
3.  
Referenčními barvami pro značku důvěry EU pro peněženku digitální identity jsou Pantone č. 661 a 116 nebo modrá (100 % azurová +67 % purpurová +0 % žlutá +40 % černá) a žlutá (0 % azurová +20 % purpurová +100 % žlutá +0 % černá), pokud se používá čtyřbarevný tisk; při použití barev RGB jsou referenčními barvami modrá (0 červená + 51 zelená + 153 modrá) a žlutá (255 červená + 204 zelená + 0 modrá).
4.  
Pouze v případech, kdy barvu není možné použít, lze značku důvěry EU pro peněženku digitální identity použít v černobílém provedení, jak je uvedeno v příloze VII.
5.  
Pokud je značka důvěry EU pro peněženku digitální identity použita na tmavém pozadí, lze ji použít v negativním formátu se stejnou barvou pozadí. Pokud je značka důvěry EU pro peněženku digitální identity použita barevně na barevném pozadí, které ztěžuje její viditelnost, může být kolem značky důvěry EU pro peněženku digitální identity použita ohraničující vnější linie, která zlepší kontrast s barvami pozadí.
6.  
Značka důvěry EU pro peněženku digitální identity má minimální velikost 64 × 85 pixelů při rozlišení 150 dpi.
7.  
Poskytovatelé peněženek zajistí, aby se značka důvěry EU pro peněženku digitální identity používala způsobem, který umožní jasné označení jednotky peněženky, jíž se značka důvěry EU pro peněženku digitální identity týká. Značka důvěry EU pro peněženku digitální identity může být spojena s grafickými nebo textovými prvky, které jasně označují jednotku peněženky, pro kterou je použita, za předpokladu, že nemění její rozpoznatelnost jako značky důvěry EU pro peněženku digitální identity ani její spojení se seznamem certifikovaných evropských peněženek digitální identity podle článku 5d nařízení (EU) č. 910/2014.
8.  
Pokud poskytovatelé peněženek zneplatnili potvrzení jednotky peněženky, zajistí, aby značka důvěry EU pro peněženku digitální identity již nebyla u příslušné jednotky peněženky zobrazena.

▼B

KAPITOLA IV

ZÁVĚREČNÁ USTANOVENÍ

Článek 15

Vstup v platnost

Toto nařízení vstupuje v platnost dvacátým dnem po vyhlášení v Úředním věstníku Evropské unie.

Toto nařízení je závazné v celém rozsahu a přímo použitelné ve všech členských státech.




PŘÍLOHA I

SEZNAM NOREM UVEDENÝCH V ČLÁNKU 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.

▼M1




PŘÍLOHA Ia

KRYPTOGRAFICKÉ MECHANISMY PODLE ČLÁNKU 5a

Evropská skupina pro certifikaci kybernetické bezpečnosti, podskupina pro kryptografii: „Dohodnuté kryptografické mechanismy“ zveřejněné Agenturou Evropské unie pro kybernetickou bezpečnost (ENISA) ( 2 ).




PŘÍLOHA Ib

TECHNICKÉ SPECIFIKACE PRO POTVRZENÍ JEDNOTKY PENĚŽENKY PODLE ČL. 6 ODST. 2a

1) Potvrzení jednotky peněženky obsahuje jedno nebo více potvrzení instance peněženky a jedno nebo více potvrzení klíče.

2) Potvrzení instance peněženky a potvrzení klíče musí splňovat následující požadavky:

a) 

Požadavky na formát

— 
FR-WIA-1: Potvrzením instance peněženky je JSON Web Token (JWT), jak je uvedeno v RFC 7519 ( 3 ), podepsaný nebo opatřený pečetí poskytovatelem peněženky pomocí kompaktního podpisu JAdES baseline B.
— 
FR-WIA-1.1: Potvrzení instance peněženky je potvrzení peněženky, jak je uvedeno v dodatku E k dokumentu OpenID for Verifiable Credential Issuance v1.0 ( 4 ) („OID4VCI“), a rozšířené, jak je uvedeno níže v C-WIA-1 a C-WIA-2.
— 
FR-KA-1: Potvrzením klíče musí být JWT podle specifikace v RFC 7519, podepsané nebo opatřené pečetí poskytovatelem peněženky pomocí kompaktního podpisu JAdES baseline B.
— 
FR_KA_1.1: Potvrzení klíče je potvrzení klíče, jak je uvedeno v dodatku D k OID4VCI, rozšířené podle specifikace v C_KA-1 a C_KA-2 níže.
b) 

Požadavky na přenos

— 
TR-WIA-1: Jednotka peněženky používá při vydávání osobních identifikačních údajů, kvalifikovaných nebo nekvalifikovaných elektronických potvrzení atributů nebo elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem potvrzení instance peněženky.
— 
TR-WIA-2: Poskytovatel peněženky ověří integritu instance peněženky a podepíše nebo opatří pečetí potvrzení instance peněženky.
— 
TR-WIA-2.1: Pokud poskytovatel peněženky vydá potvrzení instance peněženky, rozdíl mezi časem, kdy poskytovatel peněženky ověřil integritu instance peněženky, a časem, který uvede v parametru hlavičky „exp“ vydaného potvrzení instance peněženky, musí být kratší než 24 hodin.
— 
TR-WIA-2.2: Poskytovatel peněženky zajistí, aby jednotka peněženky obsahovala potvrzení instance peněženky potřebná pro vydání osobních identifikačních údajů a elektronických potvrzení atributů.
— 
TR-WIA-3: Při vydávání jednotka peněženky zašle autorizačnímu serveru potvrzení instance peněženky v rámci zaslané žádosti o autorizaci a žádosti o token, jak je stanoveno v OID4VCI.
— 
TR-WIA-3.1: Jednotka peněženky zašle potvrzení instance peněženky spolu s důkazem o vlastnictví („PoP“), jak je uvedeno v dodatku E k OID4VCI.
— 
TR-WIA-3.2: Jednotka peněženky zašle stejné potvrzení instance peněženky pouze jednomu autorizačnímu serveru.
— 
TR-WIA-3.2.1: Pokud poskytovatel peněženky používá možnost „per-issuer reuse“ uvedenou níže v R_WIA_1, může jednotka peněženky odeslat potvrzení instance peněženky stejnému autorizačnímu serveru vícekrát.
— 
TR-WIA-3.2.2: Pokud poskytovatel peněženky možnost „per-issuer reuse“ nepoužívá, musí jednotka peněženky použít potvrzení instance peněženky při nejvýše jednom procesu vydávání.
— 
TR-WIA-4: Pokud autorizační server obdrží potvrzení instance peněženky, ověří podpis potvrzení instance peněženky pomocí veřejného klíče v podpisovém certifikátu obsaženém v parametru „x5c“ v hlavičce JOSE potvrzení instance peněženky.
— 
TR-WIA-4.1: Autorizační server rovněž ověří, zda lze tento podpisový certifikát ověřit pomocí zdroje důvěry (trust anchor) na seznamu poskytovatelů peněženek uvedeném v článku 5 prováděcího nařízení (EU) 2024/2980, případně s využitím zprostředkujících certifikátů obsažených v parametru x5c.
— 
TR-WIA-4.2: Autorizační server ověří, zda nevypršela platnost potvrzení instance peněženky.
— 
TR-WIA-4.3: Autorizační server ověří podpis PoP pomocí veřejného klíče uvedeného v tvrzení „cnf“.
— 
TR_KA-1: Jednotka peněženky používá potvrzení klíče při vydávání osobních identifikačních údajů a při vydávání kvalifikovaných nebo nekvalifikovaných elektronických potvrzení atributů nebo elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem, jež jsou vázána na zařízení.
— 
TR_KA-1.1: Jednotka peněženky nepoužívá potvrzení klíče při vydávání kvalifikovaných nebo nekvalifikovaných elektronických potvrzení atributů nebo elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem, jež nejsou vázána na zařízení.
— 
TR_KA-2: Poskytovatel peněženky poskytne jednotce peněženky různá potvrzení klíčů pro WSCD jednotky peněženky a pro každý z jeho úložišť klíčů.
— 
TR_KA-2.1: Poskytovatel peněženky podepíše nebo opatří pečetí potvrzení klíče poté, co ověřil, že klíče uvedené v potvrzení klíče jsou uloženy v WSCD jednotky peněženky nebo úložišti klíčů popsaném v potvrzení klíče.
— 
TR_KA-2.2: Potvrzení klíče obsahuje alespoň jeden ověřený veřejný klíč. Počet klíčů v potvrzení klíče zaslaném vydavateli pověření by neměl překročit maximální velikost dávky, kterou tento vydavatel pověření uvedl ve svých metadatech vydavatele pověření; viz ETSI TS 119 472-3 ( 5 ), parametr „credential_configurations_supported. credential_metadata.credential_reuse_policy.options.batch_size“.
— 
TR_KA-2.3: Poskytovatel peněženky zahrne veřejný klíč (odpovídající soukromému klíči uloženému v WSCD nebo úložišti klíčů jednotky peněženky) do nejvýše jednoho potvrzení klíče.
— 
TR_KA-2.4: Jednotka peněženky použije potvrzení klíče při nejvýše jednom procesu vydávání nebo opětovného vydávání pověření.
— 
TR_KA-2.5: Poskytovatel peněženky zajistí, aby jednotka peněženky měla k dispozici potvrzení klíče potřebná pro vydávání osobních identifikačních údajů a elektronických potvrzení atributů vázaných na zařízení.
— 
TR_KA-3: Pokud je to při vydávání nutné, jednotka peněženky zahrne potvrzení klíče v rámci žádosti o vydání pověření vydavateli pověření v poli „proofs“, jak je uvedeno v OID4VCI, v ověření typu „jwt“, nebo typu „attestation“.
— 
TR_KA_3.1: Pokud jednotka peněženky obsahuje potvrzení klíče v prvku „jwt“, podepíše nebo opatří pečetí potvrzení klíče pomocí soukromého klíče odpovídajícího veřejnému klíči na indexu 0 pole „attested_keys“ v rámci objektu „key_attestation“.
— 
TR_KA-4: Pokud vydavatel pověření vydává pověření vázaná na zařízení, uvede v parametru „proof_types_supported“ v metadatech vydavatele pověření, jak je uvedeno v oddíle 12.2.4 OID4VCI, že podporuje typ ověření „jwt“ i typ ověření „attestation“ pro potvrzení klíče, která obsahují objekt „key_attestations_required“.
— 
TR_KA-4.1: Pokud vydavatel pověření vydává pověření, která nejsou vázána na zařízení, vynechá parametry „proof_types_supported“ a „cryptographic_binding_methods_supported“ v metadatech vydavatele pověření.
— 
TR_KA-5: Pokud vydavatel pověření obdrží potvrzení klíče v typu ověření „jwt“ nebo „attestation“, ověří podpis potvrzení klíče pomocí veřejného klíče v podpisovém certifikátu obsaženém v parametru „x5c“ v hlavičce potvrzení klíče JOSE a ověří tento podpisový certifikát pomocí zdroje důvěry (trust anchor) na seznamu poskytovatelů peněženek uvedeném v článku 5 prováděcího nařízení (EU) 2024/2980, případně s využitím zprostředkujících certifikátů obsažených v parametru „x5c“.
— 
TR_KA-6: Pokud vydavatel pověření obdrží potvrzení klíče v typu ověření „jwt“, ověří podpis prvku „jwt“ podle klíče na indexu 0 pole „attested_keys“ v rámci objektu „key_attestation“ obsaženého v prvku „jwt“.
— 
TR_KA-6.1: Vydavatel pověření ověří, že pole „nonce“ prvku „jwt“ obsahuje platný c_nonce z nonce_endpoint, jak je uvedeno v OID4VCI.
— 
TR_KA-7: Pokud vydavatel pověření obdrží potvrzení klíče v typu ověření „attestation“, ověří, že objekt „key_attestation“ obsahuje platný c_nonce z nonce_endpoint.
— 
TR_KA-8: Poskytovatel osobních identifikačních údajů zajistí, aby osobní identifikační údaje byly vázány na veřejný klíč, který pochází z potvrzení klíče uvádějícího WSCD.
c) 

Požadavky na obsah

— 
C_WIA-1: Potvrzení instance peněženky obsahuje následující údaje:
— 
tvrzení „wallet_name“ uvedené v dodatku E k OID4VCI, přičemž jeho hodnotou je identifikátor řešení peněženky, který lze nalézt na seznamu poskytovatelů peněženek uvedeném v článku 5 prováděcího nařízení (EU) 2024/2980,
— 
tvrzení „wallet_version“  ( 6 ), což je řetězec, jehož hodnotou je verze řešení peněženky,
— 
tvrzení „wallet_solution_certification_information“, což je objekt JSON obsahující informace o subjektu posuzování shody, který certifikoval řešení peněženky, případně číslo certifikace a další relevantní údaje týkající se certifikace,
— 
tvrzení „client_status“ obsahující dvě podpole:
— 
„status“: odkaz na seznam stavů podle dodatku E k OID4VCI, který představuje stav zneplatnění instance peněženky. Podrobnosti viz oddíl e) níže,
— 
„exp“: NumericDate, jak je uvedeno v RFC 7519, definující dobu, po kterou bude poskytovatel peněženky udržovat stav zneplatnění na indexu seznamu stavů, na který odkazuje podpole „status“,
— 
tvrzení „exp“ uvedené v dodatku E k OID4VCI.
— 
POZNÁMKA: Tvrzení „client_status.status“ v potvrzení instance peněženky představuje stav zneplatnění instance peněženky, nikoli stav zneplatnění samotného potvrzení. Jak je popsáno v R_WIA-1 níže, poskytovatel peněženky se může rozhodnout, že každé potvrzení instance peněženky se bude vztahovat na určitý autorizační server na základě skutečnosti, že všechna potvrzení zaslaná tomuto serveru obsahují stejnou hodnotu indexu v položce „client_status.status“.
— 
POZNÁMKA: Hodnotu „idx“ v tvrzení „status“ lze použít jako (párově) jedinečný identifikátor instance peněženky a jednotky peněženky.
— 
C_WIA-2: Potvrzení instance peněženky by mělo obsahovat také tvrzení „wallet_link“ uvedené v dodatku E k OID4VCI a hodnota tohoto tvrzení musí být URI, kde lze získat další informace o řešení peněženky.
— 
C_WIA-3: Autorizační server neinterpretuje parametr „exp“ v nejvyšší úrovni potvrzení instance peněženky jako konec doby udržování zneplatnění instance peněženky.
— 
POZNÁMKA: Parametr „exp“ v nejvyšší úrovni potvrzení instance peněženky označuje, kdy vyprší platnost samotného potvrzení.
— 
C_KA-1: Potvrzení klíče obsahuje:
— 
tvrzení „key_storage“ a „user_authentication“ uvedená v dodatku D k OID4VCI,
— 
atributy „key_storage“ a „user_authentication“ mají hodnotu „iso_18045_high“, kde potvrzení klíče uvádí WSCD,
— 
tvrzení „certification“ uvedené v dodatku D k OID4VCI, obsahující URL, kde lze získat informace o certifikaci, které dosáhl WSCD nebo úložiště klíčů, například Common Criteria nebo GlobalPlatform, hodnocené požadavky, jako je příslušný profil ochrany, a úroveň hodnocení,
— 
z těchto informací musí být možné určit, zda je úložiště klíčů WSCD,
— 
tvrzení „key_storage_status“ obsahující dvě podpole:
— 
„status“: odkaz na seznam stavů, jak je uvedeno v dodatku D.1 k OID4VCI. Hodnota představuje buď stav zneplatnění WSCD, nebo typu úložiště klíčů použitého k uložení ověřovaných klíčů, nebo – pod možností indexu per-key-attestation – stav zneplatnění WSCD nebo úložiště klíčů jednotlivé jednotky peněženky. Viz R_KA_1 níže, kde jsou uvedeny dostupné možnosti přiřazení indexů,
— 
„exp“: NumericDate, jak je uvedeno v RFC 7519, definující dobu, po kterou bude poskytovatel peněženky udržovat stav zneplatnění na indexu seznamu stavů, na který odkazuje podpole „status“,
— 
tvrzení „exp“ uvedené v dodatku D k OID4VCI.
— 
POZNÁMKA k hodnotě „idx“ v tvrzení „key_storage_status.status“ v potvrzení klíče: Pokud poskytovatel peněženky používá možnost „type-shared index“ (viz R_KA_1 níže), sdílejí všechna potvrzení klíčů pro stejný typ WSCD nebo úložiště klíčů stejný index seznamu stavů. Hodnota „idx“ proto není pro každou jednotku peněženky jedinečná. Naopak v případě, že poskytovatel peněženky používá možnost „per-key-attestation index“, je hodnota „idx“ jedinečná pro jednotku peněženky (nebo párově jedinečná pro vydavatele pověření). Ve všech případech však vydavatel pověření nepoužije hodnotu „idx“ v potvrzení klíče jako identifikátor jednotky peněženky, ale místo toho použije hodnotu „idx“ v potvrzení instance peněženky.
— 
C_KA-2: Pokud je potvrzení klíče zasíláno v typu ověření „attestation“, obsahuje také platný c_nonce, jak je uvedeno v dodatku F.3 k OID4VCI.
— 
C_KA-3: Vydavatel pověření neinterpretuje parametr „exp“ v nejvyšší úrovni potvrzení klíče jako konec doby udržování zneplatnění WSCD nebo úložiště klíčů.
— 
POZNÁMKA: Parametr „exp“ v nejvyšší úrovni potvrzení klíče označuje, kdy vyprší platnost samotného potvrzení klíče.
d) 

Požadavky na životní cyklus

— 
Tato příloha specifikuje následující parametry metadat vydavatele pověření:
— 
„preferred_client_status_period“: OPTIONAL. Celé číslo udávající preferovanou zbývající dobu udržování stavu potvrzení instance peněženky, kterou má jednotka peněženky předložit během vydávání, v sekundách. Zbývající doba udržování stavu je definována jako hodnota „client_status.exp“ v potvrzení minus čas přijetí potvrzení.
— 
„preferred_key_storage_status_period“: OPTIONAL. Celé číslo udávající preferovanou zbývající dobu udržování stavu potvrzení klíče, kterou má jednotka peněženky předložit během vydávání, v sekundách. Zbývající doba udržování stavu je definována jako hodnota „key_storage_status.exp“ v potvrzení minus čas přijetí potvrzení.
— 
LC_WIA-1: Autorizační server může sdělit své preference pro zbývající dobu udržování stavu v potvrzeních instance peněženky tím, že uvede parametr metadat „preferred_client_status_period“ v koncovém bodu metadat vydavatele pověření, jak je uvedeno v oddíle 12.2.2 dokumentu OID4VCI.
— 
LC_WIA-1.1: Toto pole se umístí na nejvyšší úroveň metadat vydavatele pověření.
— 
LC_WIA_2: Autorizační server neinterpretuje parametr „exp“ v nejvyšší úrovni potvrzení instance peněženky jako konec doby udržování zneplatnění instance peněženky.
— 
LC_WIA_3: Pokud poskytovatel peněženky podepíše nebo opatří pečetí potvrzení instance peněženky, udržuje stav zneplatnění příslušné instance peněženky až do doby, než uplyne lhůta „wallet_instance_status.exp“ uvedená v tomto potvrzení instance peněženky.
— 
LC_KA-1: Pokud je třeba potvrzení klíče, může vydavatel pověření sdělit své preference pro zbývající dobu udržování stavu v potvrzeních klíče tím, že do koncového bodu metadat vydavatele pověření zahrne parametr metadat „preferred_key_storage_status_period“ uvedený výše, jak je uvedeno v oddíle 12.2.2 dokumentu OID4VCI.
— 
LC_KA-1.1: Toto pole se umístí do objektu „key_attestations_required“, jak je uvedeno v oddíle 12.2.4 dokumentu OID4VCI.
— 
LC_KA-2: Poskytovatel peněženky si zvolí dobu technické platnosti potvrzení klíče, která vydává.
— 
LC_KA-3: Pokud poskytovatel peněženky podepíše nebo opatří pečetí potvrzení klíče, udržuje stav zneplatnění příslušného WSCD nebo úložiště klíčů až do doby, než uplyne lhůta „key_storage_status.exp“ uvedená v tomto potvrzení klíče.
— 
LC_GEN-1: Poskytovatel peněženky zajistí, aby jednotka peněženky mohla vždy předložit potvrzení jednotky peněženky a potvrzení klíče, jejichž lhůty „client_status.exp“ a „key_storage_status.exp“ (v tomto pořadí) jsou v době předložení autorizačnímu serveru nebo vydavateli pověření platné minimálně ještě 31 dní.
— 
POZNÁMKA: To zaručuje, že se poskytovatelé osobních identifikačních údajů mohou spolehnout na řetězení zneplatnění, aniž by byli nuceni vydávat krátkodobé osobní identifikační údaje.
— 
LC_GEN-2: Poskytovatel peněženky zajistí, aby jednotka peněženky při vydávání získala metadata vydavatele pověření.
— 
LC_GEN_2.1: Pokud je v těchto metadatech zahrnuto pole „preferred_key_storage_status_period“, pak jednotka peněženky odešle potvrzení klíče s hodnotou („key_storage_status.exp“ – aktuální čas) – „preferred_key_storage_status_period“, která je co nejmenší, ale ne záporná. Pokud jednotka peněženky nemá k dispozici žádné takové potvrzení klíče, získá od poskytovatele peněženky nové potvrzení klíče, které splňuje požadavek „key_storage_status.exp“ – aktuální čas ≥ „preferred_key_storage_status_period“.
— 
LC_GEN_2.2: Pokud je v těchto metadatech zahrnuto pole „preferred_client_status_period“, pak jednotka peněženky odešle potvrzení instance peněženky s hodnotou („client_status.exp“ – aktuální čas) – „preferred_client_status_period“, která je co nejmenší, ale ne záporná. Pokud jednotka peněženky nemá k dispozici žádné takové potvrzení instance peněženky, vyžádá si od poskytovatele peněženky nové potvrzení instance peněženky, které splňuje požadavek „client_status.exp“ – aktuální čas ≥ „preferred_client_status_period“.
— 
LC_GEN-3: Doba technické platnosti osobních identifikačních údajů končí předtím, než uplyne lhůta „client_status.exp“ potvrzení instance peněženky a lhůta „key_storage_status.exp“ potvrzení klíče zaslaného poskytovateli osobních identifikačních údajů v procesu vydávání.
— 
LC_GEN-4: Poskytovatel osobních identifikačních údajů s dobou technické platnosti delší než 24 hodin kontroluje stav zneplatnění potvrzení instance peněženky i potvrzení klíče obdrženého při vydávání nejméně jednou za 24 hodin během doby technické platnosti osobních identifikačních údajů. Pokud je některé z nich zneplatněno, poskytovatel zneplatní osobní identifikační údaje.
e) 

Požadavky na zneplatnění

— 
R_GEN-1: Poskytovatel peněženky používá seznamy stavů tokenů (specifikované v IETF Token Status List) jako mechanismus zneplatnění pro potvrzení klíče i potvrzení instance peněženky, jak je uvedeno v dodatcích D a E k OID4VCI.
— 
POZNÁMKA: Pro zlepšení škálovatelnosti seznamů stavů může poskytovatel peněženky použít následující optimalizace:
— 
Rozdělit seznam stavů na více částí, pokud mají poskytovatelé peněženek velký počet uživatelů a vydaných potvrzení. Existuje mnoho strategií rozdělení na části, například na základě pevně stanovené velikosti nebo podle časového období. Strategie rozdělení na části je ponechána na uvážení poskytovatele peněženky. V úvahu lze vzít mimo jiné velikost seznamu stavů pro stahování a soukromí uživatele.
— 
Mít více seznamů stavů.
— 
Zkomprimovat seznam stavů za účelem zmenšení jeho velikosti.
— 
R_WIA-1: Poskytovatel peněženky může přiřadit stejnou hodnotu k tvrzení „idx“ v tvrzení „client_status.status“ ve všech potvrzeních instance peněženky, která daná jednotka peněženky předkládá stejnému autorizačnímu serveru. Tomu se říká možnost „per-issuer reuse“. Pokud je tato možnost použita:
— 
R_WIA-1.1: Jednotka peněženky udržuje stav, pokud jde o hodnotu indexu, kterou použila pro každý autorizační server, se kterým dříve komunikovala, a při opětovné interakci se stejným autorizačním serverem si vyžádá potvrzení instance peněženky obsahující stejnou hodnotu indexu.
— 
R_WIA-1.2: Pokud poskytovatel peněženky obdrží žádost o potvrzení instance peněženky obsahující určitou hodnotu indexu, ověří před vydáním nového potvrzení instance peněženky s touto hodnotou indexu, že žádající jednotka peněženky tuto hodnotu indexu již dříve obdržela.
— 
R_WIA-1.3: Jednotka peněženky nesmí opakovaně používat stejnou hodnotu indexu pro interakce s různými autorizačními servery.
— 
POZNÁMKA: Pokud bude použita možnost „per-issuer reuse“, bude poskytovatel peněženky schopen určit, s kolika autorizačními servery jednotka peněženky komunikovala a jak často s každým z nich komunikuje.
— 
R_WIA-2: Poskytovatel peněženky ve svých zásadách ochrany osobních údajů zdokumentuje, zda používá možnost „per-issuer reuse“ pro zneplatnění instance peněženky.
— 
R_WIA-3: Pokud poskytovatel peněženky nepoužívá možnost „per-issuer reuse“, přiřadí každému vydávanému potvrzení instance peněženky novou, nepropojitelnou hodnotu indexu.
— 
R_WIA-4: Pokud je nutné jednotku peněženky zneplatnit, poskytovatel peněženky zneplatní hodnoty indexů v tvrzení „client_status.status“ ve všech potvrzeních instance peněženky souvisejících s touto jednotkou peněženky.
— 
R_WIA-5: Poskytovatel peněženky zohlední při určování velikosti seznamů stavů potvrzení instance peněženky míru nasazení a základní architekturu a zajistí, aby seznamy byly dostatečně velké, aby se zabránilo korelaci a chránilo soukromí uživatelů. Pokud je to možné, musí se seznam stavů vztahovat alespoň k 10 000 potvrzení.
— 
R_KA_1: Poskytovatel peněženky si zvolí jednu z následujících možností přiřazení indexu pro tvrzení „key_storage_status.status“ v potvrzení klíče:
— 
Možnost 1, tzv. „type-shared index“, při níž všechna potvrzení klíčů potvrzující klíče uložené ve stejném typu WSCD nebo úložiště klíčů obsahují stejnou hodnotu indexu v „key_storage_status.status“.
— 
Možnost 2, tzv. „per-key-attestion index“, při níž potvrzení klíče potvrzující klíče uložené v individuálním WSCD nebo úložišti klíčů obsahuje (párově) jedinečnou hodnotu indexu v „key_storage_status.status“.
— 
POZNÁMKA: Pokud poskytovatel peněženky použije možnost 1, jediná akce zneplatnění zneplatní všechna potvrzení klíčů dotčeného typu ve všech jednotkách peněženky. Kromě toho, jelikož všechna potvrzení klíčů pro stejný typ WSCD nebo úložiště klíčů sdílejí jeden index seznamu stavů, počet položek v seznamu stavů potvrzení klíčů odráží počet typů WSCD nebo úložišť klíčů podporovaných poskytovatelem peněženky, nikoli počet nasazených jednotek peněženky. Úvahy o ochraně soukromí, které odůvodňují minimální velikost seznamu stavů pro seznamy stavů instance peněženky, se proto nevztahují na seznamy stavů potvrzení klíče v rámci možnosti 1, pokud existuje dostatečný počet jednotek peněženky používajících stejný typ WSCD nebo úložiště klíčů.
— 
POZNÁMKA: Pokud poskytovatel peněženky použije možnost 2, představuje každý index stav zneplatnění konkrétního WSCD nebo úložiště klíčů potvrzeného v tomto potvrzení klíče.
— 
POZNÁMKA: Pokud poskytovatel peněženky použije možnost 2, lze na žádost uživatele rovněž zneplatnit konkrétní WSCD nebo úložiště klíčů.
— 
R_KA-2: Pokud poskytovatel peněženky použije možnost 2, může volitelně použít i možnost „per-issuer reuse“ popsanou v R_WIA-1. Pokud poskytovatel peněženky použije tuto možnost, použijí se obdobně požadavky R_WIA-1 – R_WIA-3.
— 
R_KA-3: Pokud poskytovatel peněženky použije možnost 2, zohlední při určování velikosti seznamů stavů potvrzení klíčů míru nasazení a základní architekturu a zajistí, aby seznamy byly dostatečně velké, aby se zabránilo korelaci a chránilo soukromí uživatelů. Pokud je to možné, musí se seznam stavů vztahovat alespoň k 10 000 potvrzení klíče.
— 
R_KA-4: Pokud poskytovatel peněženky použije možnost 1 (type-shared index), zneplatní položku „key_storage_status.status“ pouze v případě, že typ WSCD nebo úložiště klíčů vykazuje bezpečnostní zranitelnost.
f) 

Požadavky na podpisové algoritmy

— 
SA-1: Pro podepisování potvrzení instance peněženky, potvrzení klíče, souvisejících důkazů o vlastnictví a seznamů stavů tokenů se použije jeden z následujících algoritmů:
— 
ES256 (ECDSA s SHA-256 a P-256)
— 
ES384 (ECDSA s SHA-384 a P-384)
— 
ES512 (ECDSA s SHA-512 a P-521)
— 
SA-2: Poskytovatel peněženky si zvolí, který z algoritmů uvedených v SA-1 použije.
— 
SA-3: Autorizační server nebo vydavatel pověření (jak je uvedeno v OID4VCI) podporuje všechny algoritmy uvedené v SA-1.

▼M1




PŘÍLOHA II

SEZNAM NOREM PODLE ČLÁNKU 8

Platí technické specifikace uvedené v bodech 2 až 6 ETSI TS 119 472 -1 V1.2.1 (2026-02). Použijí se s těmito úpravami:

1) 
2.1 

Normative references

— 
[16] ETSI EN 319 412 -1 V1.6.1 (2025-06): „Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures“.
— 
[17] ETSI TS 119 412 -6 V1.1.1 (2025-09): „Electronic Signatures and Trust Infrastructures (ESI); Certificate Profiles; Part 6: Certificate profile requirements for PID, Wallet, EAA, QEAA, and PSBEAA providers“.
— 
[25] IETF Token Status List (TSL), draft-ietf-oauth-status-list-20: „Token Status List“, 20. dubna 2026.
2) 
4.2.11.1 

General requirements

— 
EAA-4.2.11.1-06: Pokud se prvek stavu používá pro osobní identifikační údaje, kvalifikovaná elektronická potvrzení atributů nebo elektronická potvrzení atributů poskytovaná subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem, uvádí pouze, zda je potvrzení zneplatněno, nebo zneplatněno není, a nepodporuje žádné jiné hodnoty stavu, např. pozastavení.
— 
EAA-4.2.11.1-06.1: Pokud je potvrzení zneplatněno, je zneplatněno trvale.
3) 
4.2.13 

EAA short-lived

— 
EAA-4.2.13-03: Pokud jsou vydávána krátkodobá elektronická potvrzení atributů s dobou platnosti 24 hodin nebo kratší, zneplatnění se nevyžaduje.
4) 
4.6.3 

Requirements for EU EAA issued by or on behalf of a public body responsible for an authentic source (PuB-EAA)

— 
PuB-EAA-4.6.2-03: neplatné.
— 
Pub-EAA-4.6.2-04: neplatné.
— 
PuB-EAA-4.6.3-03: Digitální podpis PuB-EAA by měl obsahovat kvalifikovaný certifikát podporující digitální podpis PuB-EAA.
— 
PuB-EAA-4.6.3-04: Kvalifikovaný certifikát podporující digitální podpis PuB-EAA musí splňovat požadavky bodu 8 normy ETSI TS 119 412 -6 v1.1.1 a musí obsahovat QcType qcStatement podle definice v normě ETSI EN 319 412 -5 v2.5.1 s hodnotou id-etsi-qct-eidaspsbeaa definovanou takto:
id-etsi-qct-eidaspsbeaa OBJECT IDENTIFIER ::= { id-etsi-eidas2-qct-extensions 3 } -- Certifikát uvedený v čl. 45f odst. 1 písm. b) podporující kvalifikovaný elektronický podpis nebo kvalifikovanou elektronickou pečeť subjektu veřejného sektoru uvedeného v čl. 3 bodu 46 nařízení (EU) č. 910/2014.
5) 
5.2.10.1 

General requirements

— 
EAA-5.2.10.1-04: neplatné.
— 
EAA-5.2.10.1-05: neplatné.
— 
EAA-5.2.10.1-06: Člen stav může obsahovat člen status_list, jak je uvedeno v odstavci 6.2 dokumentu IETF draft-ietf-oauth-status-list-20 [25].
— 
EAA-5.2.10.1-07: neplatné.
— 
EAA-5.2.10.1-08: neplatné.
— 
EAA-5.2.10.1-09: neplatné.
— 
EAA-5.2.10.1-10: neplatné.
— 
EAA-5.2.10.1-11: neplatné.
— 
EAA-5.2.10.1-12: neplatné.
6) 
6.2.10.1 

General requirements

— 
EAA-6.2.10.1-01: Pokud elektronické potvrzení atributů vyhovující normě ISO/IEC mdoc používá mechanismus seznamu stavů potvrzení podle EAA-6.2.10.1-02.2 nebo mechanismus seznamu zneplatnění potvrzení podle EAA-6.2.10.1-02.3, obsahuje jeho mobilní bezpečnostní objekt (MSO) strukturu stavu podle EAA-6.2.10.1-17, která obsahuje informace o zneplatnění MSO.
— 
EAA-6.2.10.1-01.1: Při implementaci mechanismu seznamu identifikátorů obsahuje prvek stavu prvek identifier_list, jak je stanoveno v EAA-6.2.10.1-11.
— 
EAA-6.2.10.1-01.2: Při implementaci mechanismu seznamu stavů obsahuje prvek stavu prvek status_list, jak je stanoveno v EAA-6.2.10.1-13.
— 
POZNÁMKA:
— 
Struktura stavu obsahuje odkaz na seznam zneplatnění MSO.
— 
Seznam zneplatnění MSO je struktura COSE_Sign1, která označuje, zda je konkrétní MSO zneplatněn, či nikoli.
— 
Struktura stavu obsahuje všechny informace potřebné k tomu, aby strana spoléhající se na peněženku mohla určit, zda je seznam zneplatnění MSO pravý.
— 
EAA-6.2.10.1-02: Poskytovatel osobních identifikačních údajů, poskytovatel kvalifikovaných elektronických potvrzení atributů nebo poskytovatel elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem použije pro zneplatnění osobních identifikačních údajů, kvalifikovaných elektronických potvrzení atributů nebo elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem jednu z těchto metod:
— 
EAA-6.2.10.1-02.1: Pokud vydávají krátkodobá elektronická potvrzení atributů s dobou platnosti 24 hodin nebo kratší, není zneplatnění nutné.
— 
EAA-6.2.10.1-02.2: K zakódování informací o zneplatnění jako seznamu stavů se použije mechanismus seznamu stavů potvrzení.
— 
EAA-6.2.10.1-02.2.1: Mechanismus seznamu stavů zneplatňuje MSO na základě toho, zda je bit na pozici definované vydavatelem v MSO v seznamu stavů nastaven na hodnotu true.
— 
EAA-6.2.10.1-02.2.2: Mechanismus seznamu stavů je specifikován ve specifikaci seznamu stavů tokenů (draft-ietf-oauth-status-list-20).
— 
EAA-6.2.10.1-02.3: K zakódování informací o zneplatnění jako seznamu identifikátorů se použije mechanismus seznamu zneplatnění potvrzení.
— 
EAA-6.2.10.1-02.3.1: Mechanismus seznamu identifikátorů zneplatňuje MSO na základě toho, zda se identifikátor definovaný vydavatelem v MSO nachází v seznamu identifikátorů.
— 
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 a EAA-6.2.10.1-11 specifikují mechanismus seznamu identifikátorů na základě požadavků ze specifikace seznamu stavů tokenů, včetně společné charakteristiky mezi mechanismem seznamu stavů a seznamu identifikátorů.
— 
EAA-6.2.10.1-03: Pokud se prvek stavu používá pro osobní identifikační údaje, kvalifikovaná elektronická potvrzení atributů nebo elektronická potvrzení atributů poskytovaná subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem, použije se výhradně stav „revoked“ („zneplatněno“).
— 
EAA-6.2.10.1-03.1: Pro seznam stavů to znamená, že se použijí pouze hodnoty „valid“ a „invalid“, jak je uvedeno ve specifikaci seznamu stavů tokenů.
— 
EAA-6.2.10.1-03.2: Do seznamu identifikátorů se zařadí pouze zneplatněné MSO, a nikoli dočasně pozastavené MSO.
— 
EAA-6.2.10.1-04: Pokud je MSO zneplatněn, je zneplatněn trvale.
— 
EAA-6.2.10.1-05: Ověření seznamu zneplatnění MSO je pro stranu spoléhající se na peněženku nepovinné, přičemž v příslušných případech ověření splňuje požadavky na ověření uvedené ve specifikaci seznamu stavů tokenů a specifikaci struktury stavů podle EAA-6.2.10.1-01.
— 
EAA-6.2.10.1-05.1: Pokud musí být strana spoléhající se na peněženku schopna ověřit stav zneplatnění osobních identifikačních údajů nebo elektronických potvrzení atributů, podporuje mechanismus seznamu stavů potvrzení i mechanismus seznamu zneplatnění potvrzení podle EAA-6.2.10.1-02.
— 
EAA-6.2.10.1-06: Prvky identifier_list a status_list v MSO mohou obsahovat prvek certifikátu.
— 
EAA-6.2.10.1-06.1: Pokud je prvek certifikátu přítomen, obsahuje certifikát obsahující veřejný klíč, který podepsal nebo opatřil pečetí certifikát nejvyšší úrovně v prvku x5chain ve struktuře seznamu zneplatnění MSO.
— 
EAA-6.2.10.1-06.1.1: Instance strany spoléhající se na peněženku použije tento certifikát jako zdroj důvěry (trust anchor) pro ověření prvku x5chain ve struktuře seznamu zneplatnění MSO.
— 
EAA-6.2.10.1-06.2: Pokud prvek certifikátu přítomen není, je certifikát nejvyšší úrovně v prvku x5chain ve struktuře seznamu zneplatnění MSO podepsán nebo opatřen pečetí certifikátem použitým k podepsání certifikátu v prvku x5chain v MSO.
— 
EAA-6.2.10.1-06.2.1: Instance strany spoléhající se na peněženku použije tento certifikát jako zdroj důvěry (trust anchor) pro ověření prvku x5chain ve struktuře seznamu zneplatnění MSO.
— 
EAA-6.2.10.1-07: Seznam zneplatnění MSO musí být implementován v souladu se specifikací seznamu stavů tokenů jako token seznamu stavů ve formátu CWT.
— 
EAA-6.2.10.1-08: Pro seznam zneplatnění MSO pro mechanismus seznamu identifikátorů a seznamu stavů platí následující požadavky:
— 
je uvedeno tvrzení exp,
— 
může být uvedeno tvrzení ttl,
— 
může být uvedeno tvrzení aggregation_uri v rámci tvrzení IdentifierList nebo StatusList a poskytovatel osobních identifikačních údajů, poskytovatel kvalifikovaných elektronických potvrzení atributů nebo poskytovatel elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru odpovědným za autentický zdroj nebo jeho jménem může použít tvrzení aggregation_uri k označení podpory agregačního mechanismu, jak je uvedeno ve specifikaci seznamu stavů tokenů,
— 
CWT je objekt COSE_Sign1, který používá jeden z následujících podpisových algoritmů pro výpočet podpisu:
a) 

„ES256“ (ECDSA s křivkou NIST P-256 a SHA-256);

b) 

„ES384“ (ECDSA s křivkou NIST P-384 a SHA-384);

c) 

„ES512“ (ECDSA s křivkou NIST P-521 a SHA-512);

d) 

„ESB256“ (ECDSA s křivkou brainpoolP256r1 a SHA-256);

e) 

„ESB384“ (ECDSA s křivkou brainpoolP384r1 a SHA-384);

f) 

„ESB512“ (ECDSA s křivkou brainpoolP512r1 a SHA-512),

— 
CWT obsahuje x5chain v chráněné hlavičce, která obsahuje certifikát nebo řetězec certifikátů pro ověření podpisu seznamu zneplatnění MSO,
— 
rozšířené použití klíče identifikátoru objektu uvedené ve specifikaci seznamu stavů tokenů lze použít pro seznam stavů a podpisový certifikát seznamu identifikátorů a instance strany spoléhající se na peněženku mohou podporovat rozšířené použití klíče identifikátorů objektu uvedené ve specifikaci seznamu stavů tokenů a pro identifikátor objektu; poskytovatel kvalifikovaných elektronických potvrzení atributů nebo poskytovatel elektronických potvrzení atributů poskytovaných subjektem veřejného sektoru nebo jeho jménem neučiní při použití rozšířeného použití klíče OID uvedeného ve specifikaci seznamu stavů tokenů pole rozšířeného použití klíče kritickým.
— 
EAA-6.2.10.1-09: Odchylně od požadavků specifikace seznamu stavů tokenů platí pro mechanismus seznamu identifikátorů následující požadavky:
— 
hodnota tvrzení o typu je „application/identifierlist+cwt“,
— 
tvrzení StatusList nesmí být uvedeno v souboru tvrzení CWT,
— 
struktura IdentifierList definovaná v EAA-6.2.10.1-11 je uvedena jako tvrzení v tvrzeních CWT pomocí klíče 65530.
— 
EAA-6.2.10.1-10: Struktura IdentifierList je strukturou CBOR s následujícím 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: Pokud je identifikátor přítomen v IdentifierList, je MSO, který obsahuje identifikátor v prvku stavu, zneplatněn.
— 
EAA-6.2.10.1-10.2: Tvrzení Aggregation_uri je specifikováno v oddíle 9.2 specifikace seznamu stavů tokenů.
— 
EAA-6.2.10.1-10.3: Typ obsahu seznamu identifikátorů je „application/identifierlist+cwt“ podle požadavků uvedených v oddíle 8.2 specifikace seznamu stavů tokenů.
— 
EAA-6.2.10.1-11: Na prvek identifier_list v MSO se vztahují následující požadavky (viz EAA-6.2.10.1-17).
— 
EAA-6.2.10.1-11.1: Prvek identifier_list je strukturou CBOR s následujícím 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 se zabránilo použití identifikátoru jako korelace napříč prezentacemi, musí být jedinečný pro každý MSO.
— 
EAA-6.2.10.1-12: Na seznam stavů se vztahují následující požadavky:
— 
EAA-6.2.10.1-12.1: Prvek bits ve struktuře StatusList se nastaví na 1.
— 
EAA-6.2.10.1-13: Na prvek status_list v MSO se vztahují následující požadavky (viz EAA-6.2.10.1-17):
— 
EAA-6.2.10.1-13.1: Prvek status_list se řídí požadavky na strukturu StatusListInfo uvedenými ve specifikaci seznamu stavů tokenů a je doplněn nepovinný prvek certifikátu definovaný v EAA-6.2.10.1-06.
— 
EAA-6.2.10.1-13.2: Aby se zabránilo tomu, že index stavu bude korelovat napříč prezentacemi, musí být kombinace indexu stavu a URI jedinečná pro každý MSO.
— 
EAA-6.2.10.1-14: Poskytovatel peněženky použije pro zneplatnění potvrzení instance peněženky a pro zneplatnění potvrzení klíče druhou (EAA-6.2.10.1-02.2) nebo třetí (EAA-6.2.10.1-02.3) z metod uvedených v EAA-6.2.10.1-02.
— 
EAA-6.2.10.1-15: Poskytovatel peněženky implementuje v řešení peněženky mechanismy zneplatnění potvrzení uvedené v EAA-6.2.10.1-02.
— 
EAA-6.2.10.1-16: Poskytovatel osobních identifikačních údajů a poskytovatel elektronických potvrzení atributů podporuje mechanismus seznamu stavů potvrzení i mechanismus seznamu zneplatnění potvrzení uvedený v EAA-6.2.10.1-02 pro ověření stavu zneplatnění potvrzení instance peněženky a potvrzení klíče.
— 
EAA-6.2.10.1-17: Struktura stavů v MSO je strukturou CBOR s následujícím CDDL:
Status = {
? „identifier_list“: IdentifierListInfo,
? „status_list“: StatusListInfo,
* tstr => RFU
}




PŘÍLOHA III

TECHNICKÉ SPECIFIKACE PODLE ČLÁNKU 10

— 
Technické specifikace:
— 
bod 4.2.5 normy ETSI TS 119 472 -3 V1.1.1 (2026-03).

▼B




PŘÍLOHA IV

SEZNAM FORMÁTŮ PODPISU A PEČETI UVEDENÝCH V ČLÁNKU 12

▼M1

1. 

Povinný formát podpisu nebo pečeti:

a) 

PAdES (zaručený elektronický podpis PDF), jak je specifikováno v normě ETSI EN 319 142 -1 V1.2.1 (2024-01); Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures.

▼B

2. 

Seznam volitelných formátů podpisu nebo pečeti:

a) 

XAdES, jak je specifikováno v normě „ETSI EN 319 132-1 V1.2.1 (2022-02) Elektronické podpisy a infrastruktury (ESI); Digitální podpisy XAdES; Část 1: Stavební bloky a základní podpisy XAdES (XAdES)“ pro podepisování formátu XML;

b) 

JAdES, jak je specifikováno v normě „ETSI TS 119 182-1 V1.2.1 (2024-07) Elektronické podpisy a infrastruktury (ESI); Digitální podpisy JAdES; Část 1: Stavební bloky a základní podpisy JAdES“ pro podepisování formátu JSON;

c) 

CAdES (zaručený elektronický podpis CMS), jak je specifikováno v normě „ETSI EN 319 122-1 V1.3.1 (2023-06) Elektronické podpisy a infrastruktury (ESI); Digitální podpisy CAdES; Část 1: Stavební bloky a základní podpisy CAdES“ pro podepisování formátu CMS;

d) 

ASiC (přidružený zásobník podpisu), jak je specifikováno v normě „ETSI EN 319 162-1 V1.1.1 (2016-04) Elektronické podpisy a infrastruktury (ESI); Přidružené zásobníky podpisu (ASiC); Část 1: Stavební bloky a základní zásobníky ASiC a norma ETSI EN 319 162-2 V1.1.1 (2016-04) Elektronické podpisy a infrastruktury (ESI); Přidružené zásobníky podpisu (ASiC); Část 2: Dodatečné zásobníky ASiC pro podepisování zásobníků.

▼M1

3. 

Aplikační programovací rozhraní:

body 6.4.3, A.6, A.7 a A.8 normy ETSI TS 119 432 v1.3.1 (2026-03).

▼M1 —————

▼M1




PŘÍLOHA VI

BAREVNÁ ZNAČKA DŮVĚRY EU PRO PENĚŽENKU DIGITÁLNÍ IDENTITY

image




PŘÍLOHA VII

ČERNOBÍLÁ ZNAČKA DŮVĚRY EU PRO PENĚŽENKU DIGITÁLNÍ IDENTITY

image




PŘÍLOHA VIII

ÚDAJE TÝKAJÍCÍ SE ZNAČKY DŮVĚRY EU PRO PENĚŽENKU DIGITÁLNÍ IDENTITY



Údaje

Popis

Kódování

Stav

TrustMarkResourceURL

URL grafických zdrojů a zdrojů uživatelských informací značky důvěry EU pro peněženku digitální identity v uživatelském rozhraní peněženky.

URL

Povinné

ListOfCertifiedWalletsURL

URL veřejného seznamu certifikovaných řešení peněženky v EU, jak je stanoveno v prováděcím nařízení Komise (EU) 2025/849 (1).

URL

Povinné

ListOfCertifiedWalletsQRCode

QR kód obsahující informace o ListOfCertifiedWalletsURL.

ISO-8859-1 Byte mode QR code

Nepovinné

WalletSolutionInfoPageURL

URL na informační stránku certifikovaného řešení peněženky v seznamu stránky certifikovaných řešení peněženky z ListOfCertifiedWalletsURL URL doplněné o „?“ a identifikátor řešení peněženky WalletSolutionID.

URL

Povinné

WalletSolutionInfoPageQRCode

QR kód obsahující informace o WalletSolutionInfoPageURL

ISO-8859-1 Byte mode QR code

Nepovinné

WalletVerifierToolURL*

URL směřující na koncový bod nástroje pro ověření peněženky /.well-known/openid-credential-issuer používaný pro vyhledání metadat poskytovatele potvrzení.

URL

Nepovinné

(1)   

Prováděcí nařízení Komise (EU) 2025/849 ze dne 6. května 2025, kterým se stanoví prováděcí pravidla k nařízení Evropského parlamentu a Rady (EU) č. 910/2014, pokud jde o předkládání informací pro seznam certifikovaných evropských peněženek digitální identity Komisi a skupině pro spolupráci (Úř. věst. L, 2025/849, 7.5.2025, ELI: http://data.europa.eu/eli/reg_impl/2025/849/oj).



( 1 ) Prováděcí nařízení Komise (EU) 2015/1502 ze dne 8. září 2015, kterým se stanoví minimální technické specifikace a postupy pro úrovně záruky prostředků pro elektronickou identifikaci podle čl. 8 odst. 3 nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu (Úř. věst. L 235, 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_en.

( 3 ) RFC 7519: JSON Web Token (JWT), květen 2015.

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

( 5 ) ETSI, „ Electronic Signatures and Infrastructures (ESI); JAdES digital signatures; Part 3: JAdES levels and baseline profiles “ (Elektronické podpisy a infrastruktury (ESI); Digitální podpisy JAdES; Část 3: Úrovně a základní profily JAdES), ETSI TS 119 472-3, V1.1.1, březen 2026.

( 6 ) Toto tvrzení je definováno v tomto prováděcím nařízen Komise, protože není součástí specifikace OID4VCI.

© Evropská unie, https://eur-lex.europa.eu/ , 1998-2022
Zavřít
MENU