Podpisovanie OpenData?

Presúvam sem diskusiu k téme podpisovania datasetov, keďže môže zaujímať aj ďalších ľudí.
@hanecak @Lubor @msurek @liska

Chcem sa spýtať, či je vhodné zverejňovať datasety s otvorenými údajmi vo formáte ASiC - t.j. ako ZIP súbor s príponou .asics / .asice obsahujúci otvorené údaje a elektronický podpis v predpísanej štruktúre.
Napríklad bude zverejňovaný dataset vo formáte CSV alebo XML a tento bude podpísaný - t.j. v zmysle štandardov bude zverejnený ako ASiC súbor.
Účelom by mohlo byť napríklad zverejňovanie zoznamov používaných pri podpisovaní - napríklad zoznamy e-formulárov spolu s hashmi súborov, zoznamy certifikátov a podobne.
Pýtam sa aj preto, lebo na podpisovanie XML súborov sa dnes vyžaduje XMLDataContainer a v roku 2014 sa ako príklad spomínalo práve podpisovanie OpenData, keď sa diskutovalo, v akých prípadoch môže byť užitočné používať “embedovanie” XSD/XSLT schém.

2 Likes

Technicky pre používateľa údajov, ktorý nepotrebuje overovať autenticitu údajov je krok “rozbalenia” ASiC kontajnera trviálny. Pre jednorazové spracovanie stačí .asic* ručne premenovať na .zip. Pre opakované spracovanie (update) si to dáš do skriptu a vybavené. V pohode sa táto inštrukcia môže dať do dokumentácie datasetu.

Najlepšie však, ak budú publikované 2 dátové zdroje: plain XML a aj ASiC (a v ňom opäť tie isté údaje). Toto je problém len pre ozaj veľké dáta (čakáme na kataster).

Podstatné je však niečo iné: na to aby som vedel ČO je podpísané, musí byť súčasťou podpisu interpretácia údajov.
To je najlepšie spraviť tak, že v podstate bude použitý elektronický formulár, ktorého príslušné dáta budú obsahom. V jednoduchšom prípade v pohode stačí, ak v tom ASiCu bude (okrem dát) skrátka textový dokument, s príslušným obsahom a schéma údajov. Tento popis bude v podstate obdobou papierového dokumentu, ktorý by v takomto prípade existoval pri papierovom sprístupnení, t.j. bude obsahovať jednoduchú informáciu typu “Organizácia X zverejňuje nasledovné údaje z registra Y. Licencia na ich použitie je CC0.”.

A ináč použitie KEPu je samozrejme extrémne riešenie. Hľadajme cesty ako publikovať záväzné údaj aj bez KEPu. Prosím nezabudnime, pointa tejto diskusie nie je o tom, že by sme technicky nevedeli garantovať integritu, ale že niekto paranoidný potrebuje mať vo fascikli bumážku. Naozaj v doterajšom svete im tie dáta prídu buď na papieri s guľatou pečiatkou, alebo na základe zmluvy s guľatou pečiatkou. Nie je pečiatka = dáta “nie sú oficiálne”, “nie sú garantované”, “nie sú spoľahlivé”, “nie je možné ich použiť na právne účely” a mnoho iných hlúpych výhovoriek.
Ja som týchto ľudí zažil. Nemá zmysel plytvať energiou na boj s nimi. Chcú pečiatku, no tak budú mať KEP - vyriešené, poďme ďalej.
Budeme prví na svete čo majú OpenData s elektronickým podpisom. Juchú!

@Lubor presne ako si napisal, hladajme nejake lepsie riesenie a pokusme sa ho na K9.4 alebo na PS1 presadit. Ja si viem predstavit aj stav ze data.gov.sk by bol referencny register OpenData udajov, kde na zaklade autorizovaneho uploadu z organizacie, by sa automaticky prehlasili udaje za hodnoverne (popripade standardizacia, datova kancelaria alebo niekto na urade by to potvrdil v MetaIS). Zaroven kazdy dataset resp. distribucia datasetu by mala jednoznacne URI, ktore je zaroven aj dereferencovatelne a tym padom je aj unikatny referencny odkaz na data. Tym padom by sa pausalne dal riesit tento problem aj bez KEP.

Ako sa riesilo na K9.4, v sucasnosti sa pripravuje nova studia na otvorene data, tak definujme v strategickom dokumente aby to tak bolo a ten projekt by to tak zaimplementoval. Z toho co som pochopil tak tam priestor je a treba dodat temy. Akoze podpisovat OpenData mi pride prinajmensom zvlastne.

Je tu este jedno riesenie ktore navrhoval aj @juraj.bardy a to pouzitie blockchain technologie co dokazalo v tomto ohlade nahradit KEP.

Toto je právnická otázka, čiže čo my (IT-čkari) vymyslíme je jedno, odpoveď musí prísť od právnikov.

Pre mňa KEP je skrátka dobré “veľké kladivo” - je to v zákonoch, fungujúce, proces aj infraštruktúra existuje. Problém (dočasne a nedokonale, ale) vyriešený, dnes.

“Použitie blockchain technológie” je dobrá zábavka na pokusy. Momentálne k tomu však nie je spravené nič (v e-Gov svete). Papiere, implementácia, ani skúsenosti. Vieš odhadnúť koľko to bude stáť?

1 Like

Chapem ze KEP je uz teraz a vsetko okolo neho je uz vybudovane a ako docasne riesenie je to fajn. Snazim sa to posunut ale o krok dalej tj. ako by to malo vyzerat za 4 roky a dookola omielat ze KEP nie. Su OPII projekty a podla mna je namieste im davat guide lines ako to ma zmysel a pripravovat aj podklady legislativne na prechod do noveho stavu.

To ze v eGov svete nie je nic s blockchain by som uplne netvrdil. Inspiracie je tu podla mna prave z Estonska ktora sa berie vsade ako priklad a oni to pouzivaju na e-Court, e-Police, e-Law a z toho co sim cital tak idu to nasadit na zdravotnictvo a podobne. Takisto citam ze to pouziva aj NATO alebo Europska unia v nejakych systemoch. Blockchain je urcite zaujimava myslienka a podla mna ma zmysel sa bavit o jej usecaseoch. Nechcem sa uplne v tomto case bavit hned o cene, lebo ja osobne ju neviem odhadnut, treba pohladat co to stalo estoncov ale ak by to bola nepredstavitelna ciastka tak ani oni by to podla mna nevedeli zaplatit. Ja len viem ze otvara to nove moznosti pre otvorene vladnutie a viem ak to ma niekde zmysel, tak najblizsie obdobie to ma potencial byt aj realizovatelne z OPII. Nasledne roky to bude podstatne narocnejsie s takouto technologiou zacat.

Toto je vyborne riesenie a cesta ako je mozu vyrobcovia tretich stran zarucit ze aplikacie, ci systemy, ktore budu vyuzivat opendata (stale castejsie a stale viac), mozu svojmu klientovi poskytnut zaruku doveryhodnych údajov. Vyuzitie KEP by bolo v tomto pripade naozaj neprakticke ale pouzitie kval. pecate by to neskomplikovalo a poriesilo by to sposob ako mozu aplikacie tretich stran, ktore udaje nejakym sposobom vyuzivaju zvysit svoju doverihodnost vo vztahu k uzivatelovi.
K Luborovi:

  • nejde ani tak o paranoidneho vyvojara, ale o to ze ked si zakaznik zaplati za aplikaciu (v aplikacii tretej strany), ktora vyuziva otvorene data zo statu, tak on by mal mat aspon nejaku zaruku, ze vidi a pracuje s datami, ktore su presne tie, ktore vyrobca tejto aplikacie deklaruje.
  • Súčasťou podpisu nemusi byt v tomto pripade interpretácia údajov. Kedze u napr. ciselnikov nejde o data urcene pre spracovanie clovekom, nebude nutne vytvarat ziadnu prezentaciu - postaci ak bude datovy subor podpisany, resp. zapecateny, ze sa bude dat urcit ku ktoremu casu su data platne a pod. Cize ak pracuje so svojou aplikaciou, ktora open data pouziva mal by mat aj prehlad o tom, ze to co vidi bolo platne k datumu tomu a tomu. Ak chce cerstvejsie data musi si ich stiahnut, resp. ak sa chce presvedcit ake data platili k urcitemu datumu v hiostorii, tiez by sme mu mali tuto moznost dat.

U systemov, ktore pracuju v realnom case, to problem nie je. Cize ked sa so svojou aplikaciou pripojim k zdroju datasetu, tak sa nemusim spravidla nicoho bat - ak viem ze mam spravne URI, ale su systemy, kde sa pracuje napriklad tak, ze sa datasety pouzivaju tak ze sa system pripoji a stiahne si do svojej databazy cely dataset a dalej uz pracuje iba so svojou databazou. Tu by sa prave hodilo udaje stahovat v asice.

Uplne nerozumiem kde je principialny rozdiel asi pretoze mi z toho vychadza ze :

  1. Ak je to vzdy realtime stiahnute tak je to safe
  2. Ak si to stiahnem a mam u seba nachachovane/naimportovane v DB, tak zrazu to safe nie je lebo… lebo mi to zamestnanci pomenia? Vidi pouzivatel tvojej aplikacie/systemu ze ci si to realtime stiahol alebo ze ci si to mal u seba nacachovane? Cim je bezpecnejsie realtime ako cached? Preco v tom prvom nie je potrebne byt podpisany a v druhom hej? Stale mi chyba ten case, preco by mali byt open data vobec podpisovane popripade sa to da spravit aj tak ze vzdy sa pozrie URI datasetu a prebehne negociacia s data.gov.sk ze ci obsah datasetu sedi s tym co je na data.gov.sk, ale to uz len vymyslam. Preco musi byt zoznam formularov podpisany? Platnost formulara predsa nie je/nebude sucastou balicka tak aj tak neviem ci je validny alebo nevalidny dany formular a znova sa musim integrovat.

Nechcem povedat ze ked to nebude vobec podpisane ze si s tym neporadime. Ale pre ten typ aplikacii, ktore mam na mysli, by sa velmi dobre pracovalo ak by datasety

  • vychadzali tak ako vychadzaju v csv, alebo xml forme
  • ak by bolo kazde jedno vydanie datasetu podpisane, my si mozeme po stiahnuti overit neporusenost ale aj zistit datum a cas podpisu, vieme tym urcit cas od kedy tato verzia datasetu plati
  • a ak by bolo mozne prijimat aj notifikacie, ze bola vydana nova verzia datasetu tak by to bolo uplne vynikajuce.

Pri importe udajov potom uzivatelovi iba zobrazime udaje o vydavatelovi, a dobu platnosti. Import si vykona sam na zaklade napr tej notifikacie o zmene datasetu.

Napr. dnes vo velkom vyuzivame datset zoznam institucii so zriadenou schrankou. Zakaznici mali problemy kedze sa tam za behu menila struktura udajov a program niektorym zacal padat ked updatovali svoje udaje pomocou tohoto datasetu. Tym sa stalo ze databaza jednej institucie nejake udaje obsahovala a u inej - tam kde to na chybe spadlo tam databaza tie udaje neobsahovala. Zakaznik sa obracal na nas a nie na vydavatela datasetu a chcel od nas napravu.
Nasa jedina rada v tomto pripade bola obratte sa na vydavatela datsetu on jediny ma informacie co od kedy a dokedy platilo…

preto sa mi zda tento sposob kedy mozeme aj my ako dodavatel systemu profesionalne vyriesit podobny spor tym ze nahliadneme do vsetkych doposial vydanych verzii datasetu a vieme presne informovat klienta bez potreby zatazovania vydavatela datasetu.

Chcem upozornit, ze toto v praxi nemusi byt vobec take lahke. Lebo “odkedy tato verzia datasetu plati” moze v roznych kontextoch znamenat nieco uplne ine.

Priklad: RPO zverejni dataset a podpise ho dnes.

  • Znamena to napriklad, ze ak tam nejaka PO nie je tak v tom datume neexistovala? Nie. Do RPO sa dostavaju data aj spatne.
  • Znamena to napriklad, ze ak tam nejaka PO je, tak existuje? Nie. Do RPO sa v klude mozu nejake informacie dostavat aj neskor (na tyzdennej/mesacnej baze) a teda pritomnost v datasete neznamena vlastne nic moc, pokial nevieme periodicitu aktualizacie jednotlivych zaznamov.

Inak problem s datasetom schranok UPVS sme mali aj my a mozete sa nam podakovat, ze tam je po par mesiacoch nova verzia. @lubor to bol riesit osobne v NASES, lebo sa to robi… rucne.

Jes dik, u nas bol z toho celkom chaos…

Ok nepocitame s tym ze by datasety poskytovali az take presne info. Ale to ze si mozem ukladat jednotlive vydania datasetu mi dava moznost povedat zakaznikovi ze k danemu dnu som mu dal k dispozicii vsetko to co stat doposial zverejnil

A na to je potrebny podpis? Na to je potrebna poriadna sluzba na data.gov.sk + notifikacna sluzba ako si pisal

Tak pokial sa predchadzajuce verzie premazavaju tak to tazko bez podpisu dokazes, ze to co mas v db nebol tvoj podvrh. Napriklad my stahujeme dlznikov vszp. Lenze tie datasety nemaju historiu na webe vszp. Ked sa pride niekto stazovat, tak som bez podpisu hotovy.

1 Like

@jsuchal Z toho mi ale vyplyva, ze nie niektore ale zavazne vsetky by mali byt podpisane aby sa ten problem odstranil tak?

Alternativna moznost robit LTS (long term support) datasety kde je garantovana dlhodoba napr. raz za mesiac backup s 10 rocnou garantovanou dostupnostou a STS (short term support) datasety kde je garantovana dostupnost povedzme 6 mesiacov

Hovoris mi z duse. :grinning:

Aj to je riesenie. Ale pocitaj s tym, ze ked ja mam niekde system (napr. spravy registratury), ktory pouziva sucasne povedzme 500 klientov a kde kazdy klient kazdu chvilu klikne lebo potrebuje otvorit formular a system sa pripoji ku kniznici formularov a stahuje si od tial data zakazdym klikom, potom zase iny uzivaelia kliknu na nieco ine co tiez bude komunikovat so slovensko.sk, napr. koli nejakemu datasetu tak ta komunikacia bude v ramci celeho slovenska obrovska, a pri tom ide iba o udaje, ktore si kludne mozem skladovat u seba ak dokazem uzivatelovi preukazat ich hodnovernost sposobom, ktory on nicim nespochybni. Cize da sa to v realnom case takto riesit, ale nie je to ono, komunikacia s servermi slovensko.sk bude zbytocne velka. Druhy argument moze byt aj to ze nie vsetci klienti z tych vsetkych maju pristup k internetu…

1 Like

Vratme sa znova spat.

  1. Bud sa bude podpisovat vsetko, alebo to nie je vseobecne riesenie problemu ale len nesystematicke platanie. Kludne nech sa vsetko podpisuje a podpisovat to moze data.gov.sk vzdy pri uploade datasetu. Je to legitimne riesenie
  2. Riesenie o ktorom hovorim ja tj. datasety LTS a STS
    a) sluzba na validaciu, ci je distribucia validna
    b) ake je URI platnej distribucie pre dany dataset
    c) odkedy dokedy je platna dana distribucia
    d) notifikacna sluzba, ktora sa zavesi na dataset a ked pribudne nova distribucia datasetu tak sa notifikuje pouzivatel
    Ak sa bavime o formularoch tak na to je specificky modul elektronickych formularov MEF a nie data.gov.sk. MEF ide rovnakou cestou akou popisujem v tomto bode tj. validita sa vytiahne von z meta.xml a budu sluzby ktore budu vracat veci ktore som popisal. Takto to bolo odsuhlasene na PS1. Preto formulare nie su tak priklad pre OpenData ktory hladame. Bavme sa o RPO, o zozname dlznikov VSZP tj. velkych datach, ktore nikto nestahuje 100x za den.
    Dalsia vec je ze hovorime o otvorenych datach a nie o sluzbach a tomu treba prisposobit aj pouzivanie. Osobne si myslim ze distribucia datasetu sa ma stahovat LEN ak je nova a nacachovat v systeme a nie ze sa pri kazdom volani stahuje. Ved to nedava zmysel. Ako by to dopadlo ak by si niekto tahal kazdu chvilu cele RPO lebo uzivatel klikol na zoznam vsetkych firiem. Hadam by si to k sebe stahoval a aktualizoval na notifikaciu a nie donekonecna stahoval. Taketo spravanie velmi rychlo bude viest k tomu ze bud sa taketo spravanie spoplatni, alebo to bloknu ako kataster kde mozes spravit request pomaly raz za minutu. Co sa tyka overovanie ci je dataset validny cez sluzbu, tak podla mna toto vie byt velmi rychle a pouzivatel si moze velmi rychlo overit platnost a nemusi stale tahat cele datasety, ale len vtedy ked to realne potrebuje. Takze pri normalnom pouzivani podla mna nehrozi to co popisujes. Argument bez internetu moc nechapem. Ako to v tom pripade funguje? Stiiahne si to z overeneho zdroja a musi neustale overovat ze ci to naozaj stiahol z overeneho zdroja aj ked to spravil len raz za rok a potom bol cely cas offline? Aky je usecase a ako sa to vtedy pouziva?
  3. Tretia moznost je spominany blockchain, kde to bude transparentne ako oci, doveryhodne a vsetko mozne. Otazka je ze co takato vec bude stat, ako som ale spominal uz sa to zacina rozsirovat ale uz zo zakladneho popisu technologie je zrejme ze to nebude stat jednotky tisic eur. Legitimna alternativa to ale urcite je.

@miromr Vidis okrem tohto zhrnutia dalsiu alternativu? Bavme sa len o systemovych rieseniach tj. ak podpisovanie tak prikazom. Osobne si myslim ze sa dokonca bod 1 a 2 nevylucuju. Tretia moznost je uplna zmena konceptu prace s datami, ale aj ona je riesenim

Prihovaram sa za podpisovanie vsetkych datasetov. Tie volania do internetu po kazdom kliknuti som daval iba ako priklad s tym ze uz teraz zbytocne komunikujeme ci uz s data.gov.sk alebo slovensko.sk to je jedno.
Ak budem mat u seba dataset, ktory je zapecateny, nebudem uz potrebovat do vydania dalsieho komunikovat s data.gov.sk.
Blockchain zabezopeci integritu na strane vydavatela, tam podla mna staci zaistit rezim a opatrenia aby nedoslo k neziaducej modifikacii. Snazim sa povedat ze dataset po jeho stiahnuti do takehoto systemu nadalej zije svojim zivotom, a ze po uplynuti nejakej doby niekdy aj mesiacov ci rokov sa k nemu potrebujeme vratit. V tejto dobe uz data.gov.sk obsahuje data v uplne inom stave. Cize hovorim o potrebe nie na rozhrani data.gov.sk - uzivatel, ale aplikacia tretej strany a jej uzivatelia.
My by sme potrebovali, aby my-vyrobcovia aplikacii co pouzivame tieto data vo svojich aplikaciach aby my sme mohli poskytnut nasim klientom istotu, ktora nebude zalozena iba na nasom tvrdeni ze data po stiahnuti nijak nemenime. Naviac nam to pomoze tak ako som pisal udrziavat nase ciselniky v stave, ktory bude najlepsie zodpovedat skustocnemu stavu aj s evidenciou zmien v urcitom casovom rozsahu do minulosti.

Zajtra by malo byt posledne zasadnutie skupiny K9.4(pred hlasovanim o OpenData priorite) ktora momentalne otvorene udaje uzatvara a chce o nich dat hlasovat. Mozem otvorit tuto temu priamo tam aby sa to dostalo aj do strategickej priority pre otvorone data.

Aby to bolo uniformne, podpisovanie by prebiehalo priamo na strane data.gov.sk, ktore by to publikovalo. Ak to ma byt pouzitelne, tak ako pisal @Lubor bolo by dobre aby boli ako podpisane tak aj nepodpisane verzie datasetu nakolko nie kazdy potrebuje podpisany subor a zbytocne by sme ho do toho nutili. To ktory pouzivatel chce by si sam vyriesil prostrednictvom parametrov dereferenciacie. Suhlasia s tym aj ostatni resp. vidia aj dalsiu alternativu, ktora by bola mozno este lepsia? @jsuchal @hanecak @Lubor @liska @stefan.szilva

Blockchain je o integrite na strane vydavatela, ale tym padom je mozne vzdy zvalidovat ze co mam u seba stiahnute voci referencnemu stavu, ktory sa “nestraca” a je nemenna, takze aj tato alternativa ten problem cela riesi.