Zákon o e-Gov - novela 2017

Čo sa deje v e-Governmente Transparentnosť a participácia
163

Všimnite si, kto na tej hromadnej pripomienke je prvý zástupca verejnosti. :wink:

@anton.janos nemáš pravdu. Momentálne sa zákon o e-Gov nevzťahuje na celé konania, ktorými sa sprístupňujú informácie podľa z.211/2000. Čiže aj vydanie rozhodnutia v tomto konaní sa spraví papierovo.

V čase písania hromadnej pripomienky skrátka prevládol postoj, že fungujúcu elektronickú komunikáciu (infožiadosti emailom) treba čo najlepšie izolovať od “e-Gov” vecí, či už v zákone, alebo technicky, keďže vládla všeobecná skepsa ku el. schránkam, el. formulárom, ZEPu atď. Nie že by sa odvtedy nálada či implementácia podstatne zmenila…

Každopádne v práve prebiehajúcej novele sa táto vec mení:
Čl I. bod2.: V § 2 ods. 2 písm. g) sa slová „sprístupňovanie informácií na základe žiadosti“ nahrádzajú slovami „podávanie a vybavovanie žiadostí o sprístupnenie informácií podľa osobitného predpisu,4a) okrem postúpenia žiadosti a vydania rozhodnutia, ktoré sa doručuje žiadateľovi“.

Odpovede teda pôjdu do el. schránky u toho, kto ju má aktivovanú.

164

No neviem. Tá nová formulácia mi je ešte viac nezrozumitelna, ako tá stará. A tu starú si obce vyložili opačne, ako bola myslená. Čiže tak, že ak im pride infoziadost do schránky, tak majú oporu v zákone, a môžu ju spokojne ignorovať.

165

Obec samozrejme vydala rozhodnutie (že na základe písmená g sa mojou infoziadostou nebude zaoberať) a toto mi poslala do schránky. Dobré nie ?

166

@Lubor nechapem v com nemam pravdu :slight_smile:
pamatam si debatu k tomuto, pretoze ja som navrhol toto pismeno precizovat prave kvoli tym spornym vykladom, aby bolo jasne, ze ziadost a odpoved nie je nevyhnutne posielat cez eDesk …rozhodnutie o odmietnuti a postupenie ano…
@robert.kuchar vsak zbytocne posiela ziadost cez eDesk, ked mohol mailom…to vsak neznamena, ze obec nemusela odpovedat vobec…

167

Spoločná správa z výborov NRSR s návrhmi zmien novely do 2. čítania:
Spoločná správa VSRR tlač 564.rtf (241.6 KB)

Na prvé prečítanie ma zaujala najmä rozsiahla zmena k autentifikačným certifikátom (bod 5 správy), o ktorých doteraz nebola reč. Tuším problémy.

A ešte jeden pozmeňovací návrh, od koalície: http://www.nrsr.sk/web/Dynamic/Download.aspx?DocID=442498

Podľa webu NRSR je pravdepodobné, že 2. čítanie bude už zajtra (6.9.)

1 Like
168

Fuu,
“Navrhovaná zmena má za cieľ umožniť vytváranie elektronických formulárov dvomi spôsobmi. Dnes existujúca cesta (pomocou vyplňovacej časti v rámci formulárov) by zostala naďalej zákonnou možnosťou a existujúce formuláre by sa nemuseli prerábať. Na druhej strane by ale zákon otvoril možnosť publikovať do prístupových miest zadávacie časti aj iným spôsobom, ktorý musí gestor služby podriadiť metodickým…”

Zda sa ze formulare upvs zacinaju byt pre niekoho nedokonale. Len skoda ze sa do tejto technologie invenstovalo a ze sa to nezohladnilo ked sa tento sposob zavadzal. Uz teraz je stav taky, ze nikto nikdy uz neuvidi vyplneny formular tak ako ho videl podpisujuci vo chvili ked ho podpisoval. Tak dufajme ze toto novatorstvo bude v tomto smere prinosom…

169

No ale toto čo si napísal som v spolocnej správe nenasiel.

170

Pán je zrejme diplomat. Rád sa stretnem s niekým, kto je presvedčený že el. form. ako sú teraz sú dokonalé.
Táto zmena pre el. formuláre bola zo strany ÚPVII avizovaná a aj tu na platforme je k formulárom búrlivá diskusia (tu a nasledujúcich 20 príspevkov).

A to prečo? Veď pred podpisom sa má použiť tá istá vizualizačná transformácia ako následne pri používaní podpísaného formulára.

Hľadaj o level bližšie, v novele (návrhy zmien zákona), nie v spoločnej správe výborov (návrh zmien novely = návrh zmien zmien zákona).
Ináč počas rozpravy k 2. čítaniu sa môže navrhnúť aj zmena ku spoločnej správe, to potom bude návrh zmien zmien zmien zákona. :sweat:

1 Like
171

Spoločná správa výborov neobsahuje nič o vzťahu eGov zákona k infozákonu preto, lebo Výbory NR SR k tejto téme nenavrhujú nič meniť a teda ponechávajú znenie ako bolo do NR SR predložené.

Čiže treba si pozrieť samotný návrh novely:
http://www.nrsr.sk/web/Dynamic/Download.aspx?DocID=439314

Prípadne všetky súvisiace dokumenty parlamentnej tlače 564:
http://www.nrsr.sk/web/Default.aspx?sid=zakony/zakon&ZakZborID=13&CisObdobia=7&CPT=564

172

Tiež nerozumiem obavám miromr, aj keď si viem potenciálne predstaviť že by nejaký OVM vypublikoval e-formulár s nevhodnou podpisovou prezentačnou schémou.
Nie je však pravda, že sa pri používaní podpísaných údajov vyplnených podľa e-formulára musí použiť tá istá vizuálna transformácia ako pred podpisom. Môže sa používať hociktorá z prezentačných schém vypublikovaných v danom e-formulári.

Citát z Výnosu o štandardoch pre IS VS č. 55/2014 Z.z.:

6.3.2 Pri prijímaní a spracovaní vyplnených údajov elektronického formulára je možné použiť ktorúkoľvek z prezentácií zdokumentovaných v publikovanom elektronickom formulári podľa bodov 2.6.5 až 2.6.7, pričom nie je potrebné použiť prezentáciu použitú pri podpisovaní vyplnených údajov elektronického formulára.
6.3.3 Pri prijímaní a spracovaní vyplnených údajov elektronického formulára podpísaných elektronickým podpisom sa kontroluje, či kontajner pre XML údaje podľa prílohy č. 11 obsahuje referenciu podpisovej prezentácie zdokumentovanej v publikovanom elektronickom formulári podľa bodu 2.6.7. Jej transformovanie do prezentácie pri overovaní podpisu nie je potrebné.

173

Áno, to je presné. Je na tvorcovi formulára, aby všetky dávali rovnaký zmysel.

174

Presiel som vsetky navrhy spravy a zajtra rano sem hodim pripomienky k jednotlivym bodom, nateraz len letecky pohlad:

  • niektore navrhy su dost “mimo” (5.),
  • niektore si protirecia s odovodnenim (38.),
  • niektore su nezrozumitelne (28.),
  • niektore sa opakuju (nasesu sa opat niekto snazi umoznit vyzadovat nim predpisany format AC (bod 18.))
  • a niektore su fakt zbytocne (34.).

Mam pocit, ze navrhy ohladne uhrad, platieb, resp poplatkov pisalo MV a Posta, pretoze vsetko sa toci okolo eKolku a jedneho IOM, prevadzkovaneho MV, ako keby ine IOM neexistovali.

175

V pozmeňujúcich návrhoch do 2. čítania novely zákon o e-Gov máme za S.D zásadný problém s bodom 5 spoločnej správy výborov NRSR, ktorým sa mení §22b zákona. Ide o autentifikačné certifikáty. Žiadame tento bod vybrať zo spoločného hlasovania o pozmeňujúcich návrhoch a neschváliť.

Dôvody prečo tento bod neschvaľovať:

  1. Táto zmena sa do pozmeňujúcich návrhov dostala bez toho, aby bola akokoľvek diskutovaná alebo prezentovaná. Doteraz v celom štandardom procese - pracovné skupiny ÚPPVII, MPK, rozporové konania, diskusia v Komisii pre technologický rozvoj NRSR - nebola táto oblasť ani raz identifikovaná a diskutovaná. Pritom ide o detailné technické zmeny, t.j. žiadne politické, či strategické rozhodnutia. Takéto zmeny si veľmi vyžadujú dostatočné odborné prediskutovanie a posúdenie. V tomto prípade naopak, zmena sa dostala do novely úplne na poslednú chvíľu.

  2. Celá oblasť autentifikácie (kam autentifikačné certifikáty patria) sa má riešiť komplexne v ďalšej nasledujúcej novele. Aj my a ďalšie subjekty sme navrhovali rôzne zmeny v tejto oblasti, ale v rámci rozporového konania nám ÚPPVII všetky zamietol s tým, že teda v ďalšej novele. Robiť teraz partikulárne zmeny pre autentifikačné certifikáty, a v ďalšej novele sa to opäť bude meniť, je najmä neefektívne a je to porušenie dohody z rozporových konaní.

  3. Toto novo navrhované znenie je vo viacerých veciach škodlivé. Jedna z najhorších zmien je povinnosť podať žiadosť o autentifikačný certifikát výlučne elektronicky. Veď tieto certifikáty sú určené aj práve pre tie subjekty, ktoré nemajú eID, nemajú ZEP atď., a teraz majú práveže sa povinne prihlásiť do schránky a podpisovať ZEPom. Rovnako aj generálny mechanizmus pre podania v zákone je umožniť podávajúcej osobe vybrať si, či chce použiť elektronickú, alebo listinnú formu. Sú tam aj ďalšie pochybné zmeny (napr. celá konštrukcia zverejňovania zoznamu platného na 24hod, pričom je povinnosť v ňom robiť okamžité zmeny, alebo oznamovanie “zrušenia” certifikátu mimo toho čo je vedené v registri …).

  4. Zmeny navrhované v tomto bode nie sú v žiadnom prípade momentálne nevyhnutné, alebo prioritné. NASES už roky funguje vo vzťahu k autentifikačným certifikátom určitým spôsobom a doteraz mu aktuálne znenie zákona nijako neprekážalo. Nevidíme žiadny akútny dôvod na zmenu práve teraz. Ani ostatné veci z novely zákona o e-Gov nie sú na tejto zmene závislé.

Podľa nás nie je teraz čas na “opravovanie” znenia v strese. Preto za správne riešenie pokladáme tento bod neschváliť a do ďalšej novely to pripraviť poriadne.
Všetky ostatné navrhované zmeny do 2. čítania sme s ÚPPVII vopred prebrali a nemáme s nimi problém.

Zhruba takéto ^ stanovisko som poslal aj na ÚPPVII.

4 Likes
176

Je to na dlhsiu debatu. Problem vidim v tom, ze ide o podania a rozhodnutia - teda nie o nejaku okamzitu transakciu dvoch vyrobnych systemov. Podanie ako aj rozhodnutie je v prvom rade dokument urceny pre cloveka. To ze data.xml mozno prezentovat roznym sposobom je ohromna vyhoda najma pre strojove spracovanie, ale pre tych dvoch co komunikuju teda obcan - vybavujuci uradnik je potrebna forma ktora zodpoveda ich zmyslom najma zraku. To ze to je rozhodnutie a podanie ma vplyv aj na to ze sa nejedna o dokumenty, ktore zariadia nejaku transakciu a stavaju sa nepotrebnymi. Take rozhodnutie ma urcitu lehotu ulozenia v registraturnom systeme. Ale treba ratat aj s tym ze nez zacne bezat lehota ulozenia dokument moze v stave “tzv. zivy dokument” stravit aj niekolko desiatok rokov a potom az zacne bezat lehota ulozenia napr. 5-10 ci viac rokov. My generujeme dokumenty este len chvilu a uz robime taketo zmeny. Lenze aj vyvojari co pridu po nas budu chciet nieco “vylepsovat” a to ked si zvykneme robit iba preto ze sa niekomu nieco lepsie urobi tak za 50 rokov budeme sa na to divat tak ze pozor toto je formular ktory sa robil od roku do roku, tento zase musis spracovavat inak ten sa zase robil v rokoch xy, a tento co ma taketo odlisnosti zase vtedy. Cize tieto veci sa mali zohladnit uz na samom zaciatku a pouzit format taky ktory je urceny resp. prisposobitelny dlhodobym podmienkam.
Mozno vycitis co ma trapi ak pospisem sucasny stav asi ako je (ospravdlnujem sa za dlhsi prispevok)
Cloviecik v Ciernej nad Tisou ide podat podanie. Vyplni formular a stlaci tlacidlo skontrolovat. System mu oznami ze ho ma v poriadku. Tak je spokojny a stlaci tlacidlo Podpisat. Teraz sa vykona skript, ktory nim vyplnene udaje zoberie a prepise ich do XML suboru - on o tom nevie ze bezi skript, kde vinou napr. chyby kodu ci zlym umyslom data mozu byt zmenene, on si stale mysli ze podpisuje to co vidi. No ale teraz perlicka - XML subor sa posiela cez celu republiku do Bratislavy aby ho tam prebalili do ineho xml suboru, ktory je vhodny pre podpisovanie. Cize cesta tam, cesta spat a procedura na serveri, su tri miesta, kde mohli byt ci chybou alebo zlym umyslom data zmenene. Cloviecik si stale mysli ze podpisuje to co vidi.
Az teraz su data poskytnute certifikovanemu softveru, kde ale prebehne transformacia do prosteho textu a data su uzivatelovi zobrazene v D.Signeri ale formou, ktora je jeho zmyslom, najma zraku uz nie taka privetiva ako ked formular vypisoval. Tam boli udaje aspon v urcitych logickych celkoch, mali celkom dobru citatelnost a vnimatelnost teda aj skontrolovat sa dali lepsie. V tejto stromovej strukture ide skor o to aby to nezabilo systemove prostriedky, nez o to ze prave toto je to dolezite miesto, kde ma vyskocit velky cerveny vykricnik, ze teraz si poriadne skontroluj udaje lebo toto podpisujes-nie to co si vyplnil.
Na podpisovanie sa sice pouziva certifikovany podpisovaci softver, ale sposob jeho pouzitia v tejto aplikacii je minimalne diskutabilny. Ked uz to musi zasielat pred podpisom moje udaje cez kozmicku stanicu, tak by aspon bolo dobre uzivatela na tuto skutocnost upozornit, ze v d.signeri by mal poriadne skontrolovat ci to co mu system podstrcil na podpis je to iste co zadaval do formulara.

Podobne podpisovy softver je sice certifikovany ale sposob jeho aplikacie nezohladnuje rizika a uskalia, na ktore upozornuju medzinarodne technicke normy tykajuce sa vyhotovovania elektronickeho podpisu.
Medzi takte problemy patri o.i. najma skutocnost,ze vzhlad dokumentu nema byt zavisly na externom zdroji, teda na niecom co sa nachadza mimo dokumentu a nie je to nijak podpisom zaistene. No a nam sa tu stalo to ze nase podanie a rozhodnutie je vylozene zavisle na tom aka transformacne data pouzijem. Zopakujem ze toze si ho mozem pozriet roznymi sposobmi je vyborna moznost, ale v prvom rade musim zaistit to aby vzhlad dokumentu nebol zavisly na externom - nekontrolovanom obsahu, ktory neni podpisany.Samozrejme mozem miesto casti podpisovaneho dokumentu - napr. transforamcneho suboru pouzit jeho tzv. reprezentaciu, ale tou sa mysli napr. Hash, alebo skomprimovany transformacny subor a nie iba akysi logicky odkaz, ktory mi sluzi iba na to aby som urcil spravnu triedu, posp a verziu na ostatne xslt. Aj jked su transformacne udaje v centralnej kniznici formularov, neni nikde zaruka ze ich niekto zly niekedy nezmeni aby urobil inemu skodu. Registraturne systemy musia tiez aj po desiatkach rokov podpisane formulare spravne prezentovat, a tieto si budu zrejme transformacne udaje ukladat vo svojich databazach, a kedze nikde neexistuje zabezpecenie tychto transformacnych dat. A tu vidim problem lebo transformacne udaje sa daju lahucko zmenit. Ak mas cas skus si urobit transformaciu lubovolneho rozhodnutia napr. s xsl urcenym pre R/O prezreranie a do tohoto suboru do casti body si napis text napr. “Toto rozhodnutie nadbudne platnost až po zaplateni poplatku na ucet xy” a vykonaj transformaciu. Cize staci sa len zaysliet kam nas setrenie pameti pri podpisovani moze zaviet. A stacilo by jedno nedivat sa na podania a rozhodnutia ocami momentalnej potreby komunikacie dvoch systemov, ale zohladnit ze podanie aj rozhodnutie je vprvom rade pre cloveka.
No a preto som reagoval na dalsiu zmenu, kde sa zrejme chysta ze nebudu transformacne udaje k dispozicii tak ako som reagoval. takze pre Lubor- pan neni diplomat pan iba vidi ze s podpisom, pecatou a formularmi je akosi vela malickosti, ktore nam v buducnosti mozno vytvoria velky problem.

Dnes neni mozne dokument transformovat tak ako ho videl clovek co ho podpisoval- minimalne farebna schema je ina. Ak sa zavedie system ktroy neposkytne prezentacne data nebude to len dalsi problem v tomto smere? Najma ak sme nedostatky doteraz produkovanych rozhodnuti neodstranili?

177

Myslím, že u Ľubora asi neprerazíš s human readable dokumentmi, a rovnako ani u lídrov informatizácie na Slovensku. Samozrejme, že bude po 30 - 50 rokoch problém vydolovať správnu transformáciu napr. elektronického rozsudku v podobe ako ju podpisovateľ podpisoval, rovnako ako overiť pravosť pečate alebo podpisu.

178

Ku autentifikačným certifikátom, vznikla otázka, že čo je teda pre nás prekážka na znení ako je navrhnuté.

Tu dávam niekoľko téz k tomu, akým smerom by malo v skutočnosti uberať riešenie AC:

  • autentifikácia používateľa nemá byť riešená správcom prístupového miesta pre každú metódu (eID, AA, AC, eIDAS veci) samostatne, správca má skrátka volať službu spoločného modulu, ktorá zabezpečí čo treba a vráti výsledok prihlásený áno/nie, úroveň autentifikácie a ID subjektu

  • nie sú preto potrebné žiadne špecifické služby registra AC, ktoré majú správcovia prístupových miest používať

  • pri AC je irelevantné kto je „vydavateľ“, tento pojem ani nedáva veľký zmysel, technicky vytvoriť AC môže ktokoľvek, napr. samotný žiadateľ, alebo AC môže na základe žiadosti dokonca vytvárať Nases (pritom nepotrebuje žiadnu certifikačnú autoritu)

  • dôležitá je iba väzba medzi subjektom ktorý si AC nechal zaregistrovať – na to dokonca ani nie je potrebná prítomnosť identifikátora tejto osoby v AC, stačí že je vytvorené prepojenie v registri

  • nie je potrebná žiadna evidencia už neplatných certifikátov, pretože validita (použiteľnosť) AC na účely podľa zákona sa overuje jedine jeho prítomnosť v registri – ak v registri nie je, nie je možné ho použiť na autentifikáciu

  • ak bude službu autentifikácie zabezpečovať spoločný modul, nie je potrebné ani žiadne zverejňovanie zoznamu AC, v žiadnej forme

  • použitie AC, a celé OpenAPI nemá byť viazané na “integráciu”, má to byť otvorené riešenie, automaticky použiteľné pre každého (kto má zaregistrovaný AC, kto vie dané API volať atď.) - na štandardné hororové otázky, že “to by ľudia zneužívali” a “to by kapacitne nestíhalo” je odpoveď, že rovnako predsa funguje prístup k webu - web stránky si nechá zobraziť kto chce, koľko chce a dokonca anonymne, prístup k webu je v skutočnosti tiež iba prístup cez API, ktorým je HTTP

Zmeny, ktoré teraz Nases/ÚPVII navrhlo do zákona sú s týmto úplne v protiklade. Predpokladám že tak ako to navrhli “sa to dá implementovať”, aj vydať k tomu vyhláška atď., ale skrátka zatiaľ akoby sa nikto skutočne nezamyslel nad tým čo vlastne potrebujeme vo výslednom stave dosiahnuť.

1 Like
179

Lubor, ktoré konkrétne zmeny sú s vyššie uvedenými bodmi v protiklade? Povinnosť vydávať zoznam AC zaviedol zákon. Keďže je taká povinnosť, NASES sa pravdepodobne snaží viesť tento zoznam naozaj aktuálny (okrem toho, že obsah registra chce mať aktuálny, preto zavádza povinnosť oznamovať zrušenie platnosti AC). Ak si sám vygenerujem AC, tak som jeho vydavateľ. Takže každý AC má nejakého vydavateľa.

To že prístup prostredníctvom AC bude zakomponovaný do IAM nemá nič s publikáciou zoznamu platných AC (ktorú, ešte raz opakujem, zaviedol zákon), s oznamovaním ich zrušenia, … Predpokladám, že tak ako eIDAS, tak isto transparentne sa budú snažiť v NASES-e zakomponovať aj AC. IAM vydá token, ktorý sa môže použiť aj pre ďalšie systémy.

Ja sa priznám, že tam (v tej zmene zákona v časti ohľadom AC) nevidím ani jeden rozpor s bodmi, ktoré si v svojom poslednom poste uviedol. Skús to, prosim, rozpísať.

180

Zákon bol dnes v NSRS schválený, bod o AC nakoniec vypustili. To neznamená že by sme “vyhrali”, ale že teraz môže prebehnúť normálna debata na čo vlastne AC sú a ako majú fungovať.

3 Likes
181

Povedzme si otvorene: žiadny elektronický dokument nie je priamo zrakom čitateľný. Každý dokument - aj obyčajný .txt - musí byť dekódovaný a zobrazený príslušným softvérom.

Áno, je jasné, že štát má povinnosť dlhodobo zabezpečovať možnosť prečítať dokumenty ktoré vydal, alebo prijal. Ak si štát vytvoril vlastný formát pre el. formuláre, je tu na minimálne tých 70 rokov (cca. tri ľudské generácie) pre neho povinnosť zabezpečiť všeobecne použiteľný nástroj na jeho zobrazovanie a naveky povinnosť zabezpečiť možnosť zobraziť/konvertovať ho v kontrolovaných podmienkach (v štátnom archíve). Toto verím že dávne štúdie uskutočniteľnosti zvážili, spočítali a vyšlo im že sa oplatí. :sunglasses:

Podobnú kalkuláciu treba spraviť pri každej zmene formátov, ktorá narušuje spätnú kompatibilitu. Asi však nikto nespochybňuje, že niekedy zmenu spraviť treba. Povedzme raz za IT generáciu? (10-15 rokov) Plus teraz na začiatku proste vychytávame detské problémy, nuž to je skrátka nevyhnutnosť pri testovaní plošným rolloutom.

V tomto máš úplnú pravdu. Je to zle.
Už rozumiem ako si to myslel že človek nevidi čo podpisuje.

Toto je samozrejmá požiadavka.
Ale veď súčasťou podpisu je aj hash transformácie. @stefan.szilva potvrď.

A to je ktorá z tých zmien? Že vypĺňacia funkčnosť nemusí byť na ÚPVS? To je predsa v pohode.
Ako si správne napísal, človek si má podanie skontrolovať pri podpisovaní. Tam sa mu to má správne zobraziť a varovať ho že robí vážny krok.

182

Jano, aj súčasné znenie k AC v zákone nie je dobré. V čom by sa to ešte “zhoršilo”, len tak narýchlo:
-ods.2: implementovala by sa funkčnosť na večné pamätanie zrušených certifikátov = zbytočná investícia
-ods.3: zavádza sa nová povinnosť pre “vydavateľa certifikátu”, niečo niekam oznamovať
-ods.4: žiadosť nemôže byť daná listinne, čo dnes robí väčšina používateľov - časť z nich nemá eID, ZEP
-ods.5: implementuje sa zbytočná služba overovania platnosti certifikátu, plus správcovia prístupových miest budú tlačení aby to používali
Ale skrátka keď sa to ide riešiť (a pokiaľ viem, v Nasese majú pripravenú špecifikáciu ako celé AC implementovať), tak treba spraviť správne riešenie. To čo je dnes v zákone tiež nie je dobré, roky to už nefunguje. Dajme si čas navrhnúť to poriadne. Ďalšia novela môže ísť povedzme vo februári.