Mobilné ID

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

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.

Á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

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

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

1 Like

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

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.

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.

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

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

1 Like

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

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 SÚHRNNÁ IMPLEMENTAČNÁ SPRÁVA ZA ROK 2018 (Zdravotníctvo, doprava, informatizácia, vzdelávanie, životné prostredie, trh práce a sociálne politiky)

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?