Poslana aktualna verzia. Pripomienkovanie - Dopytova vyzva male zlepsenia egovu.odt (21.5 KB)
V mene ÚPPVII si vás dovoľujem pozvať na ďalšie zasadnutie pracovnej skupiny Lepšie služby. Prešli by sme si tému publikovania služieb do multikanálového prostredia.:
Kontext ešte z minulého behu PS Lepšie služby (prečo je potrebné sa témou zaoberať)
Informácia o metodike, ktorú dáva dokopy PS Architektúra
Ktoré služby by bolo dobré publikovať ako OpenAPI pre dosiahnutie „quick wins“ (krátky vstup pre nás pripravia kolegovia z Slovensko.digital, ale ak má niekto v hlave nápady k tejto téme, pošlite mi mail a pridám do programu)
Ja idem prezentovat otvorenie API/formularov pre podania na slovensko.sk, ktore by podla nasho nazoru velmi zjednodusili sposob integracie tretim stranam. Idea je nasledovna
- clovek na stranke tretej strany v nejakom peknom “wizarde” vyplni potrebne udaje (napr. na zalozenie zivnosti)
- klikne na button “poslat cez slovensko.sk”
- treto stranou vytvorene formularove xml (kedze to je vymenny format) sa odosle na povedzme podanie.slovensko.sk, tam sa zobrazi TXT/HTML vizualizacia a jeden button dole podpisat a odoslat.
- Nasledne zbehne prihlasovaci flow a pripadne aj podpisovaci. centralne.
- po uspesnom alebo neuspesom odoslani je clovek presmerovany spat na tretiu stranu, ktora sa dozvie o vysledku podania. (cez callback co tam posle)
V principe by toto mohlo fungovat aj uplne bez akychkolvek dohodach o integracii s tretimi stranami. (predpokladam, ze pravnici a bezpecaci budu mat okamzite nejaky iny nazor).
V minimalistickom rezime by stacilo otvorit API na podania, takato podstranka by vsak zjednodusila cely proces este ovela viac. V principe aj vyvojari systemov pre OVM by nemuseli prechadzat zlozitou komplikovanou integraciou ale vyuzili tento centralny komponent. Nie je to nic svetoborne, do velkej miery to takto presne bolo navrhnute a schvalene aj strategickej priorite interakcia s VS…
Ked mate nejake tipy na otvaranie API alebo “male zlepsenia egovu” sem s nimi. Stretnutie je buducu stredu.
Finacna sprava - maju uz teraz moznost pre kazdy formular (s ktorym som sa stretol ja) uploadnut xml, ale manualne…otvorenie na strojove spracovanie by pomohlo
1 Like
Zapis z dnes:
- Najprv bola prezentacia od @msurek, nie uplne som pochopil, ze preco na PS lepsie sluzby sa to bralo do takeho detailu. Ale ako info ok.
- Potom som mal prezentaciu ja (vid vyssie). Na moje pocudovanie panovala velmi prudka zhoda, ze toto treba spravit cim skor a co najjednoduchsie.
- @kyselat vyzval dalsich nech prichadzaju s podobnymi napadmi na male zlepsenia/otvorenia egovu. Padli navrhy na otvorenie platby kartou, mobilne prihlasovanie, otvorenie prihlasovania ako takeho tretim stranam (rovnaky navrh u nas je tu Proof of Concept pre OAuth s eID), zjednodusenie pristupu k transformaciam formularov (myslim, ze dokonca rovnaky navrh padol tu Zdielanie definícii eFormulárov a realizácia transformácii), zjednodusenie pristupu do schranky tretim stranam.
Cize ak mate nejake napady na male zlepsenia a otvorenie API, tak teraz je dobra prilezitost.
2 Likes
V mene ÚPPVII si vás dovoľujem pozvať na ďalšie zasadnutie pracovnej skupiny Lepšie služby. Pokračovali by sme v téme quick-win publikovania služieb do multikanálového prostredia. Od posledného stretnutia by bolo dobré detailnejšie prejsť nasledovné témy.:
- „Formulár ako služba“ (z minulého meetingu) a otázka bezpečnosti scenára (3d party landing page, vs. landing page pod gesciou napr. v NASES). Doručovanie podaní cez schránky, vs. cez portál a agendový systém (Zákon o eGov vs. výnimky a povolené prechodné obdobia). Vstup od kolegov z S.D.
- Od kolegov od dopytovej výzvy „Malé zlepšenia eGov služieb“ sme dostali zadanie, viď nižšie.
Zadanie nizsie:
Zadanie do PS Lepšie služby:
Aká może byť predpokladaná výška žiadaných financií per projekt - tj o váš expertný odhad, čo všetko sa dá doručiť 1 projektom, ak oprávnené aktivity sú dané nasledovne:
Žiadateľ projektom prinesie povinne
všetky zlepšenia služby alebo časti konkrétnej služby v súlade so zoznamom a popisom atribútov uvedených v prílohe č.12, ktoré popisujú čo všetko má e-služba obsahovať pre zabezpečenie dobrej zákazníckej skúsenosti používateľa v súlade s jednotným dizajn manuálom e-služieb; v prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní; a
responzívny dizajn, v prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní.
používateľské rozhranie (front-end, GUI) a postupnosť krokov pri realizovaní elektronickej služby nadizajnované na základe kompletnej UX analýzy, pozostávajúcej minimálne z nasledovného:
i. definovanie hypotéz vlastníka IS
ii. identifikovanie persón/typov používateľov,
iii. user needs research (prieskum potrieb používateľa),
iv. identifikovanie a prioritizácia problémov vyplývajúcich z user needs researchu
v. návrh testovacích scenárov.
vi. testovanie podľa testovacích scenárov s využitím focus groups.
vii. pri testovaní má byť využitá forma A/B testovania, alebo RCT (Randomized Controlled Trials), alebo iná podobná bežne akceptovaná forma UX testovania.
V prípade ak je aktivita podľa bodu 3 pre jednotlivú službu nerelevantná, žiadateľ to zdôvodní.
elektronické poskytovanie informácie pre občana / podnikateľa o stave vybavovania elektronickej služby. Ide o poskytnutie informácie o zmene stavu podania, ktorá nastane po zrealizovaní samotného podania.
imlementáciu štandardného Google Analytics, tak aby bolo možné analyzovať početnosti prístupov k elektronickej služby, počet úspešne zrealizovaných podaní, zdroje návštevnosti elektronickej služby, a pod. V prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní.
bude minimálne pripravené (ak nebude možné riadne zrealizovať) automatizované (napr. pomocou web služby) poskytovanie informácie o úspešne zrealizovanom podaní pre ÚPVS; ide o poskytnutie základnej informácie - identifikátora služby (ID) spolu s informáciou, že bolo úspešne zrealizované podanie.
K tomu žiadateľ je oprávnený priniesť aj ostatné typy zlepšenia e-služieb výberom od 7) až 11):
nastavenie aktívnych „listenerov“ pre registráciu udalostí, vytvorenie integračných väzieb cez platformu integrácie údajov,
umožnenie online platenia,
prihlasovanie/ podpisovanie pomocou Smartfonu (vtedy, keď bude centrálne riešenie k dispozícii),
dosiahnutie multikanálového prístupu,
zriadenie proaktívnej služby (úroveň 5 v zmysle výnosu o štandardoch)
PLUS ešte povinne:
12.) Žiadateľ zabezpečí, že služba bude zrealizovaná, resp. upravená tak, aby sa pri jej volaní realizoval prístup na backend (volanie backendových služieb) výlučne cez webAPI Gateway (v zmysle zákona o eGovernmente Modul procesnej integrácie a integrácie údajov, bod a) jednotné pripojenie a interakcia prístupových miest). Toto platí v prípade všetkých prípadov spustenia služby, tzn. aj v prípade spustenia služby cez rezortný portál. Takto publikovanú službu je možné prepoužiť aj v budúcich scenároch (napr. sprístupnenie tretím stranám) a umožní to monitorovanie využívanosti služby.
V prípade, ak nebude webAPI Gateway v danom čase k dispozícii, je potrebné zabezpečiť aspoň definíciu rozhrania služby v zmysle otvoreného API kedykoľvek publikovateľnej pre priamy prístup tretích strán.
13.) Žiadateľ zabezpečí, že služba bude dostupná cez ÚPVS. (portál ÚPVS prinajmenšom odkáže na konkrétnu webovú stránku verejnej správy poskytujúcej službu, alebo poskytuje priamo konkrétnu službu).
@lubor poznamenal, ze k 1. je to vyriesene v zakone (a.k.a - podanie kliknutim) 305/2013 Z.z. - Zákon o elektronickej podobe výkonu... - SLOV-LEX
a) ak sa podľa zákona podáva v elektronickej podobe a zákon neustanovuje iný spôsob autorizácie alebo ak je podľa osobitného predpisu náležitosťou podania vlastnoručný podpis
- kvalifikovaným elektronickým podpisom17) alebo kvalifikovanou elektronickou pečaťou,18)
- použitím na to určenej funkcie informačného systému prístupového miesta a po úspešnej autentifikácii osoby ktorá autorizáciu vykonáva, zodpovedajúcej najmenej úrovni zabezpečenia „pokročilá“ podľa osobitného predpisu,20a) ak sa zabezpečí uvedenie tejto osoby ako odosielateľa elektronickej správy, nemennosť obsahu autorizovaného dokumentu do momentu uloženia v elektronickej schránke adresáta, spojenie autorizovaného dokumentu s identifikátorom osoby odosielateľa a zachovanie väzby medzi nimi, ak to osobitný predpis nezakazuje alebo
- uznaným spôsobom autorizácie, ak to osobitný predpis nezakazuje,
Áno, pri autorizácii kliknutím musí ÚPVS zabezpečiť autentifikáciu+vloženie (vyplneného) formulára+zobrazenie formulára+veľké tlačítko “podávam”. Toto ak sa spraví dobre, tak sa môže priamo použiť ako realizácia autorizácie kliknutím pre používateľov ÚPVS ktorí prišli “štandardne”, pre tých čo budú presmerovaní z app tretích strán, a detto aj pre používateľov z mobilných platforiem.
Pri podaniach autorizovaných KEPom stačí, ak ÚPVS umožní čo najjednoduchšie použitie API na podanie. Nie je potrebná ani autentifikácia používateľa (jej vyžadovanie je imho porušenie zákona), ani žiadna interakcia s používateľom (netreba GUI).
Ak má zmysel, môže samozrejme existovať aj služba, ktorá umožní zobrazenie+podpísanie KEPom+odoslanie podania.
1 Like
Keď čítam definíciu v zákone, osobne sa mi nezdá tento výklad automaticky ako jediný možný. Som samozrejme “za” myšlienku “Formuláru ako služby”, ale nezdieľam presvedčenie, že postačuje argumentácia štýlu - “stačí ak dodržíte zákon”. Podstatu návrhu “Formuláru ako služby” vnímam v tom, že prístupové miesto publikuje tech. rozhranie, na ktoré je možné sa pripojiť (aj keď sú to redirecty - teda prepojenie na “UI” vrstve). Úprava v zákone rieši len samotné vyjadrenie vôle (podpis), nie povinnosť publikovať tech. rozhranie. Prakticky: prístupovému miestu (napr. ÚPVS) postačuje zaviesť framework pre “centrálne” definície vypĺňacích formulárov, ktorý dá k dispozícii OVM nech si pomocou nich formuláre vytvoria. A tieto formuláre budú mať na konci to tlačítko “podpísať”. Podstatný rozdiel je, že napriek 100% kompatibilite so znením v zákone, “integračné rozhranie”, na ktoré by sa mohol niekto pripájať nikde nevznikne.
Plus malá technická poznámka k podpisu klikom - bez ohľadu na to akou technickou formou sa vyjadrenie vôle udeje, na konci je elektronický podpis (nejakej úrovne) - inak sme mimo právneho rámca EIDAS. Takže služba, ktorá umožní zobrazenie + podpísanie (nemusí byť len najvyššia úroveň) + odoslanie podania je jediná možná, nie len akýsi doplnok.
Ach, opäť táto téma. S eIDAS toto nemá nič. Presnejšie, eIDAS nijako nelimituje možnosť krajiny spraviť si pre seba hocaké autorizačné mechanizmy aké len chce. Čiže nie, “na konci” elektronický podpis byť NEMUSÍ.
(Dôkaz sporom: už dnes existuje plno podaní, ktoré nie sú autorizované el. podpisom. eIDAS platí a tieto podania sú zjavne legálne a platné. ČBTD)
Samozrejme, že eIDAS nelimituje možnosť spraviť si v rámci krajiny proprietárny mechanizmus pre vyjadrenie vôle, mimo rámca, štandardov (a regulácie) EU (eIDAS). Ale načo by to tá krajina robila, s čím presne si pomôže? Ak krajina použije elektronické podpisy (nemusia byť iba KEP a teda môžu byť aj lacné), tak získava synergický efekt z toho, že prípadné hrozby a príležitosti (inovácie) sleduje a rozvíja okrem danej krajiny aj kopec iných krajín. Nehovoriac o otvorení dverí pre budúce interoperabilné scenáre (budem môcť vyjadriť vôľu prostriedkom, ktorý používam v SR - aj pri podaní v inej krajine EÚ).
Naspäť k pôvodnej téme (“formulár ako služba”), pretože to ma kvôli zajtrajšej pracovnej skupine zaujíma viac. Proti mnou navrhnutej interpretácii zákona si nenamietal, takže ju beriem ako “uznané spresnenie”?
Ani ja, z čoho máš pocit že áno? O PODaaS v zákone nie je nič a nevidím potrebu tam v tejto súvislosti ani niečo pridávať/meniť.
Áno, to je predsa súčasť definície. Písal som, že aká asi funkčnosť má nasledovať v rôznych scenároch “po” pripojení sa na toto rozhranie. A konkrétne vidím 3 dosť rôzne scenáre, ktoré všetky majú opodstatnenie - samozrejme je na zváženie je ktorý/kedy/kto implementuje. Najjednoduchší scenár je to podanie už autorizované KEPom, stále nechápem prečo takéto niečo ešte neexistuje.
Toto imho nemá s PODaaS taktiež nič spoločné. Stále sa vlastne vraciame k téme “čo všetko má formulár robiť”. Pri téme PODaaS je “vypĺňacia” funkčnosť úplne irelevantná. Jediná potrebná je definícia formulára a vizualizačná transformácia. A tie si môže (z pohľadu PODaaS) vytvoriť kto chce ako chce. Tlačítko “podpísať” nie je súčasťou vizualizácie (a teda nie je súčasťou “formulára” v zmysle o akom tu hovoríme), je to funkčnosť obslužnej aplikácie, či už ide o KEP, autorizáciu kliknutím, alebo Tebou preferovaný AdES.
Btw. teraz tu píšeš za seba, či za ÚPVII, alebo ako?
Naopak, každá krajina (a aj SR odjakživa) má množstvo takýchto spôsobov. Robia to tak, lebo je to efektívne. A najmä - verejná správa nie je pupok sveta, ani v EÚ (a eIDAS nie je o verejnej správe). Pozri sa na komerčnú a občiansku sféru. Napr. také e-shopy, alebo veľké platformy, interné procesy vo firmách atď. atď. “Proprietárny mechanizmus” kam len pozrieš a (skoro) nikde elektronické podpisy! (a je to v poriadku)
Veľmi rád si pozriem porovnania jednotlivých variantov z hľadiska ceny, technických nárokov, aj požiadaviek na používateľa.
Nemajme veľké oči. Práve autorizácia kliknutím má byť pre tie jednoduché veci, ktoré netreba nijako komplikovať.
Mimochodom, EÚ po 20 rokoch snaženia nedokázala poriadne spraviť interoperabilným ani ten KEP.
Ale ja vlastne súhlasím s tým čo píšeš - “použije elektronický podpis”, v zmysle eIDAS. Tam podľa čl.3.10 elektronický podpis “sú údaje v elektronickej forme, ktoré sú pripojené alebo logicky pridružené k iným údajom v elektronickej forme a ktoré podpisovateľ používa na podpisovanie”. Napr. do príslušného políčka v XML vpíše podpisovateľ svoje meno.
Palec Hore … toto umozni vstup konkurencie na vyarendovane pole … 
Ad.: “Ani ja, z čoho máš pocit že áno? O PODaaS v zákone nie je nič a nevidím potrebu tam v tejto súvislosti ani niečo pridávať/meniť.”. Vzniklo to z tohto.:
Poďme ďalej.:
Zjavne si ma len nepochopil. Nepotrebujem dovysvetľovať, čo by mal formulár robiť. Myslím, že sa v tom zhodujeme. Ja som uviedol príklad, ktorý sa pod tú “gumovú” definíciu podpisu “klikom” (na ktorú sa odvolal Jano a potom ty) v pohode “zmestí” a výsledok je úplne iný, než všetci chceme. Niečo na spôsob tvojho neskoršieho dôkazu sporom.
Ďalej.:
Keby si čítal-vykopíroval aj predošlú vetu, tak z nej vyplýva, že za ÚPPVII. A hlavne.: Ako toto súvisí s vecnou argumentáciou?
V eShope (a všeobecne v obchodnom vzťahu) je jasné, že niečo myslím naozaj vážne, až keď za to zaplatím. Vyjadrenie vôle zaplatením. Načo by tam bol ešte aj elektronický podpis? Interné procesy vo firmách nie sú primárne o vyjadrovaní vôle, ale o práci zamestnanca pre zamestnávateľa. Tu tiež nie je potrebný elektronický podpis. Atď.
Super, ja rovnako. Doplním ešte vecné kritérium, že ten kto vôľu vyjadruje, by mal mať (podľa možnosti danej alternatívy) čo možno najviac pod kontrolou prostriedok pomocou ktorého vôľu vyjadruje. Len aby sa nezabudlo.
Chápem, že dôvodov na optimizmus nie je veľa (nakoniec medzištátna interoperabilita asi nie je ten najväčší problém eGov implementácií - ani u nás), ale keďže si len relativizoval a neuviedol protiargument, tak sumarizujem.: Proprietárny klik bude interoperatilný takmer s nulovou pravdepodobnosťou. Pri elektronickom podpise (regulovanom cez eIDAS) je pravdepodobnosť výrazne vyššia. Zvyšok je len otázka porovnania jednoduchosti použitia, nákladov implementácie, možnosti a dopadov zneužitia, atď.
Výborne, tak sme si teraz len zopakovali, že eIDAS reguluje len od úrovene “pokročilého podpisu” a vyššie. Pod tým môže byť prakticky čokoľvek (viď tvoj príklad), ale eIDAS s tým nič nemá, neposkytuje žiadne usmernenie. A KEP sme sa zhodli (aj keď ten je naopak veľmi detialne regulovaný cez eIDAS), že je na mnohé služby “overkill”. Logicky sa AdES pre dosť služieb javí ak nie rovno optimálna, tak aspoň veľmi sľubná alternatíva (na to posudzovanie a porovnávanie, viď vyššie).
Aha, už vidím zdroj nedorozumenia. Tým že “k 1. je vyriesene v zakone” bolo myslené iba, že pri autorizácii kliknutím je v §23.1.a.2 predpísané kde to kliknutie má nastať - “použitím na to určenej funkcie IS prístupového miesta”, a teda netreba špekulovať či si túto autorizáciu používateľ služby PODaaS môže/má robiť u seba.
Ostatné je normálna diskusia ako by táto služba mala fungovať. Oficiálne návrhy za S.D je samozrejme to, čo Jano povie na PS. Technická realizácia autorizácie kliknutím s PODaaS súvisí iba voľne, nemusíme to miešať - diskusia k tomu s ÚPVII už niekoľko krát bola, rád budem pokračovať.
1 Like
Kratky zapis z dnes:
“Formular ako sluzba” resp. podanie ako sluzba.
- idealne API by bolo mam nieco podpisane KEP a poslem to do nejakej rury. Pride mi notifikacia o doruceni (takmer synchronne). Dorucenka trebars do schranky subjektu co to podpisal. Bol navrh aj do hocijakej schranky (kedze si viem aj na papieri napisat hocijakeho odisielatela)
- co sa tyka vizualizacie na centralnom mieste - tam ide len o pohodlnejsiu integraciu voci tretim stranam (aj OVM!) a nie nutne doveryhodnejsiu stranku.
Editovatelne formulare “revival”
- opat sa otvorila tema vyplnacej casti formularov kedze je vraj zo zakona potrebne aby sa dalo podanie spravit na akomkolvek pristupovom mieste (iomo napr.) a kvoli bezpecnosti to vraj nemoze byt uplne decentralizovane.
- navrh teraz znie, ze by sa k formularom robili nejake HTML frontend apps, ktore by boli staticke ale volali backendove sluzby cez api gw. oponoval som, ze to fixuje technologiu len na frontendove frameworky a nie je zrejme ci toto bude vobec v praxi potrebne. (channel-fit by sa mal robit)
- otazku bezpecnosti chapem, ale dnes ked na upvs su zavesene kadejake javascripty tretich stran, tak veru neviem ci toto ma zmysel.
Podania na upvs vs. dodrziavanie zakona
- dnes by mali vsetci (az na vynimky v zakone) poskytovat sluzby aj cez upvs resp. umoznit podanie cez upvs. nedeje sa tak a ked dnes podam nieco do schranky OVM, tak to moze skoncit tym, ze mam dorucenku a odpoved nepride. => hrozba sudom.
Dopytovka “drobne zlepsenia egovu”
- ako sa to bude obstaravat? (PRK nemoze byt, kto sa tam prihlasi do legacy?)
- otvorenie API by mala byt jedna z moznosti (napr. na financnej sprave)
eid - autentifikacia ako sluzba
- dnes to stat napriek deklaraciam roznych politikov po mnoho rokov neposkytuje pravnickym osobam. NASES to vie urobit MV mu to zakazuje, MV to zatial pokial vieme nikomu nedovolilo zaintegrovat. Predstavitel NASESu povedal ze to riesia s UPVII.
2 Likes
OMG! Radsej by sme mohli vylepsovat to co nefunguje.
Logika tejto “bezpečnostnej” úvahy je: Občan má dôverovať webu úradu (má si ho otvárať) a má sa vedieť ochrániť ak tam je bezpečnostný problém, ALE úrad nemôže dôverovať webu iného úradu a nedokáže sa ubrániť ak je tam problém. Súčasne platí, že úrady svoju bezpečnosť koordinujú a každý z nich vlastnú bezpečnosť garantuje.
Okrem toho:
- medzi prístupové miesta patrí aj “kontaktné centrum”, ktoré podľa toho čo má zo zákona robiť (§5.5 ZeGov) ani nevie spoľahlivo identifikovať používateľa, nemá mať ani prístup k jeho údajom, nie to ešte za neho robiť nejaké podania (btw. na kontaktnom centre majú teda “kvôli bezpečnosti” zakázané pozerať na web Žehry?)
- prístupové miesta sú aj “špecializované portály”, a teda že by na webe Žehry mali vedieť spraviť “za mňa” čo ja viem, žiadosť o preclenie dovozu jadrového materiálu? - v zákone rozhodne nič také nie je
- pokiaľ ide o IOM (nielen centrálne IOMO), zákon akože dnes prikazuje, že na každom z nich musia vedieť spraviť “za mňa” všetky podania v Žehre? pýtal som sa tuná na pošte - ťukali si na čelo…, imho toto je aj do budúcnosti nereálne (a v zákone nič také nie je, každá prevádzkareň IOM si vlastne môže zvoliť “aké služby poskytuje” okrem služieb povinných pre všetky podľa vyhlášky 25/2014 §4.1.b)
Kto šíri takéto fantázie a prečo mu to na PS žeriete? Určite nerozumie bezpečnosti a zákon o eGov čítal iba povrchne.
2 Likes
Klidek, toto je len zapis, nie stav mojej mysle po tom stretnuti. Mam voci tomu uplne rovnake vyhrady a dokonca tam viac krat padli. @anton-somora dnes si nam tam chybal, bolo to mimoriadne vyzivne.
Škoda, že som nemohol. Na strane druhej, po pravde diskusia na tieto témy (formuláre, iomo) je už únavná. Zdá sa mi, že už ide skôr o egá jednotlivcov ako o nejakú relevatnú ideu.
Ego to nebude. Vidím v tom snahu zachrániť pôvodný koncept iomo, ktorý nejako nefunguje.