Mobilné ID

Takže predsa konkrétne pokroky, ako odpoveď na naše dotieravé otázky týkajúce sa otvorenosti a participácie:

  • v piatok (17.7.) bude k mID pracovné stretnutie s odbornou verejnosťou, viď. pozvanka.docx, ale keďže pozvánka je na meno, zrejme tam prístup majú iba “zástupcovia odborných združení” (zasadzovali sme sa aby to bolo verejné, alebo aspoň režim prac. skupina), ak tu dáte nejaké otázky, spýtam sa ich tam

  • Peter Vrábel mi zaslal doteraz vypracované dokumenty k mID, ktoré na úrade našiel, dávam ich sem, v odhadnutom anti-chronologickom poradí, t.j. najnovšie (rozumej: asi najbližšie dnešnej realite) najprv:

2 Likes

Ak teda má niekto záujem ísť na to piatkové rokovanie, dajte mi vedieť.

Skoda ze som si toto vsimol az neskor :confused:

Akcia v piatok prebehla tak, že najprv dal veeľmi rýchly úvod Vrábel, potom bola prezentácia Nases+Globaltel, následne prezentácia DEÚS, potom cca. 30 min. dosť chaotická diskusia.

Nases má dokumenty ktoré som tu vyvesil vyššie, najmä “Dodatok č.8”, ktorý však nie je podpísaný. Fakt nechápem ako je možné, že sa mID automaticky ide obstarať dodatkom, najmä v stave keď je to evidentne nová vec ktorú doteraz ÚPVS nerobil a oficiálne sa Nases snaží vymaniť z vendor-lock stavu. Škoda že na stretnutí nebol bývalý riaditeľ Nases a GR sekcie informatizácie, k tomuto by bolo o čom s nimi hovoriť. Globaltel zrejme už nejakú časť riešenia (ktoré nie je zatiaľ oficiálne objednané) má naprogramovanú, z prezentácie nebolo jasné akú. Prezentovali prepojenie na viaceré iné komponenty na ÚPVS, taktika GT -všetko je v jednej neoddeliteľnej kope- je známa.

DEÚS deklaroval, že ich riešenie je už v produkčnej prevádzke, zrejme je to táto appka: https://play.google.com/store/apps/details?id=sk.mdeus.mid
Riešenie funguje iba so službami Dcom. Ak som správne pochopil, prepojenie na ÚPVS na niečom zamrzlo (nebolo vysvetlené na čom). Ešte niečo doriešujú s biometrickou registráciou (použije sa tá istá ako pri karanténovej appke od Innovatrics), následne začnú robiť publicitu. Som fakt zvedavý na reakciu MIRRI.

Na celej akcii nepadlo ani slovo o cenách/nákladoch, či už na vývoj, ani na prevádzku. Škoda.

Nemám chuť tu opisovať detaily prezentácií, najmä keď viem že všetky tri strany si to tu čítajú. Týmto všetkých pozdravujem a povzbudzujem ich k pokračovaniu diskusie tu, napr. môžu vyvesiť svoje prezentácie sami a vyzdvihnúť silné stránky svojho prístupu.

Za mňa toto nebolo o porovnávaní “dvoch možných riešení”. Čakal som update k tomu čo nám ÚPVII odprezentovalo v decembri a odpovede na otázky, ktoré tam padli - toto som nedostal. Nie je ani jasné zadanie, čo vlastne má mID robiť / čo chceme dosiahnuť.

Magický trik, ktorým sa z prístupu, “v DEÚS sa objedná a naprogramuje a následne postúpi do Nases” (tak to bolo v 2018 prezentované a uzatvorené zmluvy) stali “musia byť 2 štátne riešenia: DEÚS a Nases” (v 2019) nebol vysvetlený, a nie je mi ani jasné ako to vlastne teraz MIRRI chce. Detto ako sme sa k pohľadu v 2018 vlastne dostali.

V podstate obe org. zvolili podobný postup: autentifikácia je level “pokročilá” a autorizácia kliknutím - v autorizácii kliknutím pre preukázanie že autorizácia prebehla (napr. ak sa príslušný podklad zasiela medzi organizáciami) sa vyrobí (automaticky na pozadí) bližšie nešpecifikovaná doložka, ktorá sa spolu s dokumentami podpíše pečaťou úradu kde sa autorizácia vykonala a celé sa to vloží do asic kontajnera. Asap by sa k tomu mal prijať štandard, netreba na nič čakať, aj tak potrvá aspoň pol roka, kým to úrady budú vedieť spracovať.

Kucer stretnutie uzavrel s tým, že do konca augusta si MIRRI “spraví predstavu ako ďalej” a dovtedy máme čakať. Toto počúvam už pol roka, len termín sa posúva.

Za mňa celú spleť otázok ktorá sa “okolo mID” vždy točí treba rozdeliť na samostatné témy nasledovne:
1. Použiteľnosť webov a služieb z mobilných zariadení

  • toto je v podstate téma “multikanálový prístup”
  • sem patrí aj otázka či sa majú vyrábať appky, alebo responzívny dizajn
  • rovnako sem patrí otázka “schránka na ÚPVS” a ako ju spraviť dobre použiteľnou - špeciálne k tejto téme by som dodal, že a) veľká časť problému sa vyrieši ak si používateľ sám môže nastaviť automatický redirect na svoju mailovú adresu b) spravme k schránke jednoducho použiteľné API c) schránka ako ústredný bod komunikácie s verejnou správou je presne ten anachronizmus papierového sveta ktorý chceme opustiť
  • detto sem patrí otázka “ÚPVS na mobile” - kým pozeranie schránky na mobile zrejme každý považuje za dobrý nápad, prerábať “všetko” na mobilné zariadenia, napr. generické zobrazovanie/vypĺňanie formulárov považujem za dosť otázne a treba dobre zvážiť hodnotu za peniaze. Obzvlášť prerábať komponenty na prácu s el. formulármi, ktoré mi pripadajú snáď až úmyselne spravené tak zložito, aby to nikto okrem 1 dodávateľa nevedel. El. formulár je rovnaký prežitok z papierového sveta ako schránka.

2. Autentifikácia a autorizácia všeobecne

  • otázka ktoré autentifikačné schémy majú byť podporované centrálne a za akých podmienok
  • ako bolo na stretnutí povedané, dnes zrejme legislatíva skoro umožňuje, aby ktorákoľvek lokálna AA schéma bola prehlásená za centrálnu, viď. §21.6 z.305/2013 - príslovku “skoro” som dal, lebo v tom § vidím len použitie pre ÚPVS, nie pre ostatné prístupové miesta (ale rád si to nechám vysvetliť)
  • asap vydať štandard pre preukazovanie autorizácie kliknutím
  • téma “register autentifikačných certifikátov”, ktorý celý ja považujem za zbytočnú komplikáciu (v legislatíve) neslúžiaci už pôvodnému účelu
  • téma “federačný hub”, ktorým už IAM ÚPVS de-facto, keďže je k nemu pripojených cca. 20 id. providerov (SK eID a alt.auth. a všetky eIDAS notifikované schémy)
  • keď sme pri eIDAS, treba vyriešiť aby naša implementácia nebola iba Potemkinova dedina (teraz je), ale po prihlásení ne-SK schémou vedel občan aj reálne nejaké služby použiť
  • SK úrovne autentifikácie (sú 4) prerobiť úplne na eIDAS úrovne (sú 3)
  • oboznámil som sa s plánovanou “veľkou” legislatívnou zmenou v oblasti autorizácie, mám na ňu jasný názor a argumenty, ale počkám si keď sa k tým dokumentom dostanem oficiálne a bude (snáď) priestor na odbornú diskusiu

3. Ktoré služby je možné použiť s auth. SK úroveň 3 / eIDAS úroveň “pokročilá” + autorizácia kliknutím

  • treba si uvedomiť, že podľa zákona už dnes musia všetky služby akceptovať túto úroveň (okrem prípadov vyžadujúcich osvedčený podpis a zopár špecialít)
  • asap spraviť zoznam prioritných služieb kde ideme dosiahnuť zmenu, aby ich implementácia podporovala túto úroveň
  • očakávam, že toto bude viesť MIRRI
  • netreba na nič čakať, otázky “či má byť skôr mobilná autentifikácia alebo el. služba” sú pasé, viď. už dnes pripojené eIDAS schémy, z čoho sú minimálne 3 plne mobilné

4. OpenAPI

  • API GW, prepojenie cez OAuth
  • vytvorenie / dostupnosť API na služby
  • jednoduchosť použitia OpenAPI
  • pripojenie mID, resp. prepojenie IAM ÚPVS na OpenAPI komponenty

a konečne 5. “mobilné ID” ako nový centrálne podporovaný spôsob autentifikácie, po oddelení vyššie uvedených tém v úzkom definovanom zmysle.

4 Likes

jo … furt som nevedel ten svoj pocit sformulovať …a toto je presne ono. Len … vsetky doterajsie procesy, sw komponenty a legislativa su na toto nastavene … neviem si predstavit (ale to moze byt len moj problem) ako toto zacat menit …

2 Likes

Pisal som aj inde, ale dam aj sem: Mnohi v SOIT-e by ohladome celeho eID uvitali tu moznost ci moznosti, ktore by zabezpecili dostupnost zdrojovych kodov pod EUPL, minimalne vsetky klientske aplikacie, idealne aj “back end” a pod.

Zdovodnenie:

1 Like

Ja dodam, ze tato otazka je uz pomerne davno zodpovedana v SP Multikanalovy pristup. Appky sa NEMAJU vyrabat pokial na to neexistuje naozaj velmi dobry dovod (napr. nutnost pouzivat nativne funkcie, ktore inak dostupne nie su, resp. specialny usecase co toto vyzaduje) a aj to len v pripade, ze 1) existuje responzivna verzia webu 2) existuje open api.

Len par poznamok, lubor sa teme venuje dlhodobo a tak ide skor o otazky.

  1. Ak spravne chapem situaciu, tak existuju riesenia a staci ich kupit, doplnit HW a riesenie moze byt pomerne rychlo , a keby neboli volby tak by to uz bolo.

Použiteľnosť webov a služieb z mobilných zariadení

  • Toto je sekundarny problem, samotne MeID to len umozni riesit, debata v tejto oblasti je ciste akademicka, bez uvolnenia penazi nikto nic nebude robit

Autentifikácia a autorizácia všeobecne

  • Podobne, urcite dolezite ale nie podstatne v tomto okamziku. Ak sa dohodnu zmeny, tak to vyvola zmeny ale cakat na to znamena cakat nejasnu dobu, pouzitelne riesenie teraz ma vyssiu hodnotu ako dokonale za par rokov.

OpenAPI

  • jasne dolezite ale znovu by to nemal byt showstopper, ale z dokumentov nie je jasne ci to vobec je problem, pripadne ci to je len otazka penazi alebo niecoho ineho

Centralny bod schranky : kazde riesenie to musi zobrat ako dane, moze sa len DOPLNIT aj iny scenar. To su lahko pochopitelne limity.

Neviem ci by bolo takto rezolutne zabit nativne aplikacie hned v zaciatkoch. Su dovody kedy sa aplikacia da pouzit a je velkym pomocnikom.
Napr. spracovanie rozhodnuti, vytvaranie dolozie o autorizacii a spravoplatnovanie rozhodnuti je prikladom toho ze z legislativy vyplynie nejaky postup. My sice mame komunikacny system vytvoreny ale webove rozhranie nedokaze rozumnym sposobom pokryt potreby takze nakoniec prideme do stavu kedy by to najradsej zabalili do obalok a poslali rucne. A bolo by to hotove 5x rychlejsie ako cez schranku. Toto je miesto kde sa vyuziva velke mnozstvo volani (overit schranu na aktivaciu, vzdy podpisat, rozparsovat podpis ak schraka neni aktivna, neodosielat v takom pripade a posunut registratre) nativna aplikacia ktora by zaistila aj podpisovanie aj overovanie aj odoslanie by v tomto pripade velmi pomohla a vedela by vyuzit aj HW vykon mobilneho zariadenia.

Nativne aplikacie maju prave v takychto situaciach, ktore sa niekedy nedaju do predu odhadnut svoje miesto. Dokazu uzivatelovi si hromadne pripravit v tomto pripade rozhodnutia a hromadne ich spracovat cast pomocou schranky a cast pomocou aplikacii a HW v organizacii.
Napr. s tymito rozhodnutiami sme narazili na skoro neprekonatelnu prekazku, kedy sa neda cinnost ani z polovice urobit tak efektivne ako v starom papierovom svete…

1 Like

Priznam sa, ze vobec nerozumiem ako sa toto tyka nativnych mobilnych aplikacii. Skus mi este raz objasnit ten scenar, kde ste zistili, ze je nativna aplikacia lepsi napad ako normalna webova responzivna?

No v tom ze 90 percent urobim offline v zariadeni a do schranky uz odoslem hotovu vec,
Cize nativna aplikacia bez potreby zatazovat statny server vytvori povedzme sto rozhodnuti. Tieto podpise. A server kontaktuje len v suvislosti s tym ci ma pre dane uri aktivovanu schranku. Ak nema, uz server nekontaktuje nema dovod. Takze rozparsuje podpis z neho vytiahne udaje potrebne pre vyhotovenie dolozky o autorizacii a vygeneruje dolozku o autorizacii. Schranku uz nikdy pre toto rozhodnutie nepouzije. Rozhodnutie aj dolozku vytlaci a odosle do systemu registratury.
Po nadobudnuti pravoplatnosti vygegeneruju dolozku pravoplatnost a/alebo vykonatelnosti a znovu vsetko vytlaci a ulozi do registratury.
V takomto pripade som iba raz zavolal funkciu UPVS aby som zistil ci ma adresat schranku aktivu.
Ak by som uvazoval ze by som kontrlou tych 100 rozhodnuti urobil na raz, tak hromadny podpis na zadanie 1x pinu mi podpise 100 rozhodnuti a ja si dam kavicku.
Ak by sa zistilo ze adresat ma aktivovanu schranku tak pred odoslanim do registratury este zaistime odoslanie do schranky upvs, cize vtedy by doslo k dalsiemu kontaktovaniu servera ale iba u tych adresartov, ktori maju schranku aktivnu. Cize tu ja vidim vyhodu nativnych aplikacii a nebolo by podla mna dobre im zasekat cestu. Ich vyhoda je poskytnutie vykonu vlastneho zariadenia pre “dobro statu” a moznost nasobne ulahcit a automatizovat pracu uzivatelovi.

Hovorime o nativnych MOBILNYCH aplikaciach hej?

Napr. v tablete

Ta cesta nie je zasekana, ak sa najde scenar kde nativna appka dava zmysel, tak su tam vynimky. Napr. offline rezim je celkom ok dovod aj ked scenar co popisujes je podla mna dost uzky. “Poskytovanie vykonu” mi pride trochu smiesny dovod, sorry.

Dovod preco sa to do strategickej priority dostalo bol vsak iny (ako uplne zasekat cestu nativnym appkam). Realny stav bol ten, ze nativne apky na dve platformy sa robili/planovali snad do kazdeho statneho projektu bez toho, aby vobec sa zamyslalo nad tym, ze ci to ma pre niekoho zmysel.

To som napisal preto lebo teraz ked ides urobit jedno rozhodnutie, tak ten system ktory je jednou nohou na spadnutie, ledva ledva funguje, tak tam otvoris chranku idu data, vyberes ze ides robit rozhodnutie idu data (nie male lebo odozvy su aj sekundy) , otvori sa firmular idu data, vyplnis formular ides podpisat stahuje sa formular a potrebne data pre podpisovac, podpises podpisane data cestuju na server, ides hladat schranku viacero volani a vyberies konecne schranku, ale je neaktivna. Aby si mohol urobit autorizacnu dolozku, musis zase stiahnut acely asik k sebe aby si z neho dostal spracovatelne udaje, inak si mozes opisovat z obrazovky. Takze preto som spomenul ze mobilne zariadenie venuje vsetok tento vykon v prospech statu.
Mobilna apka by v tomto pripade iba zistila ci uri ma schranku aktivnu. Ping ato je vsetko… A ten system by nebolo treba takto zatazovat pri kazdom jednom rozhodnuti. Keby tam boli odozvy v milisekundach alebo do jedna dve sekundy nevadi ale niekedy su strasne dlhe vidiet ze ten system sa trapi, ze je zle navrhnuty

Ano prave toto riešíme a o par týždňov bude riešenie ktore toto bude pokrývať hromadne. Na Win/Mac/Lin… ale neviem si predstavit robit rozhodnutia a dolozky na mobile ci tablete … hromadne. To je urdnicka praca, na ktoru ci chces , ci nie potebujes pocitac s velkym monitorom. …

je si treba uvedomit ze POVODCOM rozhodnuti je nejaky agendový systém s databázou údajov.
Ak tento existuje aj v mobilnmej verzii, alebo aspon s ciastocnym mobilnym klientom tak chapem … ale dnes su standardne agendove apky (obci / miest /skol ) typickou win aplikáciou, alebo webovou stránkou ako DCOM .

Ok na mobilnych zariadeniach mame obmedzeni zatial viac A to nas nuti nneuvazovat nad nimi. Ale je to skoda lebo aj oni maju svoje miesto v densnom svete. Zatial kvalifikovany podpis na nom neurobime.
To bol iba priklad ze mobilne aplikacie maju urcite moznosti v spracovavani sprav v off-line rezime a webom komunikovat az ked mam pripravene. Napr. Hromadne operacie ktore si predpripravim a pod… Rozhranie tabletu uz celkom vyhovuje roznym a procesom a modulom z registratury napriklad workflow kedy posldnym krokom wf procesu je napr odoslanie schaleneho rozhodnutia do schranky ziadatela, teda akesi prepojenie procesu spracovania uradneho formulara s konecnou fazou tj. jeho odoslanim do schranky, alebo hromadne spracovanie určitych dokumentov, formularov a pod. Moznosti by sa nasli ia ked sa to zavrhne tak vyvoj touto cestou nepojde a to si myslim ze by bola skoda.
Ano uradnici budu vacsinu riesit zo svojho desktopoveho systemu, ale ten tablet ma tiez svoj vyznam, a na drobnosti aj mobilny telefon. Ale uz sa nam objavuju aj ludia ktoti si nurcite ulohy zvykaju robit z tabletu alebo mobilneho telefonu.

  • fáza “prezentácia riešení” prebiehala podľa všetkého na ÚPVII v 2018-2019, vraj všetky firmy čo majú záujem v tejto oblasti (ja osobne viem cca. o 5) mali prezentáciu, neviem o žiadnom dokumentovanom výstupe z tohto, ani možnosti zúčastniť sa (od začiatku sme žiadali aby takéto veci boli prístupné)
  • bez ohľadu na môj názor je dnes riešenie DEÚS dodané a funkčné

Toto nie je debata, ale tretí rok povinnosť. … na ktorú skoro všetci (vrátane ÚPVII) rezignovali

Úplne súhlasím že riešiť v legislatíve nejaké “nové” AA veci nie je teraz dôležité. Všetky zmeny sú nadlho, štandardy preto treba vydať čím skôr.

Iste, toto je samostatná téma, dôležitá a sú tam styčné body s mID, ale nie je to na sebe nijako závislé.

Ono by bolo zahodno celkovo prehodnotiť pohľad na “centrálnu schránku”. Najmä keď sa tu zhusta rozvíjajú témy typu digitálna transformácia. Ale zatiaľ sme (ITčkari) skôr preukázali schopnosť rozmýšľania do šírky (aka. čo by kde ešte bolo treba prerobiť) ako do hĺbky (veci ktorých sme sa chytili spraviť poriadne).

tu by som len doplnil ze toto sa uz udialo priamym dodatkovanim v datacentre (a takisto to bola pre DEUS vec ktoru dovtedy nerobil ale tam sa ani netvaria že sa snažia vymaniť z vendor-locku) a este prepredchadzajuci riaditel NASES a datacentra vsetko zahadne stihli v jeden deň ZL-2013-19 | Centrálny register zmlúv 150-2018/453-14696 | Centrálny register zmlúv,

  • žiadne zdrojove kody
  • žiadne EUPL licencia,
  • vendor lock s tým správnym vendorom
  • konfilkty zaujmov absolutne nikoho nezaujimali @Kysela

teraz sa už len všetci snažia z tejto situacie vykorčulovať. Proste nad rozliatym mliekom darmo plakat, kricat bolo treba vtedy, ale vtedy bol ten najlepsi riaditel NASES…