Spoločné zasadnutia pracovnej skupiny PS2 (19. zasadnutie) a PS 4 (23. zasadnutie) - zápis

Last modified by zuzna_babol on 2023/08/02 12:38

Dátum: 17. 07. 2023

Miesto: on-line formou prostredníctvom aplikácie MS Teams

Čas: 13:00 - 15:30 hod.

Zúčastnení:

Ministerstvo investícií, regionálneho rozvoja a informatizácie SR – Štefan Szilva, Karol Ďumbier, Vladimír Kováč, Monika Mosejová, Zuzana Baboľ Fiľová, Veronika Schusterová, Ľubica Kašíková, Monika Miazdrová,
Ministerstvo financií Slovenskej republiky – Vladimír Janský
Ministerstvo kultúry Slovenskej republiky – Rastislav Machel

Ministerstvo spravodlivosti Slovenskej republiky – Mariana Bieliková
Ministerstvo hospodárstva Slovenskej republiky – Ing. Peter Stropko
Národná agentúra pre sieťové a elektronické služby – Ivan Turčan
Národný bezpečnostný úrad – Peter Rybár
Úrad geodézie, kartografie a katastra Slovenskej republiky – Vladimír Macko, Miroslav Kováčik
Úrad na ochranu osobných údajov Slovenskej republiky – Martin Tihelka
NESS Slovensko a.s. Vladimír Földeši
Združenie miest a obcí Slovenska –Jozef Chajdiak
Združenie samosprávnych krajov – Roman Kučerák DITEC, a.s. – Pavol Frič, Ján Dobias, Slovensko.Digital - Ľubor Illek, Sociálna poisťovňa – René Vatter, Maroš Krajňák DWC Slovakia a.s. – Miroslav Václavík, GlobalTel, a.s. – Michal Kevický Prima banka – Tomáš Baran

Program:

Otvorenie zasadnutia
Návrhy na prenos XML údajov vyplneného elektronického formulára v rámci PDF
Návrh novely vyhlášky MIRRI SR č. 70/2021 Z. z. o zaručenej konverzii
Informácia k návrhu technického riešenia Autorizácie odoslaním podania s opätovnou autentifikáciou v súlade s § 23 ods. 1 písm. a) bod 2 zákona č. 305/2013 Z. z. o e-Governmente a návrh na úpravu § 48 ods. 2 až 6 vyhlášky č. 78/2020 Z. z. o štandardoch pre ITVS
Informácia k návrhu pre autentifikáciu aplikácií prostredníctvom API gateway v spojení s HTTPS a REST: TLS autentifikácia v kombinácii s Basic autentifikáciou, APIKey-Shared Secret, OAuth2 s OpenIDConnect s JWT tokenom (návrh na doplnenie § 11 vyhlášky ÚPVII č. 78/2020Z.Z.)
Rôzne
Záver zasadnutia

K bodu 1: Otvorenie zasadnutia

Spoločné zasadnutie pracovných skupín PS 2 pre bezpečnostné štandardy (ďalej len „PS 2") a pracovnej skupiny PS 4 pre technické štandardy a štandardy použitia súborov (ďalej len „PS 4") otvoril predseda PS 4 pán Štefan Szilva, ktorý privítal všetkých zúčastnených členov pracovných skupín a prizvané osoby.
Predseda PS 4 prítomných informoval o hlavných témach zasadnutia, ktorými sú: Návrhy na prenos XML údajov vyplneného elektronického formulára v rámci PDF, návrh novely vyhlášky o zaručenej konverzii. Predseda PS 4 ďalej prítomných členov informoval, že ohľadne autorizácie odoslaním podania, ktorá bola prerokovávaná na predošlých zasadnutiach pracovných skupín, MIRRI SR vyhodnotilo zaslané pripomienky a čiastočne upravilo jej ďalší návrh, ktorý však ešte nebol zaslaný do pracovnej skupiny z dôvodu, že ohľadom jeho technických riešení stále prebieha diskusia, napríklad ohľadne spoločnej autorizácie. MIRRI SR preferuje samostatné pečatenie jednotlivých objektov namiesto spoločnej autorizácie informácie o vykonanej autorizácii spoločne s podaním/prílohami). Predseda PS 4 ďalej informoval, že ohľadom informácie k aktuálnemu stavu zapracovania pripomienok k prílohe č. 3 DNR projektu Centrálny API management platformy, kde aktuálne MIRRI SR tiež zapracúva pripomienky.

K bodu 2: Návrhy na prenos XML údajov vyplneného elektronického formulára v rámci PDF

Predseda PS 4 odprezentoval predkladaný návrh spolu s jeho podkladmi. V rámci podkladov boli zaslané rovnako aj príklady ako by prenos XML údajov vyplneného elektronického formulára v rámci PDF mohol technicky vyzerať, a to pri jednotlivých druhoch podaní s autorizáciou alebo bez autorizácie. Dané príklady boli poskytnuté členom pracovnej skupiny na predchádzajúcom zasadnutí formou odkazu na úložisko.
Predseda PS 4 oboznámil prítomných s dvoma variantmi (MIRRI SR preferuje variant č. 1 v I. bode) ako by mohol prenos XML údajov vyplneného elektronického formulára v rámci PDF vyzerať. Predseda PS 4 ďalej oboznámil prítomných aj s ďalšími alternatívami prenosu XML údajov.
NASES zvažuje implementovať oba varianty, pričom OVM na základe dohody s NASES s ohľadom na minimalizáciu dopadov na OVM bude môcť príslušný variant použiť.
Postup akým sa navrhuje prenos XML údajov vyplneného elektronického formulára v rámci PDF je nasledovný:

používateľ vyplní elektronické podanie podľa údajov elektronického formulára a následne vzniknú XML údaje vyplnené podľa elektronického formulára, ktorý je registrovaný v module elektronických formulárov (tak ako to funguje aj v súčasnosti),
vzniknuté XML údaje budú vložené do PDF súboru, ktorý bude ich vizualizáciou. Bude použitá technológia PDF attachment (názorne použitá v príklade, ktorý bol zaslaný ako podklad s pozvánkou) (t. j. vo vnútri PDF súboru budú XML údaje, ku ktorým sa používateľ vie dostať a otvoriť ich pomocou rôznych PDF prehliadačov),
neoddeliteľné spojenie XML údajov a jeho PDF vizualizácie bude zabezpečené prostredníctvom pečate MIRRI SR vo formáte PAdES, ktorá bude používaná ako záruka, že údaje zobrazované v PDF sú identické s XML dátami vyplneného formulára vloženými ako príloha do PDF a následne sa budú môcť tieto XML údaje spracovávať),
podľa typu autorizácie:

ak by sa autorizácia kvalifikovaným elektronickým podpisom vyžadovala, PDF súbor by bol zároveň podpísaný používateľom klientským podpisovačom (PAdES podpis je preferovaný). V PDF súbore by boli XML údaje zapečatené MIRRI SR a podpísané klientským certifikátom používateľa.
ak by sa autorizácia kvalifikovaným elektronickým podpisom nevyžadovala, v PDF súbore by boli XML údaje zapečatené MIRRI SR (uvedené by bolo možné použiť aj pri autorizácii odoslaním podania).

Cieľom je tiež obmedziť dopady na existujúce systémy, ktoré v hlavnom objekte elektronickej správy Sk-Talk v objekte s Class=FORM, očakávajú XML údaje.
Alternatívy vytvárania Sk-Talk správ:

1. XML údaje ako príloha v PDF súbore

Variant 1. Používateľ bude podpisovať PDF súbor (postup uvedený v tomto bode preferuje aj MIRRI SR aj NASES)

XML údaje vyplneného formulára v ASiC budú v hlavnom objekte v Sk-Talk správy (s Class=FORM),
pri použití tejto možnosti XML dáta vložené v Sk-Talk v hlavnom objekte (s Class=FORM) nebudú podpísané používateľom ale budú zapečatené pečaťou MIRRI SR,
v prílohe Sk-Talk správy bude PDF súbor obsahujúci XML dáta vyplnené podľa formulára, ktorý bude podpísaný pečaťou MIRRI SR a podľa typu vyžadovanej autorizácie aj KEPom používateľa.
ak systém OVM bude pripravený a bude preferovať prijímanie len PDF súborov, nebudú do správy ako hlavný objekt vkladané XML údaje zapečatené MIRRI SR ale rovno PDF súbor.

Variant 2. Používateľ bude podpisovať XML dáta vyplneného formulára

pri použití tejto možnosti by sa zachoval súčasný stav a to, že požívateľ bude autorizovať samotné XML údaje (XMLDataContainer v ASiC) a tieto by sa následne v podobe ASiC súboru:
vložili v Sk-Talk správe v hlavnom objekte (s Class=FORM) - tieto budú rovnako ako doteraz podpísané samotným používateľom,
vložili do PDF súboru, ktorý bude ako príloha v Sk-Talk správe (t. j. v PDF súbore bude rovnaký ASiC súbor ako v hlavnom objekte správy). UPVS následne PDF zapečatí pečaťou MIRRI SR pre garanciu integrity a prepojenia medzi ASiC a PDF súborom, zároveň bude zárukou, že údaje zobrazované v PDF sú identické s dátami vloženými ako príloha v PDF.
týmto postupom však vznikne vnáranie jedného podpisovaného kontajnera do druhého čo sa javí ako nepraktické napríklad pri overovaní podpisov,
pri použití tejto možnosti PDF nebude podpísané samotným používateľom, ale len prístupovým miestom MIRRI SR.

Predseda PS 4 ďalej oboznámil prítomných, ako by vyzeral prenos XML údajov vyplneného elektronického formulára v rámci PDF pri vytvorení rozhodnutia:

rozhodnutie by vzniklo ako XML údaje vyplnené podľa elektronického formulára rozhodnutia alebo formulára základných údajov vyžadovaných § 27 ods. 5 zákona o e-Governmente,
vytvorí sa PDF súbor obsahujúci rozhodnutie (buď z XML údajov vyplnených podľa elektronického formulára alebo ako samostatný PDF súbor do ktorého budú vložené XML údaje),
OVM by následne vykonala autorizáciu PDF súboru kvalifikovaným elektronickým podpisom vyhotoveným s použitím mandátneho certifikátu alebo kvalifikovanou elektronickou pečaťou s pripojením kvalifikovanej elektronickej časovej pečiatky,
vytvoril by sa tak elektronický úradný dokument tak, aby v jednom PDF mohli byť zahrnuté aj XML údaje,
tento postup by pre OVM nebol povinný a sám by rozhodol či prejde na túto technológiu.

Predseda PS 4 ďalej oboznámil prítomných, ako by vyzeral prenos XML údajov vyplneného elektronického formulára v rámci osvedčovacej doložky pri zaručenej konverzii:

vytvorenie osvedčovacej doložky by prebiehalo podobne ako vytvorenie elektronického úradného dokumentu. Do jedného súboru by sa spojila osvedčovacia doložka a PDF vizualizácia a následne do výsledného PDF súboru sa vložia ako príloha XML údaje, ktoré následne autorizuje osoba vykonávajúca zaručenú konverziu.

Predseda PS 4 ďalej prítomných informoval o základnom vyhodnotení dopadov pri použití prenosu XML údajov vo formáte PDF súboru:

cieľom nie je ustanoviť PDF súbory ako jedinú možnosť použitia prenosu XML údajov ale použitie bude dobrovoľné podľa rozhodnutia príslušného OVM. OVM bude môcť použiť pôvodné štandardy alebo novú technológiu zahrnutia údajov XML v PDF.
pri postúpení veci, podania (t.j. ak by s použitím formulára novou technológiou bolo podanie zaslané nesprávnemu OVM) sa postupované podanie prikladá do prílohy správy, a preto sa neočakávajú dopady na existujúce systémy,
ÚPVS bude poskytovať službu na extrakciu dát z PDF podľa výberu varianty pre OVM,
pokiaľ adresát rozhodnutia potrebuje spracúvať dáta naďalej sa budú nachádzať v hlavnom objekte elektronickej správy,
v prípade použitia tejto technológie na osvedčovacie doložky zaručenej konverzie, pôjde o najväčší dopad na systémy tretích strán, napr. kvôli potrebe overovania voči centrálnej evidencii záznamov - muselo by dôjsť k úprave systémov čo by znamenalo finančné náklady,
pri centrálnom úradnom doručovaní rozhodnutí musí byť naďalej hlavný objekt správy údaje vyplnené podľa formulára vzhľadom na existujúce technické obmedzenie CÚD.

2. XML údaje v rámci XMP (Extensible Metadata Platform) v PDF súbore

nie vhodné kvôli nemožnosti zachovať binárny obsah a komplikovanosti transformácie XML dát do podoby XMP a neskoršej extrakcie z XMP do XML.

3. Údaje v rámci XFA alebo Acroforms v PDF súbore

možnosť použitia ukladania údajov v PDF súboroch použitím proprietárnej Adobe technológie XFA, ktorá však neprešla ISO štandardizáciou,
nemožnosť použitia PDF/A v prípade XFA, nutnosť použitia PDF so širšími dynamickými vlastnosťami,
údaje vy sa neukladali vo forme XML používanej v slovenskom e-Governmente, ale vo formáte definovanom Adobe v XFA alebo v Acroforms technológii, potrebná špecifická služba pre extrakciu dát.

Ďalšie + a – sú zachytené v podkladoch, ktoré boli členom pracovnej skupiny zaslané spolu s pozvánkou na jej zasadnutie.
Diskusia:
p. Frič:

na predložené návrhy reagoval, že dobrá myšlienka vyriešiť formuláre sa dostáva do absolútne absurdných dôsledkov a popri využití Adobe ako nástroja na tvorenie formulárov sa plánuje využitie Adobe PDF ako nového kontajnera na prenos údajov,
navrhol, aby sa nemenil spôsob doterajšej komunikácie s OVM, ktorý by sa dotkol všetkých rezortov,
navrhol, aby PDF súbor bol zasielaný ako príloha a hlavný dokument elektronickej úradnej správy ponechať v takom stave akom je aj teraz (XML údaje autorizované v Asice podľa zákona) a až následne je možné viesť diskusie o forme PDF súboru v prílohe (či to bude PDF autorizované MIRRI SR alebo tam budú vložené XML údaje) a kto chce môže si PDF vytiahnuť z prílohy a z neho dáta extrahovať a spracovať,
ďalej uviedol, že mnohé OVM (rezorty), ktoré zobrazujú obsah podania prostredníctvom svojich systémov PDF súbor nepotrebujú ale potrebujú práve XML údaje,
upozornil, že návrh zasielať v hlavnom objekte elektronickej správy údaje autorizované MIRRI SR nie je vhodný, nakoľko tento objekt neobsahuje informáciu o tom, kto dokument autorizoval a či tá osoba bola opravená ho autorizovať a bolo by príliš komplikované to vyhľadať v PDF súbore.

Predseda PS 4 podotkol, že z uvedeného vyplýva, že p. Frič preferuje variant č. 2 v predloženom návrhu (XML údaje autorizované používateľom v ASiC ako v hlavnom objekte elektronickej úradnej správy a v prílohe PDF budú XML údaje v ASiC), avšak v tejto podobe by PDF čiastočne strácalo svoj význam.
p. Frič:

uviedol, že navrhované riešenie je zbytočne komplikované a nevidí význam PDF súboru ako ďalšieho štvrtého kontajnera (1. kontajner Sk-Talk, 2. kontajner Message kontajner, 3. kontajner AsiC a PDF ako štvrtý kontajner ),
ak ostane ako hlavný objekt klasické podanie ako teraz, môže sa diskutovať o prílohe aj s dátami, aby sa rezorty na to pripravili ale na prípravu je potrebný čas,
rozhodnutie by nemalo vytvárať OVM ako sa rozhodne, keďže rozhodnutie môže byť prílohou ďalších podaní a môže to mať vplyv aj pri životných situáciách kde sa majú správy reťaziť). Tým pádom by boli ostatné OVM nútené spracúvať PDF súbory obsahujúce XML údaje a koncový používateľ (občan) by dostal rozhodnutie, ktoré nebude možné použiť voči inému ďalšiemu OVM.

Predseda PS 4:

reagoval, že používanie viacerých kontajnerov má určité technické nevýhody ale aj výhody z hľadiska občana ako koncového používateľa,
rozumie, že systém OVM potrebuje spracovať dáta a nepotrebuje PDF, avšak podania typu Všeobecná agenda je skôr o čítaní manuálnom než o strojovom vyhodnocovaní (podľa štatistík tvoria asi tretinu všetkých podaní),
uviedol, že čo sa týka rozhodnutí je stav taký že OVM by si mali vzájomne vymieňať a poskytovať údaje, ktoré sú potrebné aj v rámci životných situácií, tak ako to je v upravené zákonom,
.xml údaje vo vnútri rozhodnutia by boli len vo väčšine prípadov bonusom a dnes je bežná prax rozhodnutie len ako PDF a dáta neboli žiadne,
obsah rozhodnutí sa obvykle v praxi ďalej strojovo nespracováva, a preto NASES a MIRRI SR vidia len minimálne dopady.

p. Kováčik:

položil otázku aký je účel tohto navrhovaného riešenia a aké problémy sa ním majú vyriešiť.

Predseda PS 4 reagoval, že tieto požiadavky vyplynuli:

z uznesení Vlády SR, aby sa zjednodušila práca pre adresátov rozhodnutí (išlo hlavne o podnety z podnikateľského prostredia), aby boli rozhodnutia pre koncových používateľov čitateľnejšie a aby si ich mohli stiahnuť, v jednoducho zobraziteľnom formáte a použiť ďalej na právne účely. V tejto súvislosti je OVM často využívaný aj bývalý § 28 ods. 6 zákona o e-Governmente, kde OVM zasielajú rozhodnutia vo formáte PDF súboru v prílohe, kvôli ktorému museli byť donedávna povinne spoločne autorizované XML údaje s PDF súborom.
z podnikateľského prostredia vyvstali požiadavky aj na osvedčovacie doložky, aby neboli vo forme strojových dát (XML údaje), ktoré sa ťažko čítajú, a z dôvodu ľahšej vizualizácie sa navrhlo spojiť ich do jedného PDF súboru (doložka a výsledný skonvertovaný dokument),
ohľadne elektronických podaní vyvstali požiadavky, aby občan, ktorý vytvorí podanie ho mohol jednoducho a aj dodatočne kedykoľvek prečítať, zobraziť a keď ho podpisuje, aby podpisované údaje zo strany používateľa boli s istotou, tie údaje, ktoré vidí vo vizualizácii a na tento účel spoľahlivo slúži formát PDF,
motivácia zmien bola opakovane prezentovaná na zasadnutiach PS 2022 a 2023,
návrh na využitie novej technológie vyvstal aj z prieskumu trhu bežne dostupných nástrojov vo svete na vytváranie formulárov a ich vypĺňanie.

p. Kováčik:

opätovne uviedol, že toto nebude to viesť k zlepšeniu situácie a pre občana to v konečnom dôsledku určite nebude výhodnejšie,
podľa neho sa kladie dôraz na elektronické podanie, a pri tom neboli požiadavky ho meniť, použitie PDF súborov pri vytváraní rozhodnutia možno má zmysel, aby občania vedeli čítať PDF,
uviedol, že nevidí prínosy pri zaručenej konverzii, rovnako aj jej použití v zahraničí.

p. Frič:

podotkol, že Adobe ako náhrada existujúceho dizajnéra ako aj nástroja na vypĺňanie elektronických formulárov je dobrý krok, ktorý zjednoduší to tvorbu aj vypĺňanie formulárov,
uviedol, že stále sa riešia problémy zaručenej konverzie a bolo by vhodné spraviť víziu spoločnú kam chce sa chce štát posunúť v zaručenej konverzii, aby sa ďalšie riešenia robili v súlade s touto víziou.

Predseda PS 4 na uvedené reagoval:

PDF Adobe je dizajnér bežne používaný vo svete, a preto sa navrhlo využiť už existujúci produkt, aby sa nemuselo celé riešenie programovať od začiatku,
z dôvodu spätnej kompatibility sa pri vytváraní formulárov v Adobe zároveň zachováva vytváranie .xslt a .xsd schém, ktoré sa budú zapisovať do elektronického formulára,
výhodou použitia Adobe technológie je podľa analýzy NASES aj to, že sa dá natívne použiť aj z mobilov,
vízia zaručenej konverzie bola prezentovaná na predošlých zasadnutiach a celý prezentácia tejto vízie je v zverejnených podkladoch PS v metaIS.

p. Kováčik:

uviedol, že ich organizácia posiela štruktúrované rozhodnutia v e-forme v hlavnom objekte elektronickej úradnej správy a zároveň položil otázku ako bude legislatívne ošetrený prenos XML údajov vo forme PDF, či bude potrebné kontrolovať ich súlad a kto za to bude zodpovedať.

Predseda PS 4:

odpovedal, že zatiaľ nie je potrebné upraviť ďalej legislatívu a je potrebné upraviť prílohu č. 1 vyhlášky o štandardoch,
v prípade použitia prvého variantu je PDF súbor podpísaný samotným koncovým používateľom vlastne PDF súbor je vlastne prezentácia XML údajov v zmysle štandardov,
bez ohľadu na výber riešenia budú údaja formulára stále vo formáte XML údajov a bude vyplniteľný ako aj zobraziteľný aj naďalej cez rôzne integrované systémy s využitím štandardného formulára v MEF. Pre odoslania nebude potrebné vyplniť PDF súbor pri zasielaní cez integrované systémy.

p. Kováčik:

reagoval, že ÚGKK SR má špecializovaný portál, kde občan vyplní XML údaje a pošle ich v AsiC. Ak občan vloží podanie do PDF súboru sa po zavedení tejto novej technológie budeme musieť povinne zaoberať a OVM vznikne povinnosť.

p. Frič:

reagoval, že keď je raz občanovi ponúknutá možnosť niečo urobiť zároveň sa tým zavedie povinnosť pre OVM to akceptovať

Predseda PS 4:

uviedol, že došlo pravdepodobne k nepochopeniu, keďže toto je len návrh riešenia ako sa dajú prenášať XML údaje vo formáte PDF,
OVM ako adresát podania bude rozhodovať či použije túto technológiu,
ak služba nebude vytvorená v Adobe riešení (alebo aj bude vytvorená ale nebude sprístupnený nástroj na vypĺňanie na niektorom prístupovom mieste) nebude podľa navrhovaných štandardov povolené zasielať podania v PDF súbore obsahujúcom XML dáta, t.j. gestor služby sa bude rozhodovať či bude také podania prijímať technológiou použitou pre vypĺňanie pri zverejnení služby,
kontrolu súladu údajov XML s PDF súborom nie je potrebné overovať ich súlad bude garantovať ÚPVS.

p. Frič sa opýtal na možnosť podpisovania a či bude zabezpečí sa všeobecný popisovač.
Predseda PS 4 odpovedal, že pripravuje sa univerzálny dostupný podpisovač na stiahnutie, ktorým bude možné podpisovať aj PDF súbory s PAdeS.
p. Kevický:

ohľadom prenosu XML údajov vo formulári PDF s použitím technológie XFA sa dopytoval bezpečnostnú otázka ohľadom variant dynamických vizualizácií, nevie čo to znamená a evokuje to java script a či je k tomu širší detail,
podľa jeho názoru formuláre bez ohľadu na použitie technológie by mali byť statické a nemalo by byť možné podpisovať niečo, čo sa môže akokoľvek dynamicky meniť.

Predseda PS 4:

v štandardoch v § 19 vyhlášky o štandardoch je použitie XFA zakázané. (to umožňuje zväčšovanie polí, použitie zoznamov údajov a ich načítanie z externých zdrojov, odosielanie atď.),
vzhľadom na proprietárny charakter XFA a nemožnosť použitia PDF/A nebola táto technológia detailne analyzovaná,
Adobe podporuje aj java scriptové formuláre, pôvodne uvažovalo použiť technológiu XFA ako náhradu za HTML formuláre, avšak prax ukázala, že Adobe od svojho úmyslu upustilo a aktivity smeruje na HTML/ webové formuláre.

p. Illek:

sa vyjadril, že aj keď nie je vykonaná detailná expertíza, pri prenose XML údajov v PDF súbore podporuje variant č. 1, ktorý je podľa neho všeobecne použiteľný,
podotkol, že táto problematika bola už niekoľko krát riešená, prezentovaná a konzultovaná najmä na strategických PS k NKIVS ako aj pri novele zákona o e-Governmente, ktorej znenie bolo upravené tak, aby bolo umožnené to, čo momentálne prezentuje NASES
podľa jeho názoru bola problematika prenosu XML údajov do PDF súboru dobre vysvetlená aj z hľadiska bezpečnosti, aj z hľadiska čo najjednoduchšej implementácie pre OVM,
z pohľadu Slovensko Digital sa dlhodobo sleduje cieľ, aby rozhodnutia aj podania bolo možne robiť v čo najjednoduchšej forme pre používateľov,
hlavný význam podľa neho spočíva v tom, že aj v súčasnosti je umožnené vytváranie podaní ako PDF súborov, rozhodnutie môže byť vytvorené formou textového dokumentu čo je podľa štandardov tiež PDF súbor,
bez ohľadu na implementáciu navrhovaného prenosu XML údajov vo forme PDF súboru zo strany NASES/MIRRI SR, podľa už účinného zákona môžu OVM legálne robiť rozhodnutia vo forme PDF súborov,
rovnako ako Predseda PS 4 podotkol, že prenos XML údajov vo formáte PDF súboru nemá byť plošnou zmenou (najmä kvôli náročnosti zmeny interných systémov ako aj to že pre určité typy podaní to nemusí byť vhodné) ale bude určený len pre tých, ktorí si tento postup zvolia,
uviedol, že je správne umožniť vytváranie podaní vo formáte PDF súborov občanom a aj tým OVM, ktoré chcú a vedia s tým pracovať,
upozornil, že „Všeobecná agenda" ako typ podania z právneho hľadiska neexistuje, je len vytvorenou pomôckou na ÚPVS pre iné typy podaní, na ktoré neexistuje formulár,
opätovne uviedol, že z hľadiska zmien je variant č. 1 bezpečný a podporuje ho u OVM ktoré si ho zvolia tak, ako to bolo odprezentované predsedom PS4 (občan bude mať podanie v formáte PDF súboru podpísané, nie je k tomu potrebná žiadna služba, žiadna zaručená konverzia),
z pohľadu používateľa dobré riešenie a z pohľadu OVM nevidí problém s „predspracovaním" podaní prevádzkovateľom ÚPVS, síce príde jednak samotné podanie (v tomto prípade PDF z pomerne zložitou vnútornou štruktúrou) z UPVS ale v rovnakej správe príde aj to „predspracované" podanie z ktorého sú „vytiahnuté" XML údaje, ktoré sú tiež OVM poslané,
čo sa týka právnej záväznosti, záväzné je podpísané PDF občanom. Na súlad XML údajov s obsahom PDF sa vieme sa spoľahnúť rovnako ako na správnosť fungovania ÚPVS. Tak ako sa dnes OVM spoliehajú na službu pre vrátanie podpísaných dát z ÚPVS rovnako sa môžu spoliehať na nové služby.

p. Rybár:

uviedol, že po skúsenostiach s formulármi, prácou s nimi, vrátane ich implementácie, je v prvom rade potrebné upraviť XMLDataContainer, ktorý obsahuje v súčasnosti množstvo chýb, nečitateľných znakov, ktoré sú nečitateľné aj pre mobilné platformy a bezvýsledne niekoľko krát požadovali od MIRRI SR jeho nápravu,
uviedol, že s prihliadnutím na funkčnosť a účelnosť je potrebné zamerať sa na vylepšenie existujúceho XMLDatacontainera, aby fungoval tak ako má, aby boli dodržané jeho základne postupy, aby bol kvalitný a boli v ňom dostupné údaje aj bez použitia aplikácií, vrátane úpravy jeho transformácie do HTML, ktorá je síce najprospešnejšia ale obsahuje plno zbytočných údajov,
pri prenose XML údajov vo formáte PDF by bolo potrebné vykonať množstvo analýz a jeho výsledkom by bola komplikovaná vizualizácia PDF, nevyriešil by sa užívateľský komfort a rovnako by sa nevyriešili problémy s existujúcim XMLDataContainerom,
podľa neho rovnako sú aplikácie na zobrazovanie a podpisovanie formulárov chybné. Od MIRRI SR aj NASES opakovane bezvýsledne požadoval, aby sprístupnili aplikáciu pre zobrazovanie XMLDatacontaInera a jeho použitie aj z iných podpisových aplikácií. Zároveň informoval, že z tohto dôvodu vytvoril a zverejnil vlastnú aplikáciu na zobrazovanie XMLDataContainera.
rovnako požadoval opravu nedostupných linkov – referencií schém v XMLDataContajneri,
rovnako vo vytváraných XMLDataContaineroch chýba povinná koncovka .xdcf,
upozornil, že tak ako je potrebné riešiť vizualizáciu XMLDataContainera podobne je potrebné riešiť aj vizualizáciu odporúčaných atribútov v európskej peňaženke digitálnej identity. Tam sú rovnako prenášané iba údaje a bude sa zabezpečovať ich vizualizácia na úrovni peňaženky.
navrhol, aby formát XMLDataContainer by mohol byť štandardizovaný aj na úrovni EÚ.

Predseda PS 4:

oboznámil prítomných, že nasadenie zmien do modulu elektronických formulárov trvalo dlhšie obdobie kvôli dodávateľovi, ktorý je v omeškaní (tento problém bol riešený aj na vyššej úrovni). V rámci neho má byť riešená aj dereferenciácia (aj živé linky na súčasti formulára – vrátane schém) je to obsiahnuté aj v zverejnenom release pláne,
v rámci nasadených zmien v module elektronických formulárov bude možné nájsť na verejne dostupných linkách každú časť formulára, aj keď aktuálne používané linky v XMLDatacontaineri nikdy nebudú môcť byť plne funkčné kvôli používaniu generickej URI referencie v kombinácii s atribútom MediaDestinationTypeDescription, (Generické linky form.xslt neumožňujú identifikovať konkrétnu schému ak ich je vo formulári viac na rovnaký účel.) Jednoznačné URI referencie majú dopady na integrované subjekty,a preto ich nasadenie bude spustené postupne.
problém s nedostupnosťou zobrazovača vidí v komplikovanosti realizácie projektových zámerov, ktoré boli spisované už pred niekoľkými rokmi,
ohľadne prípony .xdcf uviedol, že je zadaná požiadavka na jej použitie, zatiaľ nie je zrealizovaná a je v štádiu prípravy, a rovnako aj správne nahrávanie XMLDatacontajnera do konštruktora správy sa plánuje vyriešiť,
ohľadom použitia PDF súborov opätovne zdôraznil, že sa očakáva, že sa bude týkať časti podaní a časť rozhodnutí, a preto sa neuvažuje v žiadnom prípade o kompletnom nahradení existujúcich formulárov a XML údajov len v tomto PDF formáte,
diskusia je o tom či budeme používať PDF na podpisovanie a prenos údajov alebo to bude tak ako doteraz, že PDF súbor bude slúžiť len ako vizualizácia, ktorá sa nedá ďalej použiť na právne účely.
výhodou PDF formátu je, že existuje kvantum aplikácií na jeho zobrazovanie a extrakcia dát nie je až tak zložitá, prílohy sa dajú triviálne vyextrahovať

p. Chajdiak:

podľa neho je potrebné zamerať sa na zjednodušenie výstupu úradov voči občanom,
v prípade vytváraných rozhodnutí OVM, kde sú adresátmi občania alebo PO je, legitímne očakávať, aby im boli zasielané údaje vo forme PDF súboru, avšak XML údaje sú podľa neho v takom prípade zároveň zbytočné
v prípade podaní vytváraných občanmi alebo PO pre OVM (či už štruktúrovaných na formulároch z modulu elektronických formulárov alebo neštruktúrovaných s použitím všeobecnej agendy ako „obálky" kde sa pripojí PDF súbor), OVM ako adresát nepotrebuje dostať PDF súbor, pretože má (v prípade štruktúrovaného podania) systém na vizualizáciu, ktorá mu údaje zobrazí a zároveň poskytnuté informácie súvisiace s overovaním podpisov, atď., (v prípade neštruktúrovaného podania príde PDF súbor, ktorý je podpísaný a použitý formulár ani nemusí byť podpísaný lebo nemá žiaden obsah) a
položil otázku aký bude prínos použitia prenosu XML údajov prostredníctvom PDF formátu, ktoré v konečnom dôsledku budú „zaberať miesto" aj v cieľových systémoch, a či bude existovať dostatočné kvantifikované množstvo používateľov ktorí si budú potrebovať ďalej stiahnuť svoje autorizované podanie v PDF súbore, aby bolo ďalej použiteľné na právne účely, pretože právny úkon sa urobil tým, že sa a odoslal. Občana môže zaujímať je až rozhodnutie ktoré mu ako odpoveď na podanie príde. Ak aj občan urobí neštruktúrované podanie napíše si ho vo worde a následne v PDF tak či si to vie zautorizovať a môže si ho stiahnuť.

p. Kováčik:

má zmysel, aby občan dostal to rozhodnutie ktoré sa mu „lepšie číta" (teda vo formáte PDF), a s ktorým vie ďalej pracovať, a zároveň nevidí problém, aby OVM k nemu „pribalil" XML dáta,
cieľom je v prvom rade elektronizácia, tak pre občana (aby podania mohli byť robené z „obývačky") ale aj zjednodušenie práce a zefektívnenie práce pre OVM, ktoré sa však týmto návrhom stavia do úzadia,
odporúča MIRRI SR prehodnotiť predložený návrh, keďže podľa jeho názoru neprináša benefity,
upozorni, že sa navrhovaným riešením zablokuje použitie iných podpisovačov,
navrhol spoplatnenie všeobecnej agendy - neštruktúrovaného podania stopercentnou sadzbou poplatku.

Predseda PS 4:

pre podpisovanie na ÚPVS nie je nevyhnuté použitie konkrétneho podpisovača, bude vytváraný štandardný PAdES. Ako bolo prezentované v návrhu, PDF sa spojí s XML údajmi (pri použití prvého variantu) formou pečate MIRRI SR a následne je možné podpisovať v ľubovoľnom podpisovači podporujúcom PAdES.
Podanie bude zapečatené pečaťou MIRRI SR práve preto, aby boli údaje XML a PDF spojené, a aby nevznikla pochybnosť, že je podpísané niečo iné ako má byť. Pri použití navrhovaného riešenia nebude môcť požívateľ podpísať čokoľvek, a ak tam nebude pečať MIRRI nebude korektne vytvorené podanie.

p. Illek:

pripomenul, že to čo hovoril p. Rybár a p. Kováčik sú naozaj dlhodobo neriešené problémy a je pravda, že NASES prišiel s PDF riešením mimo systému a rozhodne je za to aby sa najskôr vyriešili problémy starých formulárov a XMLDatacontainerov,
pokiaľ ide o použitie formulárov navrhol vyriešiť tento problém nejakým systematickým variantom, a neuzavrieť to definitívne výberom len jednej z navrhovaných možností,
upresnil, že povinnosť použiť štruktúrovane podanie (iba prostredníctvom formulára pre daný typ podania) je povinné len vtedy keď je to uvedené v osobitnom predpise (napr. podania voči finančnej správe) a tam, kde je to uvedené len všeobecne je možné vytvoriť neštruktúrované podanie pomocou všeobecnej agendy a to je zrelé na myšlienku čo s tým ďalej, keďže až 30% podaní sa takto využíva.

p. Kevický:

doplnil, že k celej tejto problematike mu chýbajú úvodné vstupy a na pripomienkovanie či prípadné odsúhlasenie sú podľa neho predkladané len parciálne materiály,
podľa neho sa ťažko k tomu vyjadruje, keď vidí len izolovanú časť a chýba mu kontext.

Predseda PS 4:

opätovne zdôraznil, že celkové zdôvodnenie návrhu použitia PDF pre prenos XML údajov bolo opakovane predkladané a prezentované na PS v roku 2022 a 2023, avšak potvrdil, že bude zaslaný členom zosumarizovaný dokument,
uviedol, že použitie PDF pre prenos XML údajov je v slovenskom eGovernmente nové technické riešenie, ktoré nebude povinné a bude preverené praxou. Momentálne je potrebné v pracovných skupinách iba zvoliť vhodnejší z variantov.
informoval, že bude spustené informatívne hlasovanie pre výber variantu.

K bodu 3: Novela vyhlášky k zaručenej konverzii

Predseda PS 4 odprezentoval navrhované zmeny vyhlášky o zaručenej konverzii.

1.Konverzia podpisových kontajnerov so zachovaním pôvodného formátu dokumentu

Vzhľadom na pripomienky členov pracovných skupín bola do návrhu zapracovaná možnosť vykonávať zaručenú konverziu podpisových kontajnerov so zachovaním pôvodného formátu dokumentu, ak sa na tom žiadateľ s osobou vykonávajúcou konverziu dohodnú. Pôvodný návrh počítal so zachovaním formátu len v prípade podpisov a formátov dokumentov vytvorených podľa pôvodnej legislatívy (Vyhlášky NBÚ č. 135/2009 Z. z. a 136/2009 Z.z.), pričom bol na základe pripomienok rozšírený na všetky formáty. Osoba vykonávajúca konverziu by však mala žiadateľa informovať, že takýto dokument nie sú orgány verejnej moci povinné prijímať a ani oprávnené vytvárať v rámci elektronickej úradnej komunikácie.

2. Vytváranie osvedčovacej doložky v elektronickej podobe vo formáte PDF a jej spojenie s novovzniknutým elektronickým dokumentom do jedného PDF súboru podpísaného s PAdES

Osoby vykonávajúce zaručenú konverziu budú mať nepovinnú možnosť poskytovať pri zaručenej konverzii pôvodného dokumentu do elektronickej podoby vytvárať osvedčovaciu doložku spojenú s novovzniknutým dokumentom do jedného PDF súboru podpísaného podpisom vo formáte PAdES. XML údaje osvedčovacej doložky budú vložené v PDF súbore ako PDF attachment podľa technického návrhu prezentovaného v bode dnešného zasadnutia. Orgány verejnej moci, ktoré majú implementované informačné systémy automaticky kontrolujúce obsah osvedčovacej doložky voči centrálnej evidencii záznamov o vykonanej zaručenej konverzii, budú potrebovať úpravu systému tak, aby boli pripravené získavať XML údaje z prílohy vloženej v PDF súbore. Na tento účel bude NASES poskytovať službu.

3. Zaručená konverzia vnorených podpisových kontajnerov

Predseda PS 4 informoval, že na predošlých zasadnutiach boli zo strany členov pracovných skupín prezentované názory za nepovinnosť zaručenej konverzie vnorených kontajnerov ako aj za zachovanie tejto povinnosti. Otázkou na členov pracovných skupín je, či osoby vykonávajúce konverziu majú povinne konvertovať vnorené kontajnery alebo budú mať za povinnosť informovať žiadateľa, že vnorené kontajnery nepodporujú a v prípade záujmu o ich konverziu musí ísť hľadať inú osobu vykonávajúcu konverziu, ktorá takúto konverziu vnorených kontajnerov podporuje a vykonáva. V praxi sa vnorené kontajnery vyskytujú odhadom v menej ako 0,1% prípadov, keďže podľa informácií z NASES sa takéto prípady takmer nevyskytujú, preto je otázkou, či má byť ich konverzia plošne podporovaná. Taktiež v zmysle vyhlášky o štandardoch orgány riadenia spravidla nemajú vytvárať vnorené podpisové kontajnery, aj keď existujú špecifické prípady, kedy sa tomu nedá vyhnúť – napríklad ak je dokument podpísaný s PAdES a niektorý z podpisovateľov nemôže použiť tento formát podpisu a zahrnie dokument do ASiC. Podobne boli prípady, kedy boli rozhodnutia v minulosti vytvárané s podpisom PAdES a následne doložka právoplatnosti vyplnená podľa formulára bola vyznačovaná ako XML dokument spoločne autorizovaný s týmto PDF súborom podpísaným s PAdES podpisom.
p. Rybár:
Zopakoval svoj návrh z predchádzajúceho zasadnutia, aby v prípade vnorených kontajnerov žiadateľ o vykonanie zaručenej konverzie mohol určiť, ktorý konkrétny podpis má byť zaručene konvertovaný. Pri validácii sa vždy validuje konkrétny podpis, preto validačné služby nemajú dôvod validovať naraz všetky vnorené podpisové kontajnery. Je potrebné, aby výrobcovia aplikácií pre zaručenú konverziu vnorených podpisov využili služby validácie, ktoré umožňujú určiť aj dátum a čas, ku ktorému sa má podpis bez pripojenej časovej pečiatky validovať, pričom tento údaj je možné zistiť z príslušnej kvalifikovanej časovej pečiatky z nadradeného kontajnera resp. podpisu. NASES poskytuje existujúcu kvalifikovanú službu validácie SNCA, ktorá umožňuje uviesť dátum a čas, ku ktorému sa má daný podpis validovať, ak tento podpis nemá pripojenú časovú pečiatku. Nevidí preto závažný problém s implementáciou konverzie vnorených kontajnerov. Nepovažuje za vhodné, aby sa kvôli odmietaniu zo strany niektorých dodávateľov nevykonávala konverzia vnorených kontajnerov.
p. Kováčik:

Pri práci s dokumentami je potrebné poznať informáciu o všetkých podpisoch resp. bezpečnostných prvkoch, nie iba o určenom podpise.
Predseda PS 4:

V prípade zaručenej konverzie určeného podpisu z vnorených kontajnerov sú v princípe potrebné rovnaké technické funkcie ako pri konverzii všetkých. Taktiež by mohlo byť pre klienta zložité zo štruktúry podpisov určiť, ktorý konkrétny podpis chce konvertovať. Zároveň zákon o eGovernmente vyžaduje pri zaručenej konverzii zachovať informácie o všetkých bezpečnostných prvkoch, nie iba o určených.
Preto je potrebné prijať záver, či má byť konverzia vnorených kontajnerov povinná alebo nepovinná. O tejto otázke bude spustené aj dištančné hlasovanie.
Povinnosť konverzie vnorených kontajnerov v súčasnosti vyplýva z vyhlášky o zaručenej konverzii ako aj z odkazu na § 47 Vyhlášky č. 78/2020 Z.z. o štandardoch.

4. Definovanie formátov a legislatívnych typov podpisov

V praxi existujú rôzne formáty podpisov a v podpisoch sa používajú aj nekvalifikované certifikáty, ktoré validačné služby nevedia plne vyhodnotiť.
Vyhláška o zaručenej konverzii odkazuje na § 47 Vyhlášky o štandardoch, v ktorom sú uvedené formáty, ktoré je povinnosťou zaručene konvertovať.
Navrhuje sa zvážiť posudzovanie bezpečnostných záruk v prípade nekvalifikovaných certifikátov.

Predseda PS 4 uviedol, že návrhy budú zaslané na dištančné hlasovanie

K bodu 4: Informácia k návrhu technického riešenia Autorizácie odoslaním podania s opätovnou autentifikáciou v súlade s § 23 ods. 1 písm. a) bod 2 zákona č. 305/2013 Z. z. o eGovernmente a návrh na úpravu § 48 ods. 2 až 6 vyhlášky č. 78/2020 Z. z. o štandardoch pre ITVS

Predseda PS 4 informoval, že aktuálne prebieha dokončovanie návrhu riešenia autorizácie odoslaním podania s opätovnou autentifikáciou na strane MIRRI. MIRRI v súčasnosti preferuje riešenie, kedy bude pri odosielaní po opätovnej autentifikácii podávajúceho automaticky samostatne zapečatený každý objekt správy, vrátane informácie o spôsobe autorizácie. Z tohto dôvodu by bolo potrebné upraviť vyhlášku o štandardoch. Upravený návrh bude predložený na nasledujúcom zasadnutí PS2 a PS4 začiatkom augusta. Návrh bol taktiež predložený na nacenenie dodávateľom ÚPVS a centrálnych komponentov.

K bodu 5: Informácia k návrhu pre autentifikáciu aplikácií prostredníctvom API gateway v spojení s HTTPS a REST: TLS autentifikácia v kombinácii s Basic autentifikáciou, APIKey – Shared Secret, OAuth2 s OpenIDConnect s JWT tokenom (návrh na doplnenie § 11 vyhlášky ÚPVII č. 78/2020 Z. z.)

Predseda PS 4 poďakoval členom za zaslané pripomienky k detailnému návrhu riešenia k autentifikácii prostredníctvom API gateway. Informoval, že aktuálne prebieha zapracovanie pripomienok na strane Slovensko IT v súčinnosti s MIRRI. Návrh na úpravu štandardov bude po zapracovaní pripomienok predložený do pracovných skupín.

K bodu 6: Rôzne

Neboli vznesené žiadne návrhy.

K bodu 8: Záver zasadnutia

Predseda PS 4 poďakoval za účasť na tomto zasadnutí a aktívne pripomienky. Ďalšie zasadnutie sa predpokladá začiatkom augusta 2023.
V Bratislave dňa 17. 07. 2023