Mobilné ID

Včera bolo k teda tejto téme stretnutie na ÚPVII, dokument bol odprezentovaný, plus 1 nový slajd - časový harnomogram. @kyselat môžeš sem prosím dať tú prezentáciu?

Diskutovalo sa najmä

  • ako má fungovať spolupráca s “komerčným sektorom” - využitie mID (za mňa skrátka zapojenie do štátneho SSO) aj predpokladané zapájanie novýhch ID providerov do eGov (toto je zatiaľ asi skôr hrubá predstava)
  • úrovne autentifikácie / autorizácie - Frič/ITAS uviedol, že “na ÚPVII sa pripravuje” nejaký nový plán na nové rozčlenenie úrovní autorizácie “aby sme sa odviazali od analógie s papierovým svetom” (za mňa som z tohto trocha zdesený, nechápem aká je na toto potreba a čo je cieľ)
  • načo majú byť 2 schémy “DEUS a Nases” - nedostal som žiadne rozumné argumenty, iba veci typu “lebo DEUS nie je plne štátna organizácia”, na otázku k zmluvám Posam-DEUS-Nases čo sú linky aj tu vyššie uviedol GR Nasesu že “právna analýza vyhodnotila, že nie sú pre Nases záväzné a môžu sa rozhodnúť či podľa nich pôjdu”… asi ani netreba komentovať

K návrhu mID existuje vraj technický návrh a oba dokumenty majú ďalej prejsť PS Lepšie služby.

Tak asi aj zalezi na urovni autorizacie. Napriklad presne tato sluzba je v DCOM na level 3

Registrácia prebehne online na základe údajov predložených žiadatelom a ktoré sú podpísané zaruceným elektronickým podpisom.

Predokladam, ze toto sa bude musiet zmenit.

…fuu na dan za psa potrebujem dva doklady, osobny kontakt s uradnikom, … na com tam ficia…? Doteraz som si myslel, ze ak sa dan zaplati, tak statu/obci je jedno kto to zaplatil…

Medzicasom v komercii.

Another cool aspect of WebAuthn is that it opens the door to new kinds of authentication devices and you no longer need to own special hardware keys. You’ll be able to use your phone or laptop and authenticate with a PIN, or use a fingerprint reader or facial recognition. For example, you can use your Android phone’s fingerprint reader in Chrome, Apple’s Touch ID in Chrome for macOS, and facial recognition, fingerprint reader or PIN via Windows Hello in Edge. Of course, you can also use specific security keys like Yubico’s YubiKeys, which is what I use. Older keys based on the U2F standard work too as WebAuthn is backwards compatible with U2F authenticators, so if you have one of these, you can register it in your Basecamp account as well.
https://m.signalvnoise.com/basecamp-now-supports-security-keys-for-two-factor-authentication-thanks-to-webauthn/

1 Like

Mozno nastal cas, tieto temy oprasit. Mozno dnes by uz nases mohol inak pozerat na tuto temu…

1 Like

Po ďalšom polroku čakania, výmene vedenia úradu atď. - sme sa stále nikde nepohli.
Ale mobilné ID má na ÚPVII nového projektového manažéra - je to Peter Vrábel.

V komunikácii s ním sme sa dozvedeli zhruba nasledovné:

  • bola vypracovaná prezentácia (nevideli sme ju), v akom sme stave ako sa vieme pohnúť vpred - aké máme možnosti
    • existujúce subjekty, ktoré mID prezentovali v minulosti a počítalo sa s nimi ako s dodávateľom
    • vrátiť sa na začiatok - dôkladná analýza, scope of work, následné hľadanie dodávateľa, čo je najpomalšie riešenie
  • všetky cesty majú klady aj zápory. teraz bude musieť vedenie spraviť politické rozhodnutie či sa chce pohnúť veľmi rýchlo vpred a z toho budú vyplývať dodávatelia alebo ideme pomalšou cestou a paralelne pracovať na legislatíve
  • padlo rozhodnutie začať pracovať na legislatíve, nápomocný bude p. Frič a p. Kaľavský - ide o zmeny aby sa trh otvoril, autentifikácia/autorizácia… harmonogram prípravy legislatívy je predpokladaný na 3 mesiace, následne medzirezortné pripomienkovanie

Žiadne konkrétne kroky smerujúce k participácii - napr. prebratie týchto vecí (vopred) v pracovnej skupine, alebo aj len informovanie širšej odbornej verejnosti - sme sa ani na priame otázky nedozvedeli. Takto si novú úroveň participácie nepredstavujeme.

Za nás sme dali vedieť, že u p.Friča v tejto veci vidíme konflikt záujmov, ešte silnejší ako u Tomáša Kyselu, pri ktorom sme na to tiež upozorňovali.

5 Likes

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.