Ověření aktuálnosti výpisů/výstupů ISVS

Stav: koncept v přípravě, pilotně ho implementuje Ministerstvo spravedlnosti. Technický profil a adresy uvedené na této stránce jsou pracovním návrhem Digitální a informační agentury (DIA) a mohou se změnit. Závazně je stanoví technický profil a revize otevřené formální normy pro strojově čitelnou vrstvu dokumentů.

Výpis nebo výstup z informačního systému veřejné správy (ISVS), typicky výpis z evidence Rejstříku trestů, vypovídá o stavu údajů jen k jedinému okamžiku – k okamžiku platnosti údajů. Pozdější změna údajů se do již vydaného výpisu nepromítne a příjemce nemá jak zjistit, zda údaje ve výpisu stále odpovídají evidenci. Praxe tento problém obchází požadavky typu „výpis ne starší než …“, které ho ale neřeší a vedou k opakovanému vyžadování nových výpisů.

DIA proto navrhuje doplnit k vydaným výpisům ověřitelnou informaci o jejich aktuálnosti pomocí tzv. status listů. Vydavatel výpisu vede veřejně publikovaný a elektronicky zapečetěný seznam, ve kterém má každý vydaný výpis svou pozici s jediným příznakem. Výpis ve své strojově čitelné vrstvě nese odkaz na status list a číslo své pozice. Příjemce si seznam stáhne a aktuálnost ověří sám – bez kontaktování vydavatele a bez toho, aby se vydavatel dozvěděl, který výpis je ověřován.

Mechanismus je technicky totožný se status listy, které DIA buduje pro atestace vydávané do evropské digitální peněženky (EUDI Wallet) v Informačním systému k podpoře peněženky (IS PP). Liší se pouze význam sledovaného příznaku: u výpisů jde o aktuálnost údajů, u atestací o jejich zneplatnění (revokaci). Obě řešení tak od počátku vznikají jako jeden slučitelný systém.

Pilotně mechanismus zavádí Ministerstvo spravedlnosti pro výpisy z evidence Rejstříku trestů.

Přínosy:

• vyšší právní jistota příjemce veřejné listiny – aktuálnost ověří kdykoli, i opakovaně, bez kontaktování vydavatele,
• méně opakovaného vyžadování a předkládání výpisů „pro jistotu“ (zásada „pouze jednou“),
• jednotný mechanismus pro výpisy i pro atestace v EUDI Wallet bez duplicitní infrastruktury,
• ochrana soukromí – vydavatel se z ověřování nedozví, komu držitel výpis předložil.

Výsledek „aktuální“ je formulován záměrně opatrně. Neznamená potvrzení správnosti všech údajů, ale pouze to, že vydavatel výpis k okamžiku vydání status listu neoznačil jako neaktuální. Mezi změnou v evidenci a jejím promítnutím do status listu může uplynout až jeden obnovovací cyklus (24 hodin) a ověřovatel může používat kopii listu z mezipaměti.

• Zákon č. 365/2000 Sb. v § 9 rozlišuje výpis z ISVS (odst. 1), výstup z ISVS, tedy výpis nebo potvrzení v elektronické podobě zabezpečené způsobem zajišťujícím integritu, případně původ dat (odst. 2), a ověřený výstup, tedy listinu, která vznikla převodem výstupu z ISVS do listinné podoby na kontaktním místě veřejné správy (odst. 3). Všechny jsou veřejnými listinami (odst. 5).
• Podle § 9c téhož zákona odpovídá správce ISVS za soulad výstupu se stavem zápisu k okamžiku platnosti údajů. Status list tento údaj nenahrazuje, ale doplňuje o informaci, zda se stav zápisu od tohoto okamžiku změnil.
• Zákon č. 499/2004 Sb. v § 69a odst. 5 až 7 ukládá veřejnoprávním původcům opatřit vyhotovovaný dokument v digitální podobě strojově čitelnou vrstvou podle schématu, které zveřejňuje DIA. Strojově čitelná vrstva je nosičem odkazu na status list; odkaz se do ní zapisuje podle rozšíření otevřené formální normy Společné části elektronických dokumentů.
• Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby.
• Nařízení (EU) č. 910/2014 (eIDAS) ve znění nařízení (EU) 2024/1183 a Architektonický a referenční rámec EUDI Wallet (ARF) – pro atestace v peněžence.

Žádný předpis dnes vydavatelům neukládá povinnost informovat o trvání aktuálnosti vydaných výpisů. Zapojení je proto zatím dobrovolné (pilotní provoz). Plošná povinnost vyžaduje změnu právních předpisů – viz Postup zavádění.

Označit výpis jako neaktuální smí pouze jeho vydavatel. Generování a publikaci status listů lze svěřit jinému subjektu, odpovědnost za obsah status listu však zůstává vydavateli.

1. Vydání. Vydavatel přidělí výpisu náhodně zvolenou volnou pozici (index, idx) v aktuálním status listu a do strojově čitelné vrstvy výpisu zapíše adresu status listu (uri), index a datum konce doby ověřitelnosti. Tyto údaje musí být v rozsahu elektronické pečeti výpisu, jinak by bylo možné odkaz podvrhnout a přesměrovat ověření na jinou pozici.
2. Evidence. Vydavatel eviduje vazbu mezi vydaným výpisem a dvojicí uri + idx po celou dobu ověřitelnosti výpisu, aby při změně údajů dokázal určit dotčené výpisy.
3. Změna údajů. Při agendové události, která mění údaje obsažené ve výpisu (zápis, oprava, zrušení nebo nahrazení záznamu), vydavatel označí dotčené výpisy jako neaktuální. Označení je nevratné.
4. Obnova listu. Status list se obnovuje automaticky nejméně jednou za 24 hodin a publikuje se vždy na téže adrese. V mimořádných situacích (např. při bezpečnostním incidentu) lze list vydat i mimo pravidelný cyklus.
5. Ověření. Příjemce ověří pečeť výpisu, stáhne status list (nebo použije dostatečně čerstvou kopii z mezipaměti) a přečte hodnotu na pozici výpisu.
6. Konec ověřitelnosti. Každý výpis má dobu ověřitelnosti, jejíž konec je uveden přímo ve strojově čitelné vrstvě výpisu. Délka se odvozuje od skartační lhůty příslušného druhu výpisu. Po jejím uplynutí se aktuálnost výpisu již neověřuje; příznak ve status listu se kvůli uplynutí lhůty nemění, takže výsledek NEAKTUÁLNÍ vždy znamená skutečnou změnu údajů. Status list se přestane vydávat, jakmile skončí doba ověřitelnosti všech výpisů, které na něj odkazují.

Ověření má vždy jeden ze tří výsledků:

Výsledek NELZE OVĚŘIT nesmí být nikdy vykládán jako AKTUÁLNÍ.

• Strojové ověření – informační systém příjemce načte ze strojově čitelné vrstvy uri a idx a ověří status list podle algoritmu uvedeného níže. Příjemci, kteří pracují s velkým množstvím výpisů (např. organizace s tisíci členy), si mohou odkazy uložit do vlastní evidence, status listy pravidelně stahovat přes agregační index a ověřovat aktuálnost všech výpisů opakovaně bez lidského zásahu. Strojové ověření je hlavním a autoritativním způsobem ověření.
• Ověření člověkem přes QR kód – doplňková služba. QR kód na vizuální vrstvě výpisu povede na centrální ověřovací stránku, která status list stáhne, ověří a zobrazí výsledek. QR kód se na výpisy začne umisťovat až po zprovoznění centrální ověřovací služby; jeho podoba se však stanoví předem, aby ho šlo doplnit bez změny schématu.
• Listinná podoba – výpis v listinné podobě ani ověřený výstup nemají strojově čitelnou vrstvu; jejich aktuálnost bude možné ověřit pouze přes QR kód, a to jako doplňkovou informaci. Pravost listiny se nadále ověřuje dosavadními způsoby.

QR kód je doplňkem, který nesmí z hlediska bezpečnosti zhoršit současný stav. Platí proto tyto zásady:

• Strojové ověření na QR kódu nikdy nezávisí. Nedostupnost QR kódu ani ověřovací stránky nemá vliv na platnost ani použitelnost výpisu.
• Ověření přes QR kód vypovídá pouze o aktuálnosti výpisu, na který kód odkazuje, a nepotvrzuje pravost listiny, na které je natištěn. QR kód lze zkopírovat z jiného, pravého výpisu na padělek. Ověřovací stránka to proto musí u každého výsledku výslovně uvádět a odkazovat na postup ověření pravosti (elektronická pečeť výpisu, ověřovací doložka ověřeného výstupu, doložka autorizované konverze).
• Ověřovací stránka běží pouze na jedné pevně stanovené doméně gov.cz, která se zveřejní a uvádí i na výpisu. Nikdy nežádá přihlášení, osobní údaje ani platbu, aby nebylo možné zaměnit ji s podvodnou stránkou, na kterou by vedl podvržený QR kód.
• QR kód neobsahuje osobní údaje, pouze adresu status listu a index. Výsledek se vyhodnocuje v prohlížeči, takže se ověřovací služba nedozví, který výpis je ověřován.
• Ověřovací stránka zobrazí výsledek AKTUÁLNÍ jen po úspěšném ověření pečeti status listu; jinak zobrazí NELZE OVĚŘIT.

Profil přebírá beze změny formát, který pro atestace v EUDI Wallet používá IS PP. Díky tomu lze sdílet komponenty a použít existující knihovny a validátory. Vlastní formáty listu (XML ani JSON) se nepoužijí.

Stav standardizace: specifikace IETF Token Status List byla schválena IESG jako navrhovaný standard (Proposed Standard) a čeká ve frontě RFC Editoru na vydání jako RFC. Poslední verzí je draft-ietf-oauth-status-list-21 z 21. 6. 2026 (stav k 6. 10. 2026). Po vydání RFC se odkazy na této stránce aktualizují.

Ilustrativní podoba nové sekce; názvy elementů, jmenný prostor a ekvivalent v JSON Schema stanoví revize OFN.

<ověření_aktuálnosti xmlns="http://dia.gov.cz/ns/spolecne-casti-elektronickych-dokumentu/overeni-aktualnosti">
  <uri_status_listu>https://status.gov.cz/isvs/{id-ISVS}/listiny/2026-07</uri_status_listu>
  <index_ve_status_listu>136547</index_ve_status_listu>
  <ověřitelné_do>2031-07-22</ověřitelné_do>
</ověření_aktuálnosti>

Hlavička:

{
  "alg": "ES256",
  "typ": "statuslist+jwt",
  "x5c": ["<certifikát pečeti vydavatele>", "<certifikát vydávající CA>"]
}

Obsah (payload):

{
  "sub": "https://status.gov.cz/isvs/{id-ISVS}/listiny/2026-07",
  "iat": 1784700000,
  "ttl": 86400,
  "exp": 1784872800,
  "purpose": "dataCurrency",
  "status_list": {
    "bits": 1,
    "lst": "<bitové pole komprimované ZLIB a kódované base64url>"
  }
}

Hodnota sub musí být shodná s uri uvedenou ve výpisu. V příkladu iat odpovídá 22. 7. 2026 6:00 UTC a exp je o 48 hodin později. Algoritmus (alg) odpovídá klíči pečeti vydavatele. Adresa je pouze ilustrativní.

Status list pro 32 výpisů, ve kterém jsou jako neaktuální označeny výpisy s indexy 5, 17 a 29:

Po kompresi a zakódování: "lst": "eNpTYGBSAAAAqABD"

Pro index 136547 platí: bajt = 136547 div 8 = 17068, bit = 136547 mod 8 = 3, maska 0x08.

1. Ověřit elektronickou pečeť výpisu a to, že údaje sekce ověření aktuálnosti jsou v jejím rozsahu.
2. Zkontrolovat, zda neuplynula doba ověřitelnosti výpisu; pokud ano, výsledek je NELZE OVĚŘIT.
3. Získat status list token z adresy uri (HTTP GET s hlavičkou Accept: application/statuslist+jwt), případně použít kopii z mezipaměti, která není starší než ttl.
4. Ověřit pečeť tokenu a to, že ho vydal oprávněný vydavatel.
5. Ověřit, že sub se rovná uri, že token není prošlý (exp) a že účel listu je dataCurrency.
6. Dekomprimovat lst (ZLIB) a přečíst hodnotu: bajt = idx div 8, bit = idx mod 8, hodnota = (lst[bajt] » bit) & 1.
7. Hodnota 0 znamená AKTUÁLNÍ, hodnota 1 NEAKTUÁLNÍ. Index mimo rozsah listu nebo selhání kteréhokoli kroku znamená NELZE OVĚŘIT.

Implementaci se doporučuje ověřit proti testovacím vektorům ve specifikaci IETF Token Status List.

Status list token ve formátu JWT používá kompaktní serializaci JWS, do které nelze vložit kvalifikované elektronické časové razítko na úrovni JAdES B-T. Token se proto pečetí na úrovni odpovídající JAdES B-B a kvalifikované elektronické časové razítko vydavatel pořizuje ke každé vydané verzi tokenu odděleně.

Pro běžné ověřování aktuálnosti časové razítko ani dlouhodobé uchování nejsou potřeba. Každá nová verze listu je zapečetěna aktuálně platným certifikátem, takže obměna certifikátů pečeti ověřování neomezuje. Pro případnou potřebu prokázat stav k určitému okamžiku v minulosti vydavatel archivuje každou vydanou verzi tokenu spolu s časovým razítkem, a to nejméně do konce doby ověřitelnosti všech výpisů v listu. Veřejné dotazy na historický stav služba nenabízí.

Klíčovým principem je oddělení jmenného prostoru od infrastruktury. Adresy zapsané do vydaných výpisů musí zůstat platné po celou dobu jejich ověřitelnosti. DIA proto doporučuje, aby i pilotní a resortní řešení od prvního vydaného výpisu používala adresy v jednotném, centrálně spravovaném jmenném prostoru, i když za nimi zpočátku stojí infrastruktura vydavatele.

• Pracovní návrh tvaru adresy: https://status.gov.cz/isvs/{id-ISVS-dle-RPP}/{kolekce}/{období}
• Do zprovoznění centrální služby se segment příslušného ISVS technicky deleguje na infrastrukturu vydavatele (reverzní proxy nebo delegace na úrovni cesty). Vydavatel generování, pečetění i publikaci zajišťuje ve vlastní režii.
• Po zprovoznění centrální služby se směrování přepne na ni. Migruje se backend, nikoli odkazy – již vydané výpisy se nemění.
• Centrální publikační služba bude kromě výdeje status list tokenů se správným nastavením mezipaměti nabízet agregační index všech aktivních listů (ve formátu Status List Aggregation podle TSL), odběr změn pro hromadné ověřovatele a ověřovací stránku pro QR kód.
• Status listy jsou přístupné veřejně a bez přihlášení; přihlašování by vydavateli umožnilo zjistit, kdo ověřuje.
• Pracovní návrh obsahu QR kódu: https://overeni.gov.cz/l#u={uri}&i={idx}, tedy tytéž dva údaje, které výpis nese ve strojově čitelné vrstvě. Údaje jsou v části adresy za znakem „#“, kterou prohlížeč neodesílá na server, a výsledek se vyhodnocuje v prohlížeči.

Konkrétní doménové názvy a tvar adres slouží k ilustraci principu; závazně je stanoví technický profil. Závazný je princip jednotného, trvalého, centrálně spravovaného jmenného prostoru nezávislého na infrastruktuře konkrétního resortu.

IS PP vydává atestace (např. výpisu z Rejstříku trestů) do EUDI Wallet jako elektronická potvrzení atributů poskytovaná subjektem veřejného sektoru odpovědným za autentický zdroj (PuB-EAA), ve formátu mdoc podle ISO/IEC 18013-5. U atestací s platností delší než 24 hodin je zveřejňování stavu podle pravidel EUDI Wallet povinné a IS PP k tomu používá status listy. Výpisy z ISVS využívají tentýž mechanismus ve druhé instanci:

• Jeden spouštěč, dva výstupy. Tam, kde tentýž autentický zdroj sytí výpis i atestaci (typicky Rejstřík trestů), musí jedna změna údajů vyvolat současně označení výpisu jako neaktuálního i revokaci atestace. Nikdy nesmí nastat stav, kdy je atestace revokována, ale „stejný“ výpis se jeví jako aktuální.
• Sdílená implementace. Generátor listů, správa indexů, pečetění a publikační řetězec vyvinuté pro IS PP jsou pro výpisy znovupoužitelné; liší se jen kolekce a profil.
• Oddělení účelu. Listy pro aktuálnost a listy pro revokaci se nemíchají; ověřovatel vždy ví, na jakou otázku dostává odpověď.

• Anonymita v davu (herd privacy). Jeden status list pokrývá nejméně 10 000 pozic, takže ze stažení listu nelze poznat, o který výpis jde.
• Náhodné přidělování pozic. Pozice přidělovaná popořadě by sama byla identifikátorem a prozrazovala by čas vydání.
• Stahování do zásoby. Ověřovatelé si listy stahují předem a ukládají do mezipaměti, nikoli až v okamžiku předložení výpisu. Usnadňuje to agregační index.
• Malé agendy. U agend s malým počtem vydaných výpisů by samostatný list nebo četnost jeho změn mohly prozradit více, než je žádoucí. Jejich výpisy se proto sdružují do společných listů.
• Omezení dlouhodobého sledování. Příjemce, který si uloží odkaz na status list, by bez omezení mohl aktuálnost údajů držitele sledovat neomezeně dlouho. Doba ověřitelnosti výpisu toto sledování časově omezuje.
• Bez historických dotazů. Služba neumožňuje zjišťovat stav k libovolnému okamžiku v minulosti.
• Ověřování přes QR kód probíhá v prohlížeči; ověřovací služba se nedozví, který výpis je ověřován.
• Evidence vydaných výpisů u vydavatele a vazba výpisu na pozici v listu jsou zpracováním osobních údajů; jejich rozsah a právní titul budou posouzeny v rámci legislativní analýzy.

Zavádění je rozděleno do fází tak, aby pilotní provoz nebyl závislý na výstavbě centrální infrastruktury. Ministerstvo spravedlnosti mechanismus pilotně implementuje; zavedení povinnosti pro další správce ISVS je podmíněno změnou právních předpisů. Uvedená období jsou orientační.

Kritickou cestou je dohoda základů a pilotní provoz. Standardizace a metodiky běží souběžně s pilotem a promítají do něj zkušenosti. Centrální služba není pro pilot podmínkou díky delegaci segmentu jmenného prostoru.

• Délka doby ověřitelnosti pro jednotlivé druhy výpisů a její vazba na skartační lhůty.
• Vratnost stavu – potvrzení pilotními resorty, že postačuje jednosměrný přechod 0 → 1.
• Hromadné ověřování – popis scénářů pro příjemce, kteří ověřují velké množství výpisů (odběr přes agregační index, notifikace).
• Právní rámec – posouzení zmocnění, ochrany osobních údajů a rozsahu potřebných změn právních předpisů.

• Zákon č. 365/2000 Sb., o informačních systémech veřejné správy – § 9 až 9d
• Zákon č. 499/2004 Sb., o archivnictví a spisové službě – § 69a
• Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby
• OFN Společné části elektronických dokumentů
• Schémata pro strojově čitelnou vrstvu dle zákona č. 499/2004 Sb. (DIA)
• IETF Token Status List
• ETSI TS 119 472-1 – Profiles for Electronic Attestation of Attributes
• EUDI Wallet – Architecture and Reference Framework (ARF)
• Otevřené formální normy
• Czech POINT, Systém správy dokumentů, Informační systém základních registrů