Zákon o e-Gov - novela 2017

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 ?

@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…

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

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…

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

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

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

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é.

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

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.

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

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?

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.

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

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ť.

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

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.

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.

Ano mas pravdu, ja som to myslel tak ze kedze komunikacia je obcan<>uradnik, ze by ta transformacia formulara ako ho vidi vyplnujuci by mala byt brana ako zaklad. Tym mame poriesene zmysly ludi co sa podielaju na danej veci. A ostatne transformacie su potom vynikajuca vec, ktory moze pri automatizacii procesov napomahat - spolu s datami v xml - cize vyborna vec, ale kedze ide nie o uctovne transakcie ani vyrobne ale hlavne o komunikaciu ludi (ktoru mozno pomocou xml dat a transformacii roznymi sposobmi automatitzovat), amla by mat ta transformacia do html byt ako hlavna metoda, ktora by mohla vyhovovat aj z pohladu dlhodobejsej uschovy - samozrejme po eliminacii rizik vid. nizsie

presne tak. Mnoho veci sa da teraz doladit, ale aj vylepsit a doplnit ale nemalo by to vytvarat dalsi problem iba vyriesit stavajuci, alebo pridat neexistujucu funkcionalitu. Trochu som mal obavy - nepoznam presne o co ide ale ta transformacia ma trochu inspirovala k prispevku. V implementacii podpisu trochu zanikli kedysi dost zname uskalia, ktore su dnes iba poznamkou v technickej norme, a bolo by dobre aby sme sa im vyhli pri praci s formularmi a hned sa znizia rizika do buducnosti. Napr. poznamka k 4.2.3 podp. dokument.
http://www.etsi.org/deliver/etsi_ts/119100_119199/11910201/01.00.01_60/ts_11910201v010001p.pdf
ale aj reprezentacia miesto podpisovaneho dokumentu moze mat svoje uskalia a preto ich by bolo najlepsie preklenut podobne ako u formularov qsign tym ze sa transformacia urcena pre cloveka vlozi a podpise spolu s datami.

nemal som cas presne rozpytvat a dokumentacia hovori o referencii. Ale nech je to ako chce. Zakazdym to ma riziiko. Ak je to hash tej transformacie, ktorou som zobrazoval pri podpise, tak tym ze xsl pre formulare su bud v softveri, alebo v inom systeme-upvs, moze nastat situacia:
podpises dokument. On hash transformacneho xslt vlozi ako podpisanu polozku. Niekto medzi tym zmeni v transformacnom subore napr. nejaku len medzeru tam prida cim sa zmeni jeho hash. a problem je na svete. Overovaci softver si vo svojej kniznici drzi xslt subor bud uz ho tam ma, alebo si ho pred prvym overenim stiahnes, takze stiahnes ten zmeneny xslt, softver ti pekne overi aj zobrazi, ale das mu overit ten isty formular zo vcerajska kedy este nebol zmeny xslt a tam uz bude problem lebo podpisany hash tranf. suboru by bol iny. Ale ak je to tak ze je tam - v podpisanom objekt co ma URI ktore co priamo neukazuje na nic fyzicky konkretneho, http://schemas.gov.sk/form/App.GeneralAgenda/1.9/form.xslt tak je to odkazovanie sa pre zobrazovaciu cast kamsi do sveta a cokolvek co sa bude tvarit ako spravny xslt sa bude dat pouzit. A teoreticky sa daju obe moznosti skombinoavat. Zakazdym tam bude nejake male riziiko.
Ale toto spolu s tym ze v kniznici formularov neni napr. ani taka evidencia, ze ku kazdemu suboru je evidovany jeho hash aby si system ktory chce zobrazit mohol overit neposkodenost xslt vytvara predpoklady na to, ze ked si stiahnes formular do svojho pc cize mimo schranky a budes ho mat par rokov tak sa da podstrcit xslt, a rozne ine veci ktore by bolo dobre nejak teraz zacat obmedzovat. Napr. ani nedavat moznost v dokumentacii integrujucemu vyvojarovi aby si vyberal ci podpis chce urobit v takom alebo onakom formate. Jednoducho predpisat proceduru, hodnoty parametrov a toto bud budes pouzivat alebo ti podpis neprejde.

Nie vyplnacia ale ze nebudu prezentacne data toto: mozno som ale nepochopil co sa tymi prezenztacnymi datami rozumie. Ako som pozdejsie zistil netusim totiz co sa mysli "pre prístupové miesto zo špecializovaného portálu,“
7. K čl. I
V čl. I sa za bod 38 vkladajú nové body 39 a 40, ktoré znejú:
„39. V § 24 ods. 2 písm. a) sa na konci vkladá bodkočiarka a pripájajú sa slová „prezentačná schéma nemusí byť súčasťou elektronického formulára, ak je používateľské rozhranie pre vyplnenie elektronického formulára poskytované pre prístupové miesto zo špecializovaného portálu,“.

Len stručne, citát z Výnosu o štandardoch:

“3.1.9 Miesto publikovania elektronického formulára zabezpečuje integritu elektronického formulára vrátane integrity s ním súvisiacich údajov, súborov a dokumentov.”

Čo sa týka hashu / digitálneho odtlačku transformácie:

  • Starý slovenský formát podpisov XAdES_ZEP v prípade podpisovania XML obsahuje digitálny odtlačok podpisovej prezentačnej schémy ako súčasť podpisu. (XAdES_ZEP sa však už musí prestať vytvárať a je potrebné vytvárať eIDAS formáty.)
  • Pri nových formátoch podpisov predpísaných eIDAS sa digitálny odtlačok podpisovej prezentančnej schémy neuvádza ako súčasť podpisu ale ako súčasť podpisovaného súboru. Na tento účel je predpísaná štruktúra XMLDataContainer.

XML údaje sa podľa Výnosu o štandardoch pre IS VS musia podpisovať vložené vo formáte XMLDataContainer, ktorý sa podpisuje ako celok a v prípade e-formulárov povinne obsahuje referencie XSLT a XSD, pričom pre každú referenciu povinne obsahuje aj DigestMethod a DigestValue. Viď príloha č.11 Výnosu o štandardoch.
Zatiaľ v praxi prevláda starý formát XAdES_ZEP (.xzep, .zepx), situácia by sa mala postupne zmeniť v priebehu pár ďalších mesiacov, kedy budú na ÚPVS nasadené povinné formáty podľa legislatívy.