Mobilné ID

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