Advokáti a notári majú knihy, do ktorých sa fyzicky podpisujú prevodcovia a nadobúdatelia pri autorizovaných zmluvách. Notári a advokáti potom papierovú zmluvu naskenujú a podpíšu KEPom, takto podpísanú odosielajú elektronicky katastru. V prípade podvodu sa okrem originálu zmluvy, Môže porovnať aj kniha autorizácii s podpismi.
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
Mam tu nejake resty takze podme na to:
To najdolezitejsie najprv - mame dokument k multikanalovemu pristupu. Treba spisat pripomienky do 4.1. K9.5 - Pripomienkovanie Strategická priorita Multikanálový prístup
Stretnutie 15.12.2017
- 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.
Zapis k stretnutiu 12.1.2017
- dizajn manual - dostal na starost stefan szilva - bude sa diat paralelne
- integracia orchestracia - o 2 tyzdne nejaka verzia dokumentu na pripomienkovanie
- 270 pripomienok k multikanalu (veduci skupiny da vediet, ci zverejnitelne)
- je tam aktualizovana cielova architektura
- nove dva kusy k MUK - interakcna cast + orchestracna cast
- integracne centrum - asi to bude rozdelene, nie jedna institucia
- data su povinne cez muk, inak netreba ist cez muk
- diskusia ci pojde vsetko cez centralnu zbernicu
- bude integracny board, ktory bude schvalovat vynimky
- data - radsej v open data mode - teda nie cez zbernicu
- pripomienkovanie - bude nieco ako rozporove konanie - kde sa dohodnu nedoriesene pripomienky
- centralne komponenty - ci to bude centralny/decentralizovany/platformovy model sa ma rozhodnut najneskor v studii uskutocnitelnosti
3 posts were split to a new topic: Záväznosť vypracovaných dokumentov
2 posts were split to a new topic: K9.5 - Pripomienkovanie Strategická priorita Integrácia a Orchestrácia
A post was merged into an existing topic: Záväznosť vypracovaných dokumentov
4 Likes
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
možnosť vyjadriť sa je do 3.3.2017
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.
cc @Lubor
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.
Z tejto pracovnej skupiny sú výsledné dokumenty Multikanálový prístup a Integráci a orchestrácia predložené na schválenie v Rade vlády 28.2.
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?
Myslí sa tým toto
1 Like
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.
1 Like
Kratky zapis zo stretnutia vcera 2.3.2017
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
-
chvilu sa riesilo co so slovensko.sk
- 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.
1 Like
Ak mate navrhy na scope co by sa v tomto dokumente malo este prebrat, dajte vediet teraz.
Poslete mi prosim ten dokument? Vdaka.
Dokument neexistuje. Ten sa ide tvorit. Odkaz na staru verziu je v prvom prispevku.