Mobilné ID

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

Nases plánuje zaviesť nový spôsob autentifikácie - pomocou mobilných zariadení.
Projekt “mobilné ID” je už v pokročilom štádiu prípravy (podľa Nasesu), ale doteraz známe sú iba niektoré základné plány.
Má cez to byť možný prístup k elektronickej schránke, aj autorizácia podaní (ľudovo “podpisovanie”).

Keďže toto považujem za nielen nejaké vylepšenie ÚPVS, ale principiálne riešenie pre eGov na dlhodobé použitie, od začiatku sa o tento projekt zaujímame. Taktiež sú tu viaceré firmy s existujúcimi návrhmi v tejto oblasti (len čo ja viem - Viamo, Disig, HPX/Plaut). Aby sa našlo čo najlepšie technické riešenie, a tiež aby sa predišlo špekuláciám “kto si s kým čo dohodol”, za S.D presadzujeme, aby podklady boli verejne dostupné, každý kto má nejaký konkrétny návrh v tejto oblasti ho mohol odprezentovať viditeľne pre všetkých a pre výsledné riešenie by mal Nases vedieť odôvodniť prečo ho vybral.

V piatok bude k tomuto projektu v Nasese rokovanie, kde sa má prebrať:

  • predstavenie mobileID zámeru
  • dôvody spustenia projektu a jeho ciele
  • business zadanie, teda hlavné požiadavky na funkcionalitu
  • požiadavky na technické riešenie
  • osadenie do existujúcej architektúry eGov
  • spísanie návrhov, komentárov a odporúčaní všetkých zúčastnených
  • dohoda o ďalších krokoch

Na rokovanie boli pozvaní ITAS a S.D. Budú tam aj zástupcovia ÚPVII (minimálne viem o @kyselat), ktorý mal túto tému kompetenčne na starosti, ale zrejme celú iniciatívu prenechal Nasesu. Všetko čo k projektu zistíme tu dáme vedieť.

2 Likes
2

som mimo BA, inak by som siel rad

3

Len zohladnite SP multikanal, ked sa to splni aspon z casti, vsetci budeme radi…

2 Likes
4

Ked uz vravis o casti (preco nie cele?), tak napis co povazujes za prioritu.

5

Casti myslim kaptioly, ktore sa tykali mobilneho pristupu na sluzby :). Tento projekt nevyriesi vsetko…

1 Like
6

…podla dostupnych info z Nasesu ja scope daneho projektu vidim v takomto rozsahu:

  • mobilna aplikacia na pristupovanie do elektronickej schranky,
  • osamotene podpisanie dokumentov ZEP/EP (koncepcne nieco ako https://zep.disig.sk/Portal a mozno nejake storovanie podpisanych dokumentov v ramci elektronickej schranky, na pouzitie v inych sluzbach

…nemyslim si, ze ani v analytickych uvahach sa pojde tak daleko, ze by si s tym vedel vybavit jednotlive elektronicke sluzby a formulare v ramci jedneho pouzivatelskeho flow…to je moj tip…mozno sa mylim…

7

ze “Po inštalácii už nebude na prihlásenie potrebná čítačka, nainštalované aplikácie v počítači, ani občiansky preukaz. Bez použitia občianskeho preukazu bude taktiež možné podpisovať cez mobileID aj elektronické podania.”

odkial bude mat apka moj private key z eID ?

8

neviem ako tu, ale vacsinou sa to riesi tak ze sparujes identitu, mobileID bude dalsi privatny kluc a na strane NASES ho budu prijmat

1 Like
9

Nebude. Ja predpokladám, že toto len napáruje zariadenie na tvoju identitu (ktovie ako - možno niečo so secure enclave, android keystore…) a následne to bude použiteľné na niektoré podania. Tipol by som, že na podania, kde je potrebná úroveň kvalifikovaného podpisu to stačiť nebude. Ak sa tam použije ten hack so vzdialeným podpisovaním, tak ktovie.

Viac sa dozvieme snáď zajtra.

10

Áno, očakávam podopru levelu autorizácie kliknutím (§23.1.a.2).
To vôbec nemusí byť elektronický podpis a ak by aj áno, stačí softvérové riešenie (netreba QSCD). Ak “vzdialené podpisovanie”, tak taktiež iba pre level autorizácie kliknutím, ináč by to musela byť kvalifikovaná služba, čo by tead nebol “rýchly a efektívny” prístup.

Privátne kľúče z eID sa samozrejme nikam prenášať nebudú a ani nedajú - aspoň tak je eID certifikované.

Jedna z dobrých otázok je, ako sa prístup do schránky pomocou tohto vyrieši legislatívne. Lebo teda zákon o eGov je v tomto nešťastne striktný, podľa §13.4, §21.1 a §22a.2 to môže byť len cez eID, alternatívny autentifikátor ktorý vydáva MVSR, alebo autentifikačný certifikát, ktorý je určený na “prístup automatizovaným spôsobom s použitím technického alebo programového prostriedku”. Mobilné ID nie je ani jedno z toho, tipujem že sa kreatívne vyložia ustanovenia o AC.

Keď už sa cez mobil bude dať spraviť autentifikácia (očakávam level “pokročilá” podľa eIDAS), samozrejme by to malo byť štandardne spracované cez SSO na IAM ÚPVS, čiže prístup ku službám ako doteraz, nič netreba meniť. Akurát sa pri tých službách musí určiť že tento level autentifikácie stačí, a web ktorý službu implementuje musí byť responzívny pre mobilné zariadenie.

1 Like
11

…a teda, co ste sa dnes dozvedeli od Nasesu?..

12

@Lubor má poznámky snáď ich tu čoskoro zavesí. Bolo to celkom zaujímavé a konštruktívne.

1 Like
14

Poznámky zo stretnutia v Nases.
(z toho čo som si zapísal, čiže dosť chaotické, určite som si viaceré dobré postrehy nezapísal, aj osnova podľa ktorej sa išlo bola málo systematická, ďalej to skúsim trocha utriediť, beriem to ako diskusiu, viaceré veci sa -snáď- ešte upravia)

  • prezentácia, ktorá bola osnovou stretnutia: mobileID_predstavenie_projektu_27-7-2018_v4.pptx (12.1 MB)
  • boli sme tam ÚPVII (@kyselat), Nases, ITAS 3 zástupcovia a S.D 3 zástupcovia (za oba subjekty viem o viacerých záujemcoch, ktorí sa pre obmedzený počet na rokovanie nedostali)
    .
  • projekt iniciovalo ÚPVII, oni sú aj gestor úlohy “zjednodušiť autentifikáciu” z NKIVS, ale “je najlepšie” ak sa to celé bude riešiť v Nases, keďže tam je centrálny modul pre autentifikáciu
  • Nases má na tento projekt “pracovnú skupinu”, ale takú internú, t.j. nevieme kto je členom a nedá sa do nej zapojiť
    .
  • podľa prieskumu málo ľudí používa dnes elektronické služby, asi iba 10% tých čo majú eID
  • to by sa mohlo zlepšiť ak budú môcť robiť jednoduchšiu autentifikáciu
  • ITAS aj S.D pripomenulo, že cieľom je aj naopak aby “štátna” autentifikácia bola konečne použiteľná mimo verejnej správy
    • ITAS špeciálne zdôrazňoval možnosť použitia bankami - zriadenie účtu a schválenie úveru - ja by som práveže za dôležité považoval podporiť menej “vážne” služby, ktoré sú oveľa častejšie používané
      .
      Ciele projektu:
  • autentifikácia - bez HW požiadaviek
  • autorizácia - usr. má byť schopný “vybranú” skupinu služieb cez mobil použiť
  • bude teda k tomu mobilná aplikácia
  • spraví sa aj prístup do schránky z mobilu, lebo je to dôležité (napr. advokáti toto žiadali)
  • nerobí sa teraz celý scenár prípravy podania cez mobil (ale do budúcnosti to je cieľ)
    .
    Akú úroveň autentifikácie a autorizácie má pripravované riešenie podporovať
  • ÚPVII: level autentifikácie eIDAS 3 “vysoká”, jediný kompromis oproti eID je že netreba QSCD (bezpečné úložisko privátneho kľúča)
    • cieľ je komfortnejšie a výrazne lacnejšie riešenie
  • za mňa toto nedáva zmysel, lebo cez level 3 musí byť dostupné všetko (konflikt s cieľom “iba vybrané služby”), nebude to finančne efektívne a v konečnom dôsledku vysoká bezpečnosť bude vždy tlačiť na zložité riešenie, myslím že nezvážili všetky potrebné požiadavky na tento level, viď. QAA level 4 pre auth v našich štandardoch (zodpovedá level 3 eIDAS)
  • čiže za mňa cieľ je smerovať na eIDAS level 2 “pokročilá” (zodpovedá levelu 3 podľa štd. ISVS)
  • ÚPVII má právny výklad autentifikácie kliknutím, že prostriedky ktorými sa vykonáva majú byť “do najväčšej miery” pod kontrolou usr.
    • toto vyzerá na klasické právnické málo konkrétne stanovisko, skúsim tento výklad získať
  • aká úroveň autorizácie má byť týmto riešená nepadla jasná odpoveď, riešitelia si to skrátka predstavujú že “bude sa podpisovať pomocou AdES”
    • za mňa pri ÚPVS v skutočnosti riešime podľa eIDAS doručovaciu službu, ako som písal vedľa, tam spôsob autorizácie je kontraktuálna dohoda medzi poskytovateľom služby a usr. (čiže tu daná zákonom), pre interoperabilitu nie je podstatná
    • t.j. riešme autorizáciu kliknutím
    • ITAS sa pýtal, či teda má byť použitý iba AdES, alebo AdES s kvalifikovaným cert.
    • za mňa AC nemôže byť QC, skrátka sú to iné režimy, a už vôbec by toto nebolo “lacné rýchle” riešenie
  • za mňa treba jasne na začiatku povedať riešené úrovne A/A, od toho sa má odvíjať technické riešenie
    .
    Diskutovala sa otázka, či toto má byť notifikovaná schéma podľa eIDAS
  • ITAS: práve notifikovaná schéma je spôsob ako otvoriť používanie pre ďalších
  • ÚPVII: nie je to priorita, prvý cieľ je pomôcť ľuďom v SR
    .
    Riešenie používa autentifikačný certifikát
  • (keďže iná možnosť v súčasnsom zákone nezostáva)
  • sú presvedčení že legislatívne je to v poriadku
  • ITAS pripomenul dokument ENISA, že autentifikácia nemá byť realizovaná podpisovaním (ak ho získame, zavesím ho sem)
  • čiže tento mechanizmus bude použiteľný pre každé vydávanie/použitie AC, to je rozdiel od dnešného stavu
  • autentifikácia pôjde štandardne cez SSO IAM ÚPVS
    • čiže prístup ku službám cez mobil bude ako doteraz
      .
      Nemá sa na realizáciu projektu robiť zmena legislatívy
  • ale ak treba, svoje vyhlášky Nases doplniť/zmeniť vie
  • pripomenuli sme, že je čas upratať časť ZeGov o autentifikácii
    • ozaj je čas toto poriadne riešiť, skúsim k tomu dať nejaké návrhy do novely ZeGov, dnes končia konzultácie
  • ITAS pripomenul, že ak toto má byť aj komerčne využívané, leg. zmeny sú nevyhnutné
    .
    Inicializácia / zriadenie mobilného ID:
  • plán je pevná väzba na eID
  • čiže každý kto mobilné ID chce použiť, musí vopred mať eID
  • toto je problém, lebo veľa ľudí nemá/nebude mať eID a práve sme chceli aby to bolo nezávislé
  • špeciálne na IOM sa predsa má dať toto zriadiť aj ak nemám eID, je to tak (leg., bezpečnosť, procesy) pripravené
  • diskutovala sa otázka, či pri zneplatnení eID sa má automaticky zablokovať príslušné mobilné ID
    • za mňa určite nie, jednak nie je dôvod a predsa práve ak nemám eID potrebujem iný spôsob prístupu ku službám (napr. schránke)
  • plán bol že 1 mobilné zariadenie = 1 identita
    • to je ale čudné, lebo mobilné zariadenia majú bežne usr. profily, čiže radšej 1 profil = 1 identita
  • samozrejme celý mechanizmus zvolenia “subjektu v mene ktorého identita vystupuje” po prihlásení zostáva ako je teraz
    .
    Ako hlavný scenár použitia bolo prezentované “prihlasujem sa na slovensko.sk cez počítač (ako doteraz), ale nechcem použiť eID/čítačku”, viď. slajd 9
  • namiesto toho použijem mobil
  • (mne a Janovi trocha padla sánka, lebo teda celý čas sme predpokladali, že hlavná vec ktorá sa má riešiť je natívny prístup ku službám cez mobil)
  • zadávaný PIN je nový (nie je to BOK ani nič iné doteraz)
    • má zostávať lokálne na zariadení, t.j. v žiadnej forme neide na serverovskú časť
  • pripomenuli sme, že keď riešime otvorenie pre iné použitia, tak aj mobilnú aplikáciu si de-facto môže urobiť každý akú chce
    • integrácia cez API, ktoré majú byť štandardne dostupné
    • t.j. nie veľká integrácia ako doteraz
    • Nases predsa ani nevie rozlíšiť, či som použil “ich” aplikáciu

.
Scenár “podpisovanie smartfónom”, slajd 10

  • za mňa je toto celé čudne popísané, jednak neriešime “podpisovanie”, ale autorizáciu, nie je jasné čo presne má byť “kvalifikovaný podpis”, “úroveň zabezpečenia” sa vzťahuje na autentifikáciu, nie autorizáciu, nemáme toto jasne namapované na leg. úrovne autorizácie, “CA na trust liste kvôli overeniu podpisu” - kto/kedy/ako bude overovať? ako toto súvisí s AC? toto je jednoduché/lacné riešenie?, “centrálny podpisovací komponent” - prosím? podpisovanie je predsa vždy lokálna vec, opäť sa vyberie jeden privilegovaný dodávateľ podpisovacej funkcionality?
  • viď. aj poznámky vyššie k podpisovaniu / AdES / doručovacia služba
  • za S.D aj ITAS sme povedali, že autorizácia kliknutím nemá byť robená elektronickým podpisom
    .
    Scenár čisto mobilného použitia
  • zatiaľ nie je, ale ráta sa s tým “v ďalších fázach”
  • všetci sme pripomenuli, že toto je dôležitá vec
  • ale vlastne keď je funkcia prístupu ku schránke tak toto je prirodzene podporované (viď nižšie)
  • skrátka Nases nemá kapacitu aby teraz menil responzívnosť svojich služieb
  • ITAS pripomenul, že na všetky OVM sa tlačí aby nové služby boli “použiteľné cez mobil”, budú sa vôbec dať použiť?
    .
    Scenár schránka cez mobil
  • vylobovala SAK (a ďalší)
  • otvára sa cez web alebo cez natívnu appku
  • skrátka normálne na mobile idem na slovensko.sk, zvolím prihlásenie a ide sa ako v scenári “prihlasovanie s mobilom cez počítač”
  • pripomenuli sme, že toto musí byť bez QR kódu (nemám ho ako zosnímať)
    .
    Nases nemá architektonický komponent ktorý by zastrešil zobrazenie/autorizácia/odoslanie podania
  • toto je najväčšia prekážka, lebo každá úprava ÚPVS je utrpenie
    • možno bude spravený nový komponent, nie úprava toho čo už je
  • samozrejme toto je nezávislá vec od mobilnej appky
    .
    Ďalší plán
  • do konca roka 2018 nasadené
  • v 1. kvartáli 2019 dostupné pre všetkých usr.
    .
    Otvorenosť procesu prípravy riešenia
  • Nases a ÚPVII ďalej chcú ísť v režime “niečo si tu pripravíme, občas to niekomu ukážeme”
  • do 6.8. máme poslať “pripomienky” a vyberú si čo sa im najviac pozdáva
    • úvodzovky preto, že koncept/materiál nie je dostatočne konkrétny na formálne pripomienkovanie
    • detto je čudné, že teraz sa mohol vyjadriť iba niekto, napr. rôzne firmy majú na určitý aspekt rôzne názory
  • pripomenul som, že toto celé sa malo riešiť v PS na ÚPVII - je to v pláne pre PS Lepšie služby “do 31.3.2018” a detto PS pre štandardy ISVS - veď to má byť povinné pre všetkých
    • k tomuto nebola žiadna odpoveď zatiaľ
1 Like
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