Mobilné ID

Plány sa postupne upresňujú.
Stanovisko Nasesu k stanoviskám S.D a ITASu: Stanovisko-NASES-k-navrhom-odbornej-verejnosti-k-teme-mobilnej-autentifikacie-a-autorizacie.pdf (1.0 MB)

Zverejnené na
https://www.nases.gov.sk/projekty/mobileid/index.html a
https://www.slovensko.sk/sk/inovacie-slovensko-sk/slovensko-sk-mobile-ID

Dokument má 21 strán (!) vcelku odbornej argumentácie, vidno v ňom smer uvažovania o eIDAS, A/A, AC, SSO, OpenAPI. Oplatí sa prečítať (!).
Vybratých zopár bodov:

  • nateraz bude pri aktivácii vyžadované eID
  • podporovaná bude autentifikácia v úrovni pokročilá/eIDAS
  • plne mobilný scenár bude podporovaný od začiatku
  • AC je pre mID možné použiť, lebo …šikovné právnické úvahy a sú popísané plány ako sa AC má meniť do budúcnosti
  • Nases buduje “centrálny autorizačný komponent” a k tomu dáva aj dosť chabé odôvodnenie
  • použitá bude “autorizácia kliknutím”, Nases konštatuje že jej zmyslom je “odbremeniť používateľa služby od potreby vynakladania osobitných nákladov ma obstaranie si a udržiavanie prostriedku autorizácie” a “zveriť vytvorenie a kontrolu nad prostriedkom autorizácie „do rúk štátu“ s tým, aby nebola potrebná žiadna ďalšia regulácia konkrétnych technických podrobností s tým spojených”
  • ako technologické riešenie autorizácie Nases evidentne preferuje AdES podľa eIDAS, ale “Parametre ako finančná náročnosť, používateľská prívetivosť a miera jednoduchosti adaptácie existujúceho eGov prostredia na nový spôsob autorizácie by mali byť predmetom posudzovania pri konkrétnych kandidátskych riešeniach”
  • nepredpokladá sa riešenie pomocou nového typu kvalifikovanej dôveryhodnej služby podľa eIDAS
  • o kvalifikovanej službe elektronického doručovania sa môžeme baviť do budúcnosti, ale Nases nateraz s tým neráta
  • autentifikácia a autorizácia pomocou mID má byť použiteľná pre 3. strany, vrátane “redukovania povinností pri integrácii”
  • mobilná appka má byť OpenSource (okrem výnimiek, ktorými “môžu byť bezpečnostné mechanizmy”)
  • detailný návrh mID bude prezentovaný na PS Lepšie služby “počas jesene”

Ak si nájdem čas, dám k tomuto detailnejšiu odpoveď. Napr. sa nijako neráta s prebiehajúcou novelov ZeGov, v ktorej sa niektoré predpoklady zmenia, ba dokonca si môžeme (snáď spoločne) dohodnúť aký má byť nový stav.

3 Likes

Nieco sa dostalo do IS DCOM. Zvlastne, ze sa toto neriesi centralne.

https://www.uvo.gov.sk/vestnik/oznamenie/detail/398642

Opis úprav

Predmetom dodatku sú doplňujúce služby, ktorých predmetom je zabezpečenie mobilnej verzie služby autentifikácie osôb a autorizácie dokumentov prostredníctvom aplikácie v mobilnom telefóne. Tým sa odstránia bariéry a umožní sa občanom komfortnejší prístup k elektronickým službám.

Oficiálne odôvodnenie, prečo sa to robilo ako dodatok:
Opis ekonomických a technických dôvodov a nevýhodnosť či znásobenie nákladov, ktoré bránia zmene dodávateľa: Zmena poskytovateľa nie je možná z ekonomických ako aj technických dôvodov, najmä s ohľadom na dodržanie kompatibitlity a interoperability IS DCOM. Zmena poskytovateľa by verejnému obstarávateľovi spôsobila významné ťažkosti a podstatnú duplicitu nákladov.

To je samozrejme nezmysel. Súťaž mala byť.

Príslušná zmluva: https://www.uvo.gov.sk/vyhladavanie-dokumentov/document/3020764/content/906599/download
(Uzatvorená 24.10.2018)

Zjednodušene povedané, dodávateľ

  • “poskytne sublicenciu na používanie softvéru ANZU”, čo je back-end a appka do mobilu. Appka už je hotová a poskytuje sa zadarmo (viď. zmluva I.1.1.1). Sublicencia sa “postúpi na Nases” (II.2.7). “Objednávateľ nezískava žiadne práva ku zdrojovému kódu ANZU.” (II.2.9)
  • za 300K Eur bez DPH (V.5.1) sa dorobí do DCOM zmena aby sa toto dalo používať (I.1.2.1) a “zmena DCOM voči systémom Nases” (I.1.2.2), tu sa naprogramujú špecifické front aj back-end komponenty a všetko čo treba aby to bežalo v Nases, k tejto časti bude odovzdaný zdrojový kód, má sa používať čo najviac štandardizované API a jednotlivé komponenty “majú byť čo najjednoduchšie nahraditeľné”
  • “poskytuje služby technickej a prevádzkovej podpory” (I.1.2.3) za 196K Eur bez DPH ročne, splatné po polrokoch, vopred, začiatok po uvedení do rutinnej prevádzky (VI.6.1-5)

Back-end komponent a jeho servis sa následne prevedú, vrátane zmluvného vzťahu, na Nases “alebo iný subjekt verejnej správy, ak to bude potrebné pre poskytovanie e-Gov služieb…” (XII.12.2.2).

Celé “riešenie bude umiestnené a prevádzkované v infraštruktúre NASES-u (UPVS) z dôvodu eliminácie dodatočných nákladov na migráciu.” Toto je ozaj priamo napísané v špecke (p16, 1. strana).

Zadanie sa síce vágne odvoláva na zákon o eGov, ale v špecifikácii sa priamo hovorí o implementácii “elektronického podpisu” “úrovne zdokonalený podpis” podľa eIDASu, príslušný scenár sa volá “Podpisovanie smartfónom”.

Produkt ANZU “vlastní a prevádzkuje” firma mTrust,s.r.o., od svojho vzniku je v strate, ktorá každoročne prevyšuje tržby (viď. Finstat, 2010-2017). Je vlastnícky prepojená s firmou PoSam.

V špecifikácii sa hovorí o “pripravenosti na plne mobilný scenár”, nie je mi jasné či to po dodaní už má normálne z mobilu fungovať alebo nie.

Na diagramoch je aj komponent “CA”, ale “Služby certifikačnej autority pre elektronické podpisy” sú uvedené ako “Optional”, tak to naozaj neviem čo z toho je súčasť dodávky.

2 Likes

Co na to UVO? Nevnima takyto dodatok ako umele zuzenie trhu. BTW nikdy by som neveril, ze Peter Skodny bude podpisovat taketo dodatky…

1 Like

UVO toto zjavne neriešilo.

Btw. tu je celá zmluva na DCOM, ku ktorej je toto dodatok: https://www.crz.gov.sk/index.php?ID=1249582&l=sk

Sublicenčná zmluva, ktorou sa ANZU prevádza na Nases: https://www.crz.gov.sk/index.php?ID=3785170&l=sk
Uzavretá podľa CRZ taktiež 24.10.2018, zverejnená až 3.12.2018, podpísal ešte Lukáš Sojka.

Skrátka od začiatku bolo jasné, že toto sa robí pre Nases.

IJ ÚV SR neboli zaslané relevantné podklady na vyhodnotenie plnenie opatrenia. Podľa informácií NASES a ÚPPVII bol projekt mobilného ID koncom roku 2018 pozastavený s tým, že nie je jasné, kedy bude mobilné ID ako alternatívny spôsob overovania identity a prihlasovania sa do elektronických služieb štátu zavedený do používateľskej praxe.

Vid Implementačná jednotka

Tak sme o pol roka ďalej. Toto prišlo z ÚPVII:

MobilneID_PodkladPrePrezentaciu_v2_final.pdf (700.8 KB)

Viacero vecí tam zmysel fakt nedáva, najmä hypnóza že “aby bolo možné FA v plnej miere demonštrovať”, musia sa vybudovať dve autentifikačné aplikácie “DEUS a NASES”. To je pravda asi tak, ako že musíme vyrobiť minimálne dve eID, aby sa dala demonštrovať plná funkčnosť IAM ÚPVS.

Ak by sa to aj hneď podarilo, podstatná časť obyvateľov bude mať v mobile 2 konkurenčné štátne appky, ktoré robia to isté. Určite to bude lacnejšie a celkovo lepšie fungujúce.

Pritom celé toto mýtické “FA” je stále iba mierne rozšírenie toho istého IAM ÚPVS, ktoré už teraz federáciu robí, viď. notifikované schémy pod eIDAS.

V piatok mi jeden kamarát s vážnou tvárou vysvetľoval, ako Globaltel má plné právo požadovať že on bude robiť mID, lebo “tak to bolo biznisovo dohodnuté”. Stačilo to tak aj napísať do dokumentu.

Keďže na ÚPVII je 20 pracovných skupín, tak namiesto toho aby sa v niektorej z nich téma mID riešila, na stredu je naplánované stretnutie “zástupcov IT združení s vedením sekcie”, k tejto téme…

2 Likes

Prebehol som ten dokument:

Najprv: Nerozumiem, co take strasne tajne tam je, ze sa toto nemohlo uz davno prebrat na PS.

Služba Pokročilý elektronický podpis v prvej fáze nebude súčasťou portfólia ÚPVII MobileID, pokročilý elektronický podpis môžu jednotliví poskytovatelia mobilných identít ponúkať pre komerčné subjekty ako svoju vlastnú dodatočnú službu.

Fajn.

Plánujeme spustiť mobilnú aplikáciu ,Mobilná elektronická schránka“ a pomocou mobilu sprístupniť aj niektoré veľmi populárne služby miest a obcí.

Opatovne davam do pozornosti strategicku prioritu multikanal, kde sa jasne hovori, kedy moze a kedy sa nemoze robit mobilna nativna aplikacia. V skratke, pokial neexistuje responzivna alternativa pre schranky + API, tak sa nativnych aplikacii nema stat co chytat. Toto je dokument z dielne UPVII, ktory presiel pripomienkovanim, bol schvaleny radou vlady, je to best practice z UK. Ak UPVII/NASES si robia z vlastnych strategickych dokumentov trhaci kalendar, tak nemozu ocakavat, ze to iste neurobia aj ine OVM.

ak bude v schránke uložený prevodný príkaz, používateľ’ ho môže zaplatiť’ priamo v mobile.

Opatovne davam do pozornosti SP multikanal a dalsie dokumenty, ktore hovoria, ze v nativne aplikacii moze byt nejaka funkcionalita len ak existuje API. Na taketo platby API neexistuje, NASESu sme toto niekolkokrat hovorili, p. Kmetovi dokonca osobne. Tymto stat ziskava monopol na funkcionalitu, ktoru trh chce a stat mu ju akosi nechce spristupnit. Taktiez plan je vsetku funkcionalitu pristupnu cez GUI vypublikovat cez API (t.j. na co sa da kliknut, musi byt aj cez API). Toto je tu porusene.

Scenare v dokumente (prihlasovanie cez mobil pri praci cez desktop, prihlasovanie a praca na mobile) su vsetko presne usecases z webauthn. Cize je na zvazenie, ci toto rovno nevyuzit. Jediny blocker (resp. kde to treba riesit) je zatial iOS, ktory nema nativny scenar bez hw kluca. android/chrome toto uz vedia nativne.

Kedze sa tu neriesi ziadne kvalifikovane/pokrocile podpisovanie, tak by asi malo uplne stacit aj riesenie dnes dostupne v android telefonoch (webauthn). Ci?

Kancelaria lepsich sluzieb: Toto uz existuje?

Z pohľadu pridanej hodnoty komerčného prevádzkovateľa identít je pre štát zaujímavý jednoznačne počet už aktívnych mobilných identít komerčného prevádzkovateľa. Nemá zmysel sa zaoberať prevádzkovateľom, ktorý má síce technologicky kvalitné riešenie ale nemá v systéme aktuálne žiadnu identitu.

Toto dava asi zmysel z pragmatickeho hladiska, avsak trochu bariera pre vstup na trh a jednoznacne by sme si mali ustrazit, aby toto neznamenalo, ze nebudu vediet zapojit novi hraci. Napriklad aj statne riesenia (NASES/DEUS) maje dnes nula identit vyuzivajucich ich mobilne riesenie. Ako prejdu tymto kriteriom?

2 Likes

K tomuto by som dodal, že ak správne čítam zákon, zatiaľ sa toto nedá robiť vôbec. A neviem si celkom predstaviť, ako sa do toho zákona kritérium “počet už aktívnych identít” dostane. Prirodzené kritérium je “ten kto prejde potrebnou štátnou byrokraciou”, čo už aj doteraz odfiltrovalo absolútnu väčšinu romantikov pri úplne všetkom.

Co to je ten Pokrocily elektronicky podpis?

To je nazov podla eidas.

Ten sa ale oficialne vola Zdokonaleny. Tak by mozno bolo dobre ze ten kto sa pusta do realizacie tohoto projektu by si mohol aspon precitat legislativu v tejto oblasti…

2 Likes

Veď o to ide, nie? Monopol štátu = monopol dodávateľa tej služby (lebo zatiaľ štát si všetko outsourcuje)

K dokumentu moje poznámky:

  • Dokument rieši mnohé zložité a odborné témy. Má byť detailne prerokovaný v pracovných skupinách ÚPVII. Takto to bolo aj prisľúbené a žiadame o to pred akýmkoľvek jeho schvaľovaním, alebo vykonaním investícií z neho vyplývajúcich.

  • V dokumente sa všade používa nevhodný termín “podpisovanie”. Treba ho nahradiť za “autorizácia”, keďže tá sa dá vykonávať aj ináč ako podpisovaním, viď. autorizácia použitím funkcie informačného systému. Napr. “podpis klikom” nahradiť aspoň za “autorizácia klikom”, keďže tu skutočne žiadny podpis nie je potrebný (viď. napr. zákon o eGov).

  • Pozitivne hodnotime, ze v studii nie je zahrnute riesenie KEP, co skutocne nepovazujeme za prioritu. V doterajších prezentáciách Nasesu však bolo uvádzané, že KEP je súčasťou tento témy. Žiadame o informáciu ako je táto téma uvažovaná riešiť ďalej.

  • Ad “Prezeranie obsahu elektronickej schránky” a “Mobilná elektronická schránka” - nie je jasné, prečo práve táto elektronické služba má byť realizovaná odlišne od ostatných. Podľa SP Multikanálový prístup majú byť el. služby dostupné cez GUI s responzívnym dizajnom.

  • Federácia identít bola požadovaná už v module IAM v štúdii uskutočniteľnosti ÚPVS. Dnes to IAM aj robí, viď. použitie autentifikačných prostriedkov notifikovaných podľa eIDAS. Netreba teda nový komponent (FA), je to už existujúca funkčnosť IAM.

  • Ad “Inštitút certifikácie mobilných identít” a “federačná autorita” - ak už má byť vo veľkom štýle riešená téma federácie identít od rôznych správcov, žiadame toto riešiť nielen pre “mobilné”, ale skrátka pre každý typ autentifikácie.

  • Plán na “certifikovanie riešení od DEUS a NASES” - žiadame konkretizovať realizáciu tohto zámeru z legislatívneho pohľadu. V súčasnosti takúto certifikáciu ÚPVII môže vykonávať? Na akom podklade? Prečo je vôbec vyžadovaná? Prečo eID neprešlo certifikáciou?

  • Ad “Komerční prevádzkovatelia identít dostanú certifikáciu podľa eIDAS, čím sa aj následne môžu od seba konkurenčne odlišovať.” - Žiadame túto úvahu vysvetliť, čo presne je na mysli pod “certifikáciou podľa eIDAS”?

  • Ad “Z pohľadu pridanej hodnoty komerčného prevádzkovateľa identít je pre štát zaujímavý jednoznačne počet už aktívnych mobilných identít komerčného prevádzkovateľa. Nemá zmysel sa zaoberať prevádzkovateľom, ktorý má síce technologicky kvalitné riešenie ale nemá v systéme aktuálne žiadnu identitu.” - Akým spôsobom chce “štát” vyberať, komu umožní zapojenie, a komu nie? Prosíme konkrétne kritériá, napr. vo väzbe na deklarovanú certifikáciu podľa eIDAS. Rovnako odhadované náklady na certifikáciu a kto ich bude znášať.

  • V súčasnosti existujú veľké zábrany využitia eID mimo eGov, najmä technické a byrokratické. Keďže dokument pojednáva aj o možnosti využiť štátne autentifikačné nástroje v rámci privátnej sféry, žiadame v dokumente popísať ako bude v tomto zjednodušené použitie eID mimo eGov.

  • Žiadame do dokumentu doplniť aj detailnejší technický popis navrhovaného riešenia.

  • Ad “MobileID jedna služba štátu … Budú ich môcť používať na prihlasovanie do …”, “uzavrieť zmluvu o pripojení k službe mID” - Opäť žiadame všetky autentifikačné schémy uvažovať spoločne (t.j. aj spolu s eID, notifikovanými schémami eIDAS atď). V rámci existujúceho mechanizmu SSO skrátka majú pribudnúť nové spôsoby autentifikácie. Všetky dnes dostupné elektronické služby majú byť realizované GUI s responzívnym dizajnom, v podstate nemusia ani vedieť aký autentifikačný mechanizmus bol použitý.

  • Ad “služba pokročilý podpis” - žiadame konkretizovať, čo presne “pokročilý podpis” je. Myslíme si, že v súčasnosti tento spôsob autorizácie nie je v rámci eGov možný a nie je potrebné ho vôbec uvažovať. Ak áno, žiadame o detailnú argumentáciu.

  • Tvrdenie, že “je potrebné mať minimálne dvoch prevádzkovateľov identít” je absolútne neodôvodnené, nelogické a nehospodárne. Z plánovaných “dvoch riešení DEUS a NASES” žiadame ponechať iba jednu a tej sa naplno venovať. Akosi každý občan je obyvateľom niektorej obce, čiže samostatne uvažovať autentifikáciu “pre obce” a “pre štát” je úplný nezmysel.

  • Ad “katalóg služieb OVM, ktoré bude možné využívať aj … podspisom klikom” - Nie, žiadny takýto katalógi nie je potrebný. Súčasný zákon o eGov to špecifikuje jasne. El. služby ktoré poskytuje má každý OVM poskytovať v každej úrovni autorizácie, ktorú zákon umožňuje.

  • Dokument sa venuje iba niektorým (náhodne?) vybraným aspektom témy autentifikácie a autorizácie. Žiadame túto tému systematicky rozpracovať.

  • Úplne absentuje prehľad nákladov na jednotlivé “dobré nápady” a hramonogram, kedy ktoré kroky budú realizované.

  • Chýba detailnejší pohľad, aké organizačné, technické, legislatívne zmeny bude treba vykonať na dosiahnutie zamýšľaných dobrých nápadov.

  • Chýba pomenovanie a vyhodnotenie alternatív.

  • V dokumente sa uvádza “ÚPVII sa rozhodlo …”, avšak takto veci nefungujú a nemajú fungovať. Pre zriaďovanie spoločných blokov existuje záväzný postup.

  • Celý dokument je písaný ako esej, chýba podloženie argumentácie exaktnejšími údajmi, a to aj v témach eGov. Detailnejšie údaje sú potrebné pre realistické odhadovanie, ako sa dobré nápady z dokumentu prejavia v praxi.

2 Likes

Toto dnes na K9.4 spomenute nebolo. Ale bol explicitne spomenuty “DEUS mobile ID”:

Schvalne som sa pytal, ci :ten DEUS alebo iny DEUS" a odpoved bola “ten DEUS”. Na mieste som uplne nechapal, ze preco DEUS, teraz zase nechapem, ze preco “dva statne mobilne ID”.

Plus aj k tomu by som mal otazku “kde su resp. budu zrojaky?” (tak, ako som sa pytal na dnesnom stretnuti K9.4. k inej apke).

Je to kazdopadne velmi kreativny dokument, resp. esej to asi lepsie vystihuje :slight_smile:

V rámci sprístupnenia populárnych služieb miest a obcí, budú občanom v Úvodnej fáze k dispozícii prvé 3
služby a to:

Neviem teda, ci tomu dobre rozumiem, ale ked uz budem raz autentifikovany na UPVS, budu mi predsa fungovat vsetky sluzby. Ake spristupnovanie prvych sluzieb?

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