MIRRI Pracovná skupina K9.5 Lepšie služby

A post was merged into an existing topic: Záväznosť vypracovaných dokumentov

FYI: Toto je priklad loginu do Norskeho egovu. OpenAPI na autentifikaciu.

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.

V skupine sa otvorila otazka, ze ci teda tie aplikacie maju byt centralne alebo nie. Na gov.uk som si vsimol jednu zmenu.

Zive aplikacie - formulare - boli vzdy na subdomenach ale po novom ostavaju na subdomene gov.uk - https://www.gov.uk/settle-in-the-uk

Pritom je zrejme, ze gov.uk serviroval doteraz takmer vyhradne staticky obsah. Finta sa vola novy router https://github.com/alphagov/router a k nemu router api https://github.com/alphagov/router-api kde si mozu samotne urady zaregistrovat nejaky endpoint a serviruje to z ich aplikacie.

Nerozumiem uplne preco prechadzaju na toto, napadaju ma vseliake dovody - centralizacia analytiky, zdielanie cookies, pouzivatelia mozno boli zmateni z inej subdomeny (netusim).

Celkom dobre citanie k architekture je tu https://gdstechnology.blog.gov.uk/2016/07/08/introducing-the-gov-uk-publishing-platform-in-detail/ a dokonca nepouzili ani TOGAF :slight_smile:

@ret toto by mozno bola cesta ako decentralizovat aplikacie na gestorov ale zaroven centralizovat na slovensko.sk

2 Likes

No asi by sme mali rozlisovat FE a server-side end-pointy. Co sa tyka end-pointov tak podobny scenar uz mame porkyty v ramci MC a IaO, ci ?

API GW zakryva centralne a agendove front-office mikrosluzby, cez ktoru su standardizovane vystavene do kanalov. Tzn. teraz ten routing vykonava API GW, ale ako standardny middleware (bez dodatocnej biznis logiky, robi nativne funkcie). Ak sa rozhodneme ten routing dopnit o nejake biznisove funkcionality napr. aproximacia cookies, vieme takuto proxy posunut nizsie do centralnych mikrosluzieb ako end-point a z nej realizovat routing.

K tym FE a publishingu contentu - vyzera to zaujimavo, mohli by sme to prejst na PS. Ked sa pozries tak modre stickers su apps a funckie, tak je to trocha Archimate… :slight_smile:

Aj si to potom nakreslime, ci sa rozumieme :).

Podla mna toto je cisto o frontende a je to len reakcia na tu vec z PS - “Budeme mat lepsie hodnotenie, ked to bude na jednom portali.” – pricom koncoveho pouzivatela to podla mna vobec nezaujima, jeho zaujima ci to je konzistetne (vyzera a sprava sa to rovnako = dizajn manual) a az potom mozno niekde v dialke riesi, ze ci to je rovnaka url.

API pokial spravne pozeram oni vobec necentralizuju (mozno tam pridu).

Ano, prave som to precital… Pokusim sa nieco z toho pripravit na ten workshop k centralny vs. specializovane portaly a ako by ta interakcia a redirect mohol vyzerat z pohladu FE.

2 Likes

Existuje malá skupina služieb štátu, ktorá si vyžaduje osobné overenie jej iniciátora (žiadateľa/navrhovateľa). Samozrejme, okrem overovania totožnosti kvôli dvom dokladom totožnosti - pas a eID, ktorá je nevyhnutná.
Tou prvou je zapis do katastra nehnutelnosti a druhou do evidencie vozidiel. Obidve by v normalnejšej spoločnosti mohli byť od iniciácie až po výstup, realizované plne elektronicky, ale keďže u nás sa podvádza aj v listinnom svete, tak na tieto dva úkony by som stále vyžadoval osobné overenie notárom/úradníkom.

Problémom zapisu do katastra nehnutelnosti nie je problém samotného vkladu, ale byrokratický vstupný formular, ktorý brani zjednoduseniu celeho procesu…pritom by stačilo málo - jednoznacny identifikátor nehnutelnosti a tým by sa vstupne udaje zostihlil o 3/4…

Kratky zapis zo stretnutia 9.3.

  • MV - uz ma projekt na zber spatnej vazby v klientskych centrach
  • potreba zadefinovat, co je to zivotna situacia, kde zacina a konci?
  • potreba monitoringu end-to-end procesu ZS, kvoli optimalizacii.
  • ciel je nejaka “kucharka” - napr. co bude stavova orchestracia a co eventova propagacia pre dany proces
  • ako donutit tretie strany (napr. vszp) alebo “neposlusne” OVM spolupracovat?
  • kto bude mat zodpovednost ze ZS je spravna a uplna?
  • MV - ma uz namapovanu legislativu na koncove sluzby (700 zakonov)