ÚPVII Pracovná skupina K9.5 Lepšie služby

K stretnutiu PS 16.11.

Veduci skupiny Tomas Revaj pripravil prezentaciu UPVII_PS_sluzby_v03.pptx (825.5 KB) (dostal som povolenie ju zverejnit)

Vystupmi tejto skupiny by mali byt tieto dokumenty v tejto casovej naslednosti:

Dostali sme prislub, ze cca o dva tyzdne budeme mat prvy draft na pripomienkovanie. Vitame tuto otvorenost.

Potrebujeme zozbierat navrhy na:

  • co ma byt v scope tychto dokumentoch? Aby sa na nic podstatne nezabudlo.
  • ake alternativy su nepokryte? Aby boli slusne vyargumentovane vsetky moznosti.

Primarne v oblastiach strategickych dokumentov:

  • multikanalovy pristup (riesi sa ako prvy)
  • integracia a orgestracie
  • interakcia s VS, Zivotne situacie a navigacia

Co sa preberalo na stretnuti a moje postrehy k tomu napisem neskor. Akekolvek navrhy piste sem, konsolidaciu spravime potom.

Moje osobne poznamky a uvahy zo stretnutia 16.11.2016

Zhrnutie:

Prve zasadnutie pracovnej skupiny. Pracovna skupina sa bude zaoberat nasledujucimi strategickymi prioritami NKIVS:
multikanalovy pristup,
integracia a orchestracia,
interakcia s verejnou spravou, zivotne situacie, navigacia v ramci zivotnych situacii.

Predstavil sa harmonogram stretnuti, milniky. Dolezite milniky su:
14.12.2016 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k multikanalovemu principu
11.01.2017 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k integracii a orchestracii
01.03.2017 - vznik 1. verzie a zaciatok pripomienkovania dokumentu k zivotnym situaciam

Veduci skupiny presiel uvodnu prezentaciu, v ktorej sa nacrtli jednotlive temy. Nizsie spisujem postrehy, co som zachytil.

Negativa, rizika:

  1. nesedi mi poradie v akom sa idu spracovat jednotlive temy - osobne by som zacinal zivotnymi situaciami a z toho by vypadavali poziadavky na zostavajuce priority a dokonca aj na konkretne projekt, projektove zamery.

  2. popisuje sa ToBe stav a iba na papieri, bez reflexie existujuceho stavu a existujuich skusenosti. Ako Jano S. poznamenal, chybaju kroky ako sa k ToBe stavu dostat. Toto je jeden z najklucovejsich prvkov a mal by byt zapracovany do rohodovania a definovani high level architektury.

  3. multikanalovost by som bral velmi light, aktualne nemame vyrieseny poriadne ani jeden kanal (ani osobny styk) a zrazu sa chce mat vsetko a vsade - ako Miso B. poznamenal adopcia takychto sluzieb je otazna, prepis nehnutelnosti a pod. clovek asi nebude chciet robit elektronicky a dokonca nie prostrednictvom mobilu a pod. Nie je potreba mat autosave formularu, t.j. nieco si rozpracujem na mobile a potom dokoncim na pocitaci

  4. multikanal - kanal mobilne zariadenia - padla otazka, ze ake odporucania dat pre budovanie tohto kanalu, ci nativne app, alebo responzivny dizajn webovych aplikacii, alebo nieco ine? Ake su trendy v zahranici? Kde sa vidi potencial? Co je uz za hranicou a vieme z inych segmentov, ze nefunguje alebo sa vobec neodporuca? K tejto otazke treba pristupovat velmi konstruktivne a agilne. Vraj uz v ramci aktualnych projektovych zamerov sa pocita s vyvojom mob. aplikacii. Mob. aplikacie su velmi specificka zalezitost, ktora musi vychadzat jednoznacne z potrieb pouzivatelov a proces vyvoja by mal byt extremne agilny. Osobne si myslim, ze nema byt cielom vyvinut kopec mob. aplikacii, ktore kopiruju napr. webove aplikacie. OpenAPI umozni sukromnemu sektoru taketo aplikacie budovat a keby sa to nechytilo a bola by potreba pouzivatelov, tak potom by sa malo ist do zvazovania, ci nativna mob. aplikacia alebo nejaky hybrid. Mob. aplikacie maju specificky sposob riadenia vyvoja a teda malo by sa to riesit v metodikach pre projektove riedenie. Plus obstaranie takejto sluzby/diela by malo byt samostatne.

  5. OpenAPI - osobne mam pocit, ze niektori clenovia si tento pojem zamienali s OpenData API. Potrebne klast doraz na vysvetlenie, ze nejde len o citanie udajov z API, ale aj o zapis a pod. V tejto suvislosti sa hovorilo o govtech firmach a o potrebe riadenia cyklu pre pristup k OpenAPI. OpenAPI je zatial vnimane v rovine “sandboxu”.

  6. mam pocit, ze sa velmi rychlo, bez analyzy existujuceho stavu, definuju uz vizie dalsich velkych projektov, ktore su duplicitne/do velkej miery rovnake s uz existujucimi IS VS alebo ich castami, napr. bol spominany centralny komponent pre notifikacie. Nemame uz niekde taketo nieco? UPVS? Nie je moznost, aby sa uz existujuce riesenie spristupnilo pre ine IS VS a takto bolo zakomponovane do navrhovanej architektury alebo malymi upravami taketo riesenie dosiahnut? Cielom by nemalo byt budovat nieco simultanne s existujucim stavom, ale do max. miery prepouzit/upravit uz existujuce riesenia. Moze pomoct zverejnenie kodu?

  7. navrhuje sa extremne centralne riesenie, cim sa zvysuje riziko single point of failure. Centralizacia sa tyka ci uz datovej roviny (napr. MyData) alebo aj technologickej, aplikacnej roviny. Opat teda hrozi riziko aj vendor lockinu.

  8. integracia a orchestracia sa nacrtla mierne. Toto si ani zatial neviem predstavit na zaklade aktualnych skusenosti. Ma toto vobec vyznam? Ma to riesit stat alebo ked bude OpenAPI, neporiesia sa tie najdolezitejsie veci mimo statu a lepsie v prospech obcanov? Bolo spominane aj nejake narodne integracne centrum, ak som to dobre zachytil. Zatial neviem co by to konkretne malo byt. Tema bude este predmetom debaty, cize urcite sa k nej este vratime.

Pozitiva:

  1. Viacero clenov si rychlo adoptovalo myslienku OpenAPI, napr. MV SR, ITAS.
2 Likes

Pridavam moje postrehy zo strenutia + navrh toho ako vidime situaciu za Slovensko.Digital. Dokument je otvoreny na komentovanie, pripadne piste navrhy sem.

Momentalne otvorene temy: Su orchestracna platforma, mobilne aplikacie a open api.

Zatial je “kontroverznejsia” otazka orchestracnej platformy. Tam nie je zrejma pridana hodnota centralneho riesenia, ktore prinasa svoje velmi velke rizika.

Stale plati, ze pokial nieco v dokumente chyba, teraz je cast doplnit scope.

Pridavam vyjadrenie za SUXA, ktore sme si interne schvalili:

2 Likes

Neskory, ale predsa zapis zo stretnutia minuly tyzden. Chcem pochvalit Tomasa, urobil si domace ulohy a spracoval podnety co dosli tu na platforme aj od SUXA. Ma to zmysel.

  • riesili sa ciselniky zivotnych situacii - su v metais, ale len stara verzia

  • MV ma nejake velmi dobre rozpracovane ZS - zatial nie v metais

  • architektura skupina - caka sa ci zo strategickych architektur vyjde nieco co z architektury co sa v roku 2014 (?) navrhla bude v protiklade

  • diskusia o tom kedy vlastne zacina a konci zivotna udalost (pred podanim, zistit vytazenost, registracia terminu)

  • zivotne situacie pre podnikatelov

  • diskusia preco mobilne aplikacie ano a nie, v nkvis su mobilne aplikacie - co s tym? prehlasit ze responzive je mobilna aplikacia

  • diskusia o tom aky bude mat dopad neimplementacia

  • vysledok - obmedzit mobilne appky len na to co je naozaj nutne (spravit whitelisting) - na toto treba dohliadnut v dokumente

  • openapi - ake objekty evidencie? (read / write)

  • poznamka backend musi kontrolovat aj to, ze podpis na ukone je v nejakom vztahu k tomu co chce menit/vidiet (logicke - nemozem podpisat, ze chcem prepisat auto niekoho ineho)

  • diskusia o limitoch open api - legislativa, formulare

  • existuje nieco ine ako api (write) na formulare? - vsetko vznika na zaklade podania (legis)

  • problemy schranok - DCOM robi polling (maju sluzbu co vrati pre 50 schranok naraz, problem ak statutar nieco do schranky sam prida, etc)

  • folder - opravnenie na folder (vraj je), opravnenie na podanie (malo byt v scope, vyzera ze neexistuje)

  • diskusia orchestracie - varianty

  • schranky - push notifikacie chybaju na urovni api

  • schranky - correlation id institucia nevidi (oni si to posielaju do schranok)

  • diskusia o umiestneni udajov pre open API - ci centralne alebo nie

  • developer portal pre API

  • kompetecne centrum, co bude tlacit na integracie a buchat do stola ak nieco pojde mimo to

  • diskusia o projekte csru - viaceri to videli ako zbytocny medzikus, integracia napriamo je pre producentov jednoduchsia. pre konzumentov je naopak fajn mat jeden endpoint a menej byrokracie.

  • diskusia o zivotnej situacii - co to je a ci tam vobec moze vzniknut viac krokov

  • bolo povedane, ze sa budu robit projekty per zivotna situacia - toto si treba treba ustriehnut. vsetci suhlasne prikyvovali

  • orchestracna platforma bude (lebo v cloude sa s tym rata)

  • diskusia - nove gui pre ZS nebude duplicita voci opis projektom?

  • argumenty za orch. platformu - procesy su mimo hlav vendora a diskusia o tom, ze prechod na novy proces je vzdy bolestivy.

  • viac krat som upozornil, ze toto by mala asi riesit ina skupina - PS architektura, ktora este nenastartovala.

Vysledkom je, ze ako kanal budu preferovane responzivne aplikacie (mimo velmi obmedzenych pripadov, kde by mohla mobilna aplikacia davat zmysel, napr. podpisovanie, autentifikacia)

Open API - z tohto mam zatial pocit, ze nie vsetci chapu uplne co sa tymto mysli a nemozeme to zredukovat len na podania na urovni formularov.

Orchestracna platforma - zatial vyzera, ze bude jedna centralna (v cloude), pricom vyhody prezentovane (centralizacia procesov a monitoring) nevidim ako velky dovod to robit takto. Tomas vsak odkazal, ze nami navrhovana alternativa (propagacia domenovych eventov) bude vhodnejsia ak sa da spravit.

Na tohtotyzdnovom stretku 1.decembra bude:

  • Mobilná aplikácia pre autentifikáciu
  • Asistovaný prístup k elektronickým službám (koncept IOM v navrhnutej architektúre)

Ak mate navrhy alebo nieco co by sa malo prebrat dajte vediet. Bol tu navrh venovat sa centralnemu dizajn manualu.

1.) Zbierat, vyhodnocovat a implementovat podnety (bugy, zlepsenia)

Do dokumentu navrhujem pridat poziadavku na zbieranie podnetov k aplikaciam a ich pouzitelnosti (public issue tracker? odborna komunita?) a definovane procesu, co sa s tymito podnetmi bude robit.

Specialna kategoria su male/lacne opatrenia “low hanging fruits”, ktorymi je mozne za relativne male naklady zlepsit pouzitelnost existujucich aplikacii. Ak sa podnet vyhodnoti ako opodstatneny a “low cost/jednoduchy”, tak by sa mal implementovat ASAP. Bud cez 2., 3. alebo “standardne” ako samostatny projekt alebo ako sucast projektu riesiaceho viacej podnetov naraz.

Priklad: Pri elektronickom vybavovani nevyzadovat od pouzivatela vyber poskytovatela podla lokality, ak to nie je nevyhnutne (napr. pri sluzbe konkretnej obce). Priklad: Ak ziadam o rodicovsky prispevok, tak mi je jedno, ci to vybavi pobocka v Bratislave alebo Humennom, takze v zozname sluzieb na slovensko.sk chcem pri sluzbe “Rodičovský príspevok pre zverené dieťa” uplne preskocit krok “Zvoľte poskytovateľa služby”.

2.) Vyuzitie reklamacii na opravy chyb v aplikaciach a ich pouzitelnosti

Ako je to so zarukou na existujuce projekty? Su dodovatelia povinni opravovat vyargumentovane vady? Do kedy? Toto by mohol byt sposob ako zapracovat zlepsenia “zadarmo” v ramci reklamacii. Navrhujem poziadavku na verejny zoznam projektov, dodavatelov a datumov dokedy su v zaruke.

3.) Statom organizovane hackathony a sposob financovania malych mikroprojektov na zlepsovaky UI/UX

Ludia generuju vela zaujimavych navrhov na zlepsenie, ktore by sa dali zrealizovat bud ako dobrovolnicke aktivity alebo nejakou formou financovane mikroprojekty (max. par tisic eur). Navrhujem pridat poziadavku na vytvorenie mechanizmu ako umoznit zapojenie ludi s mikroprojektami. Jedna moznost je napr. zapojenie studentov cez bakalarske a diplomove prace. Zadania by mohli plynut aj z podnetov z bodu 1.

Priklady: browser plugin, asistencny system, info o dostupnosti, napady z hackathonu, atd.

1 Like

Principy

  • navrhujem pridat “Eat your own dog food”

Kanaly a pristupove miesta

  • Kanaly “osobne”, “listinne”, “telefonicky”, “email” by mali byt len proxy k primarnemu kanalu (web?), cize uradnik by mal byt v ulohe asistenta, ktory moze v mene obcana pouzit webovy kanal. “Eat your own dog food” Otazka: Ako to robia napr. operatori alebo banky?
  • suhlasim s ostatnymi, ze mobilne aplikacie nie

Servisna vrstva:

  • Autosave je jedna z mnohych “drobnosti”, ktore zlepsuju pouzivatelsku skusenost, ale nedaval by som to do dokumentu
  • Vyhladavanie ZS a predvyplnanie udajov su zasadne veci. Su tieto dve veci vsetky zasadne veci? Podla mna nie.
  • K vyhladavaniu jeden detail a to, ze by mal byt budovany slovnik synonymickych pojmov (zalozenie sro = ziadost o zapis do orsr = zalozenie firmy, atd.).
  • Ja za zasadne povazujem aj:
  • plynulost procesu” (nenapada mi teraz vystiznejsi pojem), cim mam na mysli to, aby sluzby boli implementovane tak, ze ich pouzivatel dokaze cele zrealizovat v jednom prostredi/aplikacii a nemusel napr. po vyplneni formulara v aplikacii ist do schranky a tam ho este podpisat. Iny priklad roztriestenosti je nemoznost prepinat medzi uctami po prihlaseni sa na slovensko.sk.
  • “jednotny vizual”, rovnako vyzerajuce komponenty (zoznamy, formulare, typografia, atd.), SUXA to popisala podrobnejsie, suhlas.
1 Like

Suhlasim tiez s tym, ze sa zase buduju to-be patrocnice a minimalne sa reflektuje sucasny stav.

Podla mna by bolo dobre vybrat zopar realnych sluzieb a popisat cely proces, ktorym musi pouzivatel (aj uradnik) prejst a na tomto ukazat principialne/systematicke chyby, kozmeticke veci (napr. nejednotny vizual, roztriestenost, zle vyhladavanie, nezrozumitelnost textov, z kozmetickych napr. autosave) a navrh ako sa dostat k lepsiemu stavu.

Druhy podklad by mal byt pohlad na metaproces zavadzania novych sluzieb, ktore este neexistuju elektronicky, identifikovat systematicke a kozmeticke chyby v tomto procese a navrh ako ich odstranit, aby vysledkom boli kvalitnejsie implementovane sluzby (tam je napr. rozhodnutie nerobit mobilne aplikacie, jeden krat a dost, eat your own dog food, atd.).

Tiez by bolo dobre najst a ukazat dobre priklady, kde fungoval proces tvorby a mame aj funkcny vysledok (napr. ITMS?).

Sorry ze sa zapajam aj bez vyzvania. Toto je mozno najvacsi oriesok. Z vlastnej skusenosti viem ze vytvorit nejaky Change request procesneho typu napriklad na MiFi bolo dost organizacne narocne.
Dovod. Vela systemov a kazdy pod inou zmluvou u ineho dodvatela. Iný projektak z MiFi a JEDNOTNA Orchestracna platforma v Datacentre ponizena z BPMN procesneho stroja na file exchanger. Potom ak mas zmenu , ktora je v primarnom systeme, musis cakat, alebo niekedy na vlastnu past jednat aj so systemami (dodavatelmi) kde ma dopad a s firmou co sedi na SAP NW PI (bpmn orchestracia). Oni musia na zakalde inych zmluv dostat Change requesty. Tento proces v podstate nema pana, a tak to tlaci obycajen dodavatel, ktoremu to najviac hori. A viac clovekohodin sa vybuicha na schodzkach a pri pisani zapisnic a mailov, nez programovanim.
… A bojim sa, ze takto by dopadli aj microprojects … (co je inac pattern velmi progresivny).
A to MiFi je na tom najlepsie co sa tyka procesov a vzdelania ludi pri Informatickych projektoch.

2 Likes

asi skor pracovna skupina delivery

Vie mi niekto v skratke popisat, ze co bolo na skupine 1.12.2016.

dik

  • Mobilná aplikácia pre autentifikáciu
  • Asistovaný prístup k elektronickým službám (koncept IOM v navrhnutej architektúre)

temy som vedel, myslel som nieco blizsie k nim napr. strucne zavery…pripadne ci sa otvorilo nieco nove a pod.

Moj zapis:

Na stretnuti sa riesila hlavne mobilna aplikacia na autentifikaciu. Toto bolo z mojho pohladu trosku nestastne a nizke, kedze sa vhuplo dost nizko do konkretneho riesenia ako robit autentifikaciu cez mobil a na tablete, bez toho, aby bol popisany high level scenar ako si cestu pouzivatela vlastne predstavujeme. Zacalo sa s predpokladom (podla mna chybne), ze zivotna situacia/podanie musi koncit podpisom cez ZEP/KEP a tym padom sa toto cele extremne komplikuje. Diskusia bola chvilu nekontrolovana kedze sa preberali prilisne detaily bezpecnosti, ktore sa maju riesit na bezpecnosti a az potom v tejto PS.

Navrhy z nasej strany boli hlavne:

  • znizit uroven nutnej autorizace pre niektore(!) ukony z levelu 4 (zep) aspon na level 3. Tymto sa vyriesi kopec technickych komplikacii. Gestori nech prejdu svoje ukony a urcia minimalny level autorizacie, ktory na dany ukon treba
  • podobne zaviest rozne urovne autentifikacie. niekde moze stacit FB login, niekde na to, aby som videl data (napr. ehealth) treba byt ovela striktnejsi.
  • je potrebne zaviest moznost, aby bolo mozne vypnut (!) alebo limitovat pristup cez rozne kanaly. Priklad - nikdy v zivote nechcem, aby sa robili prevody mojho majetku ZEPom. Nechcem, aby niekto mohol za mna robit podanie na IOMO, etc. Toto je velmi individualne (napr. realitny makler alebo pravnik a uctovnik pravdepodobne budu nejake ukony chciet robit takto, nech maju moznost) - ako idealne miesto pre toto sa javi modul opravneni - kde budu aj tieto limity.
  • je neziaduce aby stat robil trendy riesenia a pokryl vsetky podania online. je potrebne zistit, ktore zivotne situacie/podania ludia vlastne chcu robit online alebo dokonca na mobiloch a snazit sa tam znizovat level autentifikacie a autorizacie tak, aby netrpelo UX ale zaroven bola primerana bezpecnost. (Priklad - na dan zo psa naozaj ZEP netreba).
  • povazujeme za klucove, aby stat umoznil zapojit sa komercii v dvoch miestach cez API. Jednak pri autentifikacii (stat nech pripravi svoj sposob, ale nech komercia ma moznost sa certifikovat na urcity level a ukazat ako to vie zjednodusit - v klude nech na tom zarobi), a pri autorizacii (v klude nech komercia vyuziva aj ZEPasaservice a predava ako produkt, ale nie je dovod, aby to robil stat pokial ponukne dostupne alternativne riesenie)

Tieto navrhy boli najprv trochu nepochopene, potom este raz este viac nepochopene, ale k zaveru to uz vyzeralo, ze sa na tom vlastne zhodneme a chceme to. Tymto veducemu skupiny a aj veducej prog. kancelarie dakujeme za trpezlivost a posnazime sa nase navrhy nabuduce jasnejsie naformulovat hned na 1x.

Nasledne bola kratka debata k IOMO o module opravneni. Nepamatam si z toho nejaky zasadny zaver, snad len to, ze je dolezite, aby OpenAPI bola vrstva pouzivana aj pre IOMO a ine kanaly. Vyhneme sa tak duplicitnym rieseniam pre interne a externe pouzitie a zvysi sa ich kvalita.

K IOMO bola vznesena zasadna pripomienka, aby neboli poskytovne vsetky sluzby na IOMO asistovane (priklad - nie je mozne aby na miestnom urade v hornej dolnej vedeli ako urobit nejake clo na lodnu dopravu). Treba identifikovat zakladny set ZS, ktory treba pokryt na IOMO a ostatne na IOMO neriesit.

Bolo povedane, ze JKM (jednotne kontaktne miesta) maju problem s IOMO lebo nevedia robit hotovostne platby.

Prioritne sa bude robit ZS - 7 kusov - nepovedalo sa ktore to su

Dalsie poznamky

  • buduci stvrtok dokument na interne pripomienkovanie
  • 14.12. - zacne verejne pripomienkovanie dokumentu
  • bude zavedeny schvalovaci mechanizmus pre nativne aplikacie (postrazit si) podobne ako UK
2 Likes

Toto je trochu nešťastná formulácia, keďže nariadenie eIDAS pozná len tri úrovne zabezpečenia a to „nízka“, „pokročilá“ a „vysoká“ (mapovanie na STORK úrovne QAA 2, 3 a 4). Navyše eIDAS legislatíva definuje použitie elektronického podpisu len na podpisovanie údajov a nie autentifikáciu, takže autentifikácia cez ZEP/KEP je v rozpore s eIDAS nariadením.

Stanovisko EK:
“an eSignature can only be used by a natural person to “sign”, i.e. mainly to express consent on the data the eSignature is put. This represents a difference from the eSignature Directive where the eSignature – which could also be used by legal persons – was defined as a means for authentication”

Podľa ENISA (https://www.enisa.europa.eu/publications/eid-cards-en, kap.4.3.2. Authentication vs. Digital Signature) elektronický podpis (PKI koncept) nie je vhodný pre použitie na účely autentifikácie osôb, nakoľko predstavuje narušenie ich súkromia a tým porušuje “minimal disclosure” princíp požadovaný EU zákonom o ochrane osobných údajov (http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:31995L0046)

4 Likes

Diky, opravene preklep. Bola myslena autorizacia. @Lubor isto opravi aj ine nepresnosti. Ospravedlnujem sa.

A modul opravneni bude autorizovany cez ZEP? :slight_smile: Jedine riesenie na zrusenie zrusenia prevodu majetku ZEPom bude potom vybavit to papierovo/notarsky overenym podpisom. Tu IMHO hrozi, ze si ludia preventivne vsetko povypinaju a sme v bode 0.

Ja navrhujem riesit to viacfaktorovou autentifikaciou/autorizaciou, cize napr. by som si zvolil, ze okrem ZEP chcem este aj nieco ine (podpis pred notarom, ZEP od inej osoby/inych osob, atd.) Predpokladam, ze trh by prisiel s dalsimi moznostami, ktore by to zjednodusili. Napr. poistovne s produktom, ktory by spolu s poistenim nehnutelnosti prinasal klientovi druhy online sposob autorizacie prevodu vlastnictva nehnutelnosti, pricom poistnou udalostou by bol hack tohto sposobu autorizacie.

1 Like

Pokiaľ tieto služby budú dôveryhodné podľa eIDASu tak by nemal byť vôbec žiadný problém prepojiť ich so schránkami.

Napr. České mojeID v konzorciu s niekym zo Slovenska by mohlo byť využité ako autentifikačných nástroj k eschránkam.

Alebo online riešenie autorizácie sa a service od disigu, len je dôležité aby to bola dôveryhodná služba podľa nariadenia.

Pochybujem že Facebook sám o sebe bude môcť byť použitý ako autorizácia, nepredpokladám že Facebook má ambíciou byt dôveryhodnou službou v zmysle eIDASu.

Pri komunikácii zo štátom pokiaľ nechceš dopĺňať podanie v listinnej podobe si limitovaný kepom. Lebo len KEP je uznaný ako vlastnoručný podpis. Podľa agendových predpisov všetky podania musia byť podpísané. Pokiaľ nemáš podanie podpísané vyzve ťa na podpísanie s tým, že keď podanie nepodpišeš na podanie sa neprihliadne/odmietne. Takto to fungovalo aj keď sa podania faxovali, dalekopisovali a dokonca aj keď sa e-mailovali.

Nemyslím si, že by sme boli v bode 0, ak si dnes v tatrabanke viem obmedziť kartové operácie cez internet na 0,- EUR tak ich banka jednoducho nezrealizuje. V prípade, že potrebujem realizovať platiť cez internet tak si zapnem platby cez internet, resp si nastavím limit.

A rovnako nie je zlé, ak si viem nastaviť další faktor autorizácie, token, SMS.

Otázkou je, čo so sprísneným úkonmi napr. Prevod Nehnuteľností.

1 Like

Ak vies vypnut/zapnut platby cez internet cez internetbanking, tak to nie je ziadna velka ochrana, v pripade, ze mas napr. kompromitovany pocitac/mobil. Motivovany utocnik ti pred vybielenim uctu zmeni nastavenie. Preto je podla mna lepsie ist cestou viacerych faktorov.