Východiskem nejasnosti je naplnění následujícího bodu Národního standardu pro elektronické systémy spisové služby VMV čá. 42/2023 (dále jen NSESSS):
2.4.5 ESSL zajistí, že vyhotovovaná textová komponenta nebo statická kombinovaná textová a obrazová komponenta určená k odeslání obsahuje metadata ve formátu XML, a to v souladu se schématem XML v příloze č. 3.
Mluví se zde o vyhotovované textové komponentě nebo statické textové a obrazové komponentě určené k odeslání, která má obsahovat metadata ve formátu XML. Toto lze technologicky docílit tak, že bude použit kontejnerový formát PDF a to ve verzi PDF/A-3.
Problém č.1 porušení podpisů původního PDF dokumentu
V systémech spisové služby běžně uživatelé přikládají do dokumentů komponenty určené k odeslání, které jsou v PDF formátu a jsou danou osobou opatřeny elektronickým podpisem a časovým razítkem. Nehledě na to, v jaké verzi podepsané PDF je, tak pokud z tohoto PDF následně vznikne kontejnerové PDF, tak se logicky po přidání přílohy metadata.xml (případně dalších příloh) poruší podepsaná verze a dokument je pro adresáta zobrazen jako nepodepsaný (viz obr. 1).
Obrázek 1 - doplnění původně podepsaného PDF o metadata.xml
Dále pak záleží, zda původní PDF projde konverzí do PDF/A-3 či nikoliv. Pokud nedojde ke konverzi dokumentu (to znamená PDF již ve formátu PDF/A-3 je), ale pouze vznikne kontejner a doplní se přílohy, tak je podpis sice poškozený, ale lze zobrazit původní verzi v době podpisu. Pokud došlo ke konverzi hlavního dokumentu do formátu PDF/A-3, tak se podpisy poškodí, a navíc nebude možné zobrazit ani předešlou verzi. Toto je způsobeno tím, že konverzi do PDF/A-3 nelze provést inkrementální úpravou původního PDF souboru (jak tomu dochází při přidání přílohy) a dojde tedy k úpravě i podepsaného obsahu.
Upozorním, že na tento problém nebudeme narážet pouze u přikládání PDF souborů uživatelem, ale i při práci s rozhraním NSESSS, kde systémy budou pomocí konkrétních metod vkládat komponenty k dokumentům včetně jejich vypravování. Dle znění NSESSS i tyto komponenty má eSSL povinnost doplnit o metadata.xml.
Ano tuto situaci lze teoreticky řešit tak, že budou podepisovány až kontejnerové PDF s vloženými přílohami, jenže z praktického hlediska je to pro instituce velmi obtížně řešitelné, nehledě pouze na business procesy vyřizování dokumentů, ale i fakt, že metadata.xml je vhodné vložit ke komponentě ideálně v době vypravení, protože budou nejaktuálnější.
Aby k porušení podpisu nedocházelo, nabízí se použít jako „nosné“ PDF nějaký průvodní dopis nebo obecnou šablonu a ostatní přílohy, u kterých je porušení podpisů nežádoucí vložit jako přílohy do kontejneru společně se souborem metadata.xml. Nicméně tohle bude generovat další zbytečnou agendu v eSSL a současně také problém č.2, který je popsán níže.
Problém č.2 kontejnerové PDF není vždy uživatelsky jednoznačně čitelné
Pokud je otevírán kontejnerový PDF soubor, který obsahuje další přílohy (metadata.xml, další PDF, DOCX, …) např. v internetovém prohlížeči, tak vůbec nejsou zobrazeny přílohy. Bude tedy docházet k nepochopení technologie kontejnerového PDF souboru veřejností, jelikož ne všichni používají Adobe Reader.
Návrh změny: Změnit znění bodu tak, aby za kontejner byl považován e-mail nebo DZ
Pokud by se přikládal soubor metadata.xml do odchozí Datové nebo e-mailové, což jsou samy o sobě kontejnery i dle definice NSESSS, tak by to výrazně zjednodušilo zpracování nejen pro odeslání ale i pro příjem (systémy by nemusely umět vyhodnotit více souborů metadata.xml, jak tomu může dojít nyní, pokud budou kontejnerové PDF vznikat postupně).
Změna by mohla být např:
2.4.5 ESSL zajistí, že elektronické vypravení pomocí datové nebo e-mailové zprávy, které obsahuje vyhotovované textové komponenty nebo statické kombinované textové a obrazové komponenty určené k odeslání, obsahuje metadata ve formátu XML, a to v souladu se schématem XML v příloze č. 3.
Prosím o vysvětlení, zda chápeme problematiku správně, případně o vyjádření, jak se technologicky s tímto požadavkem NSESSS vypořádat. Děkuji
Východiska
Východiskem nejasnosti je naplnění následujícího bodu Národního standardu pro elektronické systémy spisové služby VMV čá. 42/2023 (dále jen NSESSS):
2.4.5 ESSL zajistí, že vyhotovovaná textová komponenta nebo statická kombinovaná textová a obrazová komponenta určená k odeslání obsahuje metadata ve formátu XML, a to v souladu se schématem XML v příloze č. 3.Mluví se zde o vyhotovované textové komponentě nebo statické textové a obrazové komponentě určené k odeslání, která má obsahovat metadata ve formátu XML. Toto lze technologicky docílit tak, že bude použit kontejnerový formát PDF a to ve verzi PDF/A-3.
Problém č.1 porušení podpisů původního PDF dokumentu
V systémech spisové služby běžně uživatelé přikládají do dokumentů komponenty určené k odeslání, které jsou v PDF formátu a jsou danou osobou opatřeny elektronickým podpisem a časovým razítkem. Nehledě na to, v jaké verzi podepsané PDF je, tak pokud z tohoto PDF následně vznikne kontejnerové PDF, tak se logicky po přidání přílohy metadata.xml (případně dalších příloh) poruší podepsaná verze a dokument je pro adresáta zobrazen jako nepodepsaný (viz obr. 1).
Dále pak záleží, zda původní PDF projde konverzí do PDF/A-3 či nikoliv. Pokud nedojde ke konverzi dokumentu (to znamená PDF již ve formátu PDF/A-3 je), ale pouze vznikne kontejner a doplní se přílohy, tak je podpis sice poškozený, ale lze zobrazit původní verzi v době podpisu. Pokud došlo ke konverzi hlavního dokumentu do formátu PDF/A-3, tak se podpisy poškodí, a navíc nebude možné zobrazit ani předešlou verzi. Toto je způsobeno tím, že konverzi do PDF/A-3 nelze provést inkrementální úpravou původního PDF souboru (jak tomu dochází při přidání přílohy) a dojde tedy k úpravě i podepsaného obsahu. Upozorním, že na tento problém nebudeme narážet pouze u přikládání PDF souborů uživatelem, ale i při práci s rozhraním NSESSS, kde systémy budou pomocí konkrétních metod vkládat komponenty k dokumentům včetně jejich vypravování. Dle znění NSESSS i tyto komponenty má eSSL povinnost doplnit o metadata.xml.
Ano tuto situaci lze teoreticky řešit tak, že budou podepisovány až kontejnerové PDF s vloženými přílohami, jenže z praktického hlediska je to pro instituce velmi obtížně řešitelné, nehledě pouze na business procesy vyřizování dokumentů, ale i fakt, že metadata.xml je vhodné vložit ke komponentě ideálně v době vypravení, protože budou nejaktuálnější.
Aby k porušení podpisu nedocházelo, nabízí se použít jako „nosné“ PDF nějaký průvodní dopis nebo obecnou šablonu a ostatní přílohy, u kterých je porušení podpisů nežádoucí vložit jako přílohy do kontejneru společně se souborem metadata.xml. Nicméně tohle bude generovat další zbytečnou agendu v eSSL a současně také problém č.2, který je popsán níže.
Problém č.2 kontejnerové PDF není vždy uživatelsky jednoznačně čitelné
Pokud je otevírán kontejnerový PDF soubor, který obsahuje další přílohy (metadata.xml, další PDF, DOCX, …) např. v internetovém prohlížeči, tak vůbec nejsou zobrazeny přílohy. Bude tedy docházet k nepochopení technologie kontejnerového PDF souboru veřejností, jelikož ne všichni používají Adobe Reader.
Návrh změny: Změnit znění bodu tak, aby za kontejner byl považován e-mail nebo DZ
Pokud by se přikládal soubor metadata.xml do odchozí Datové nebo e-mailové, což jsou samy o sobě kontejnery i dle definice NSESSS, tak by to výrazně zjednodušilo zpracování nejen pro odeslání ale i pro příjem (systémy by nemusely umět vyhodnotit více souborů metadata.xml, jak tomu může dojít nyní, pokud budou kontejnerové PDF vznikat postupně).
Změna by mohla být např:
2.4.5 ESSL zajistí, že elektronické vypravení pomocí datové nebo e-mailové zprávy, které obsahuje vyhotovované textové komponenty nebo statické kombinované textové a obrazové komponenty určené k odeslání, obsahuje metadata ve formátu XML, a to v souladu se schématem XML v příloze č. 3.Prosím o vysvětlení, zda chápeme problematiku správně, případně o vyjádření, jak se technologicky s tímto požadavkem NSESSS vypořádat. Děkuji