Mobilné ID

Čo sa deje v e-Governmente Orientácia štátnych IT služieb na občana
15

Pripominam zo SP multikanal toto:

Pri definovaní technického riešenia nižšej úrovne autentifikácie použitím mobilného zariadenia je potrebné zohľadniť nasledovné princípy:

  • eID karta bude vždy vydávaná ako primárny autentifikačný prostriedok, pomocou ktorého bude možné aktivovať mobilnú autentifikáciu samoobslužným procesom, prípadne aktivovať aj iné autentifikačné mechanizmy.
  • Autentifikácia je vykonávaná vždy cez centrálneho poskytovateľa identity VS SR (ÚPVS IAM), ktorý je integrovaný s referenčnými registrami (RFO,RPO). Nakoľko v súčasnom stave architektúra VS SR obsahuje centralizované údaje o identitách, nie je potreba využitia decentralizovaných modelov autentifikácie cez externých poskytovateľov identít ako je to v prípade niektorých krajín, ktoré nemajú centralizovanú správu identít.
  • V prípade implementácie obidvoch úrovni (3 a 4) zabezpečenia autentifikácie použitím mobilnej aplikácie budú tieto funkcionality integrované v jednej aplikácií, aby klient nemusel inštalovať viacero autentifikačných mobilných aplikácií.
  • Súčasťou rozvoja centrálneho poskytovateľa identít VS SR bude otvorenie služieb identifikácie a autentifikácie vo forme Open API a vykonávaná podpora za účelom inklúzie týchto služieb do komerčného sektora. Poskytovaním predmetných služieb sa výrazne odbúra komplexnosť riešení spojených s určením identity v digitálnych kanáloch komerčných poskytovateľov služieb (napr. nahrávanie fotiek občianskeho preukazu, resp. videa).

Okrem určenia technického spôsobu prevedenia mobilnej autentifikácie v súlade
s bezpečnostnými požiadavkami, bude vykonaná biznis analýza koncových služieb v gesciijednotlivých orgánov verejnej moci za účelom revízie požadovanej úrovne autentifikácie s jej potenciálnym znížením na úroveň, ktorá zabezpečí čo najrýchlejší prístup aj z mobilných zariadení.

Zvyraznenie som dal ja.

16

Toto sme poslali ako stanovisko S.D k návrhu mobilného ID:

mID - navrhy S.D.docx (237.6 KB)

Stručne z toho dokumentu vytiahnuté hlavné odrážky, bez argumentácie:

Základné princípy

  • Súhlasíme s konceptom, že podporované majú byť iba vybrané služby, ktoré sú spojené s nižšími požiadavkami na bezpečnosť
  • Súhlasíme s konceptom, že je vhodné zvoliť rýchlo dosiahnuteľné a finančne veľmi efektívne riešenie
  • Používajme v čo najväčšej miere už existujúce legislatívne nástroje, najmä v zákone o eGov
  • Autentifikáciu žiadame implementovať pre úroveň eIDAS „pokročilá“ = ŠTD ISVS level 3
  • Ak nebude podporovaný plne mobilný scenár, autorizáciu nemá vôbec zmysel riešiť a vynechajme ju z projektu úplne
  • Autorizáciu žiadame implementovať pre úroveň „použitím na to určenej funkcie informačného systému“ aka. „autorizácia kliknutím“

Scenáre použitia

  • Plne mobilný scenár má byť jedna z priorít tohto projektu
  • Na „autentifikáciu pomocou mobilu“ (ak by sa neriešil plne mobilný scenár) postačia štandardné služby
  • Konkrétne bezpečnostné mechanizmy nie je vhodné fixovať vo fáze konceptu
  • Mobilné ID nemá byť priamo naviazané na eID
  • ÚPVS nemá obsahovať „centrálny podpisovací komponent“
  • Nemá byť vytváraný „centrálny komponent“ pre autorizáciu kliknutím

Otvorenosť riešenia

  • Riešenie má byť jednoducho interoperabilné pre aplikácie tretích strán
  • Autentifikačná služba má byť použiteľná aj mimo verejnej správy
  • Zjednodušiť použitie služieb aplikáciami tretích strán spôsobom OpenAPI
  • Aplikácia na mobile má byť vyvíjaná ako OpenSource

V prílohe je úvaha na tému, prečo ak “používateľ spravil el. podpis” to nemusí znamenať vyššiu úroveň záruk a odbiť tému spoľahlivosti týmto nemusí to byť v záujme používateľa.

17

Zatiaľ odpoveď Nases/ÚPVII je, že “stanovisko vyhodnotia” a dajú vedieť aký je finálny návrh. Pokiaľ viem ITAS zatiaľ stanovisko nezaslal.

Keďže vznikla diskusia, či si OVM budú môcť/musieť zvoliť, pre ktoré podania umožnia použitie mobilným ID (t.j. autorizácia), za S.D to vidíme takto:

K otázke “klasifikácie podaní” z hľadiska vyžadovaného stupňa autorizácie je naše stanovisko úplne jasné. Zákon o eGov v §23 ods.1 konštrukciou písm.a) a b) dáva presnú a normatívnu odpoveď, kedy sa môže aký spôsob autorizácie použiť. Použiť autorizáciu kliknutím je možné “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” (viď. písm.a)).

Pre autorizáciu podľa nášho rozboru v súčasnosti OVM nesmie “zvoliť” akú autorizáciu bude vyžadovať, musí sa postupovať iba v medziach zákona . Považujeme tento stav za správny, a to aj z dôvodu určitosti pri podaniach, ktoré sú právnym úkonom, ktorý vykonáva sám podávajúci.

T.j. akékoľvek riešenie, ktoré by dávalo možnosť pre jednotlivé OVM “zvoliť” úroveň autorizácie považujeme za nevhodné (aj ak by legislatíva takýto prístup umožňovala).

Naopak, pri autentifikácii (prístup ku službám) si každý OVM musí určiť vyžadovanú úroveň a taktiež tento stav považujeme to za vhodný. Služby, ku ktorým sa pristupuje sú totiž v správe OVM, ktoré zodpovedajú za ich prevádzku a bezpečnosť.

18

Stanovisko ITASu k Mobilnému ID:
Stanovisko_ITAS_MobilneID_v5.docx (31.9 KB)

1 Like
19

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
Chyba

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
20

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.

21

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
22

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
23

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.

24

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

26

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
27

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
28

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.

29

Co to je ten Pokrocily elektronicky podpis?

30

To je nazov podla eidas.

31

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
32

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

33

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
34

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).

35

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?