OK starý postup pri elektronickom podaní, podpisovalo sa ručne. Ako som uviedla, teraz sa má postup meniť, ak občan bude chcieť elektronické podanie, bude podpisovať eID, potom konverzia. O elektronickom podpise a o konverzii majú vydať záznam. Tak nejak som to pochopila, nie je jasné odkedy sa to spustí. (zákon o e-Governmente)
Originál zmluvy sedí, kniha sedí, podpisy sedia, údaje na občianskom sedia, ale bol falošný, lebo fotka bola iná a prišiel podpísať iný občan než skutočný vlastník - to bol problém pri starých plastových OP
multikanal - dovod je, ze EU nas nuti transparentne informovat obcana o stave vybavenia podani
Integracia a Orchestracia
diskusia - synchronna vs asynchronna komunikacia - striktne synchronna integracia moze mat problem v peakoch
co maju byt klucove standardy? spravit analyzu
otazka ci - byrokracia nie je vacsi problem ako nedodrzane standardy
kto bude mat zodpovednost a kompetenciu za ZS - kto bude mat bic na rezorty aby bola sucinnost?
ak niekto vie, ze jeho sluzba bude potrebna, vie vydierat
standardy boli vyprodukovane neskoro - az po implementacii - vznikali problemy
diskusia
datova integracia - operativne datove ulozisko a vedla toho dwh.
centralizacia - sanca odlahcit od zbytocnych orchestracii
MUK
historia - nemali by fungovat len cez schranky
datova cast - synchronizacia do inych systemov (toto bol povodny zamer), povodne to bolo chapanie ako rura nie ako storage
diskusia k SIFO - poskytnut data mimo rezortu, ktory ich ma na starosti je problem
EVS - potrebujeme vstupy od nich
mozno nejake veci budu uplne inak (napriklad riesenie poplatkov)
jedna cesta asi nebude nikdy spravna
webapi gateway nad tym vsetkym
diskusia - ak padne ESB co potom? = “centralny vypinac egovu”
Za ulohu sme dostali doniest k OPEN API poziadavku na integraciu.
Stretnutie 20.12.2017
velmi dlha (a podla mna zbytocna) diskusia k aktualnemu stavu MUK (komunikacna, pristupova, datova, datova2)
bolo povedane, ze IS CSRU je dnes akasi platforma datovej integracie az na to, ze tam treba dalsie veci dorobit.
opat otazka k ZS - kto bude gestorom, ake bude mat paky na gestorov roznych potrebnych sluzieb, aby ho nesabotovali/nevydierali ale spolupracovali.
linked data - bol navrh aby boli datove prvky a sluzby popisane cez linked data na urovni schemy. k tomuto neboli namietky.
k open api
upozornil som, ze pokial budu rozne zbernice pre externy a interny svet, tak moze nastat podobna situacia ako v open data (register adries na data.gov.sk nefungoval mesiace a nikoho to velmi netrapilo). idealna by bolo zjednotit zbernica/gateway pre interny a externy svet (nie nutne na urovni 1 centralny projekt). na urovni web api gateway taky plan je.
povedal som zakladnu predstavu toho ako si to predstavujeme. nejde o nejaku extra novu vec. schranky dnes tak podobne funguju. viete dat niekomu splnomocnenie, aby tam pristupoval za vas.
potrebujeme z pohladu integracie:
umoznit jednoducho dat splnomocnenie tretej strane.
umoznit pristup k api v zastupeni. aj offline
umoznit pristip tretim stranam k api ktore reaguju callbackom - napr. zmena trvaleho bydliska (vyleti domenovy event niekde na zbernicu, a tretia strana to bude vediet odchytit - napriklad banka)
bola vznesena namietka, ze ked sa centralne budu uchovavat nastavenia o permissions tak to bude vela dat a zataz. z nasho pohladu to nie je problem, komercia takto funguje na vacsej skale.
bola vznesena namietka, ze toto by sa malo diat na klientovi a ten by mal toto posielat kam treba. z nasho pohladu nie, ten domenovy event moze vyletiet aj bez interkacie s pouzivatelom (napr. periodicke eventy resp. naviazane na cas) a podruhe, nesmie sa stat, aby znalost o x dalsich systemoch, ktore mozu pocuvat bola v agendovy systemoch. toto je dratovanie. (bolo to spomenute z viacerych stran)
Ako ulohu sme dostali zaslat poziadavky k open api veducemu PS na email.
Predbežná informácia k PI/2017/44 Návrh zákona, ktorým sa mení a dopĺňa zákon č. 305/2013 Z. z. o elektronickom výkone pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) v znení neskorších predpisov https://www.slov-lex.sk/legislativne-procesy/SK/PI/2017/44
V záujme zjednodušenia autorizácie elektronických dokumentov sa navrhuje umožniť autorizáciu aj zadaním bezpečnostného osobného kódu na občianskom preukaze s elektronickým čipom, čím sa umožní poskytovať elektronické služby aj bez nutnosti použitia kvalifikovaného elektronického podpisu.
Toto bola moja iniciativa, aby bolo vsetkym uradnikom jasne, ze nemusia mat KEP na vsetkych vstupoch od FO/PO.
V tejto suvislosti ma napadli este dve kacirske myslienky, ktore by rozbili biznis s nazvom mandatne certifikaty:
v prvom rade ich zrusit s prechodnym na 2 roky a
v druhom rade stanovit pre statutarov OVM moznost autorizovat aj vlastnym KEPom.
Je to myslené tak, že sa občan prihlási (použije eID a zadá BOK), zvolí službu, vyplní formulár a ako jeho potvrdenie (autorizáciu) znovu zadá BOK? Niečo ako obdoba potvrdenia transakcie v internet bankingu? Alebo sa tým myslí len prvotné prihlásenie s eID a zadanie BOK?
Nerozumiem celkom pridanej hodnote tejto “novinky” do buducnosti. Co brani v sucasnosti upravit v zakonoch pouzivanie BOK? Staci si len pozriet napr. zakon o cestnej premavke a elektronicke evidencne ukony pri vozidlach: na ukony +/- meniace vlastnictvo/drzbu vozidla sa vyzaduje ZEP, na ine ukony staci BOK. Jednotlive urovne autentifikacie sa aj tak nedaju urobit jednotne cez e-Gov zakon, vzdy to bude musiet byt v jednotlivych zakonoch uvedene pri konkretnych ukonoch, a to moze byt aj teraz.
Rozumiem tomu čo hovoríš a súhlasím, že by to v eGov zákone ani nemuselo byť, ale bohužiaľ naša verejná správa ak nemá niečo v zákone, tak jednoducho taký postup neaplikuje.
Priznávam, že ide o nadbytočné ustanovenie, ktoré by navyše malo byť obsahom agendových procesných predpisov, ale vzhľadom na realitu bolo potrebné, aby sa strešne ukázalo, že je možná aj nižšia úroveň autorizácie ako len ZEP.
AK by to tam nebolo, úradník by stále obhajoval ZEP všeobecnou úpravou, ktorá nižšiu úroveň nevyžaduje. Tá koniec koncov často nie je a a ani nemusí byť upravená v agendovom procesnom predpise, pričom by stačila dobrá metodika výberu úrovní autorizácie a autentifikácie a podľa kritérií by sa pre jednotlivé služby stanovovali konkrétne úrovne aj bez úpravy náležitosti v zákone.
Startuje sa Strategicka priorita: Interakcia s verejnou správou, životné situácie a výber služby navigáciou.
Veduci skupiny dal uvodne stretko kde sa povedal plus minus scope co sa bude postupne riesit. Mal by byt harmonogram, na ktorom stretnuti sa co bude riesit.
uzavretie dokumentu ma byt v maji - je viac casu (oproti povodne mu planu hore, posun az o 2 mesiace)
kto by chcel moze dostat spravu hodnotenia eGov na slovensku - su tam zivotne situacie z 8 oblasti
rozne typy navigacie - vsetko sa pouziva - fulltext, katalog, lokator (upozornil som, ze bezne chodi aj 80% z externych vyhladavacov - google atd)
ci to meraju - asi hej, mozu zistit
centralizacia vs decentralizacia sluzieb. bude vsetko na slovensko.sk alebo sa len zjednoti vizual - lepsie hodnotenie z eu ak to je jeden portal (co sme hned rozporovali, ze je nezmyselna metrika)
diskusia o tom ako sa tvori obsah na slovensko.sk a aku ulohu v tom ma ma a ma mat NASES
platby/poplatky su komplikovany problem - mozno vznikne podskupina (mali by sa prizvat aj ludia so statnej pokladnice a MSSR)
inkaso je po zmene EU legislativy / SEPA platieb - zlozity papierovy proces - celkovo dost no-go - lepsie su karty
platby kartou - cakanie na potvrdenie je problem pre stat. nemusi teoreticky dostat zaplatene. treba riesit v legis
diskusia o remote signing - z mojho pohladu je to velmi zvlastne, ak to ma robit stat, tak moze celu cast toho podpisovania vynechat - je uplne zbytocna, kedze autorizacia sa deje na necertifikovanom zariadeni - mobile a odosiela sa von. To, ze sa to potom niekde ovela bezpecnejsie podpise nepridava nic. Malo by sa to pouzit ako nizsi stupen autorizacie pre nejake ukony kde netreba.
cielom skupiny je pokryt potreby pre celu cestu pouzivatela a pripravit nejaku “kucharku” ako postupovat.
Nerozumiem uplne preco prechadzaju na toto, napadaju ma vseliake dovody - centralizacia analytiky, zdielanie cookies, pouzivatelia mozno boli zmateni z inej subdomeny (netusim).