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

Doslo z UPVII.

V mene ÚPPVII si vás dovoľujem pozvať na prvé zasadnutie pracovnej skupiny Lepšie služby v roku 2018. Prešli by sme si plánovaný program na najbližšie obdobie, požadované výstupy z PS a kde sa prelíname s programom ostatných PS, najmä s PS Architektúra. Rovnako dohodneme aj režim a témy ďalších zasadnutí.

Ako prvú vecnú tému by sme zároveň prešli návrh Dopytovej výzvy Malé zlepšenia eGov služieb, ktorú nám príde predstaviť zástupca ÚPVII (V. Hainzl/Silvia Drahošová). Podkladová prezentácia je na Sharepointe v MetaIS, v záložke PS Lepšie služby/Vstupy/2018/. Privítame, ak sa s obsahom dopredu oboznámite. V prípade otázok som k dispozícii.

Bolo by vhodné, ak by sa na diskusii k tej dopytovej výzve riešilo aj to, či je možné obstarať takýto malý projekt tak,

  1. aby to mohol vyhrať aj niekto iný ako pôvodný dodávateľ, alebo
  2. aby to mohol urobiť aj niekto iný ako pôvodný dodávateľ.
    V tomto mám veľkú obavu, že to buď nebude obstarateľné alebo to bude dodávať pôvodný dodávateľ ako sub “víťaza” súťaže.
1 Like

Neviem ci sem mozem zavesit tu prezentaciu uz teraz, po stretnuti sa budem snazit ziskat ju na zverejnenie tu. Inak veducim PS je po novom @kyselat. :clap:

Neocakavane bola na PS architektura tato prezentacia, takze som vyuzil komenty co tu zazneli a co mi @peter_k poslal. Tu kratky zapis, z tejto casti:

  • nebudu sa robit nove reformne zamery
  • upozornil som na to, ze pocet podani nemusi byt uplne dobre KPI - kedze:
    • niektore podania by mali uplne zmiznut a robit sa automaticky (na toto bola odpoved, ze musia prejst konzultaciou s EVS ludmi, ze ci to zapada do optimalizovanych procesov)
    • nie vzdy velka pocetnost = vela usporenych penazi alebo velke prinosy (odpoved na toto je, ze teraz idu po tych naozaj pocetnych a bude tam studia aj verejne pripomienkovanie a vsetko cize sa to odhali)
  • ako podmienku pre projekty som navrhol povinne reportovat metriky do metais (digital uptake, pocet podani…) toto je pripravene, staci to pouzit. (odpoved: dobry napad, aj my ked sme zacinali, sme vlastne ziadne data nikde nevedeli najst :frowning_face:
  • povinna dostupnost cez UPVS = len aby to bolo v katalogu.
  • upozornil som, ze nie vsetky podania ludia chcu robit elektronicky a podla strategie tu navrhutej aj schvalenej a musi sa robit channel-fit. (odpoved: ano, pomozte nam ako a kedy to obstarat, nevieme. otvorena otazka. imho sa to musi udiat bud v studii alebo niekde predtym. toto naozaj nie je raketova veda a moze to usetrit vela zbytocnych projektov. napady?)
  • rypava otazka: “bude to moct urobit aj niekto iny ako sucasny dodavatel?” (odpoved: skupina VO/governance by sa mala seriozne rozhybat a toto vyriesit (cc @janhargas) jednak do buducna a dvak aj do minulosti.)
  • taktiez som povedal, ze niekedy mozno staci otvorit API namiesto robenia appky/lepsieho formulara…atd. Hlavne v kontexte rypavej otazky vyssie.
1 Like

Zapis z PS Lepsie Sluzby dnes:

Temy na lepsie sluzby (co sa bude robit najblizsiu dobu) - dokumenty

  • koncepcia + vyhlaska: podpis klikom / mobilna autentifikaca a autorizacia
  • koncepcia API GW
  • formulare a lepsie sluzby

Dopytove vyzvy

  • manazment udajov - 30M ak bude treba navysia
  • male zlepsenia egov sluzieb
    • 80k - 800k cena na projekt
    • 22mesiacov max trvanie projektu
      • podmienky
        • musia byt vo schvalenych RZ alebo v popisoch procesov OP EVS

Diskusia: zlepsenie sluzieb

  • staci na lepsie popisat sluzby ju lepsie popisat? ak je to uveritelne tak preco nie.

  • open api - len otvorit api niekedy staci

  • robil sa prieskum prioritnych API, mozno to tam zaradit

  • behavioralny tim - moze vstupovat do projektov - memorandum o spolupraci

  • ako to bude vyzerat v praxi?

    • ked do toho zasiahnu v strede projektu tak to rozbije dodavatelovi plan a budget
    • agile vs waterfall diskusia
  • OP EVS

    • ministerstvo spravodlivosti - neboli v OP EVS, RZ nie je koncipovany uplne na zivotne situcie, ako sa moze zapojit? bude stretnutie s nimi.
  • ako bude vyzerat zivotny cyklus projektu z pohladu ziadatela?

Budu studie!

  • “vykuchana studia”

    • z OP EVS je procesna mapa, granularita ma byt ovela nizsia, nejake “skoro” zadanie
    • mala by odpovedat aj na to ci to niekto chce (channel-fit) - toto potrebujeme tam navrhnut
    • bude refundovana z EU alebo OVM plati sama? zistia.
  • vystupy EVS - maju ich dostupne OVM co ich robili

Prezentaciu bohuzial nemozem zverejnit, kedze to je draft. dovodom som uplne nepochopil, ale ked ju niekto chcete mozem vam ju poslat (mam dovolene).

Pripomienky sa posielaju do utorka!


Poznamka pod ciarou: NASES opat poslal zapisovatelky, ktore boli cely cas ticho. :frowning:

sme si isti, ze existujuce RZ alebo popis procesov OP EVS toto popisali?

je mozne aktualizovat RZ, OP EVS, aby sa tam pripadne chybajuce zlepsenia dostali? ak ano, kolko to bude cele trvat?

no, ak neschvalia ZoNFP, tak nebude refundovana

jedine, ze by napr UPVII pripravil ZoNFP, ktorej podstata bude zrealizovanie jednotlivych studii

myslia sa tym existujuce API, ktore by sa mali otvorit alebo budeovanie novych API?

kto, kedy, akou metodikou a na akej vzorke robil prieskum? je mozne mat tieto info a aj vysledky daneho prieskumu?

moze alebo musi? ake ma konkretne pravomoci - poradne, ci schvalovacie a rozhodovacie? ak iba moze, tak ake kroky na strane ziadatela budu akceptovane, aby sa nestalo, ze behavioralny tim vstupi do projektu neskoro a vznesie pripomienky, nazory, ktore by mohli zmenit charaketer, plan, rozpocet a pod. projektu? napr. UX vyskum na reprezentativnej vzorke bude akceptovatelny?

tazko porovnavat 80k a 800k projekt, kde pri 80k si viem predstavit, ze znalost bude velmi detailna. Pri 800k podla mojich skusenosti sa detailnost strati

dolezite je, aby studia v prvom rade rozhodla, ci dana iniciativa, investicia ma realny vyznam alebo nie, identifikovala realne potreby, poziadavky a na ich zaklade navrhla, nacrtla moznosti riesenia

dalej je dolezite, aby studia namodelovala vstupy do VO, t.j. aby zhodnotila moznosti implementacie danej investicie, zhodnotila moznost vyuzita jednotlivych technologii,napr. open source, zhodnotila za akych podmienok je mozne, aby danu iniciativu dodaval aj iny subjekt ako je subjekt, ktory dodava sucasne riesenie, v pripade, ze sa buduje/rozvija/upravuje existujuce riesenie, vydefinovala PHZ, atd.

-> ale to co sa tu nespomina a je jeden z najdolezitejsich aspektov v ramci implementacie eu fondov su hodnotiace/vyberove kriteria…ich obsahom, strukturou, bodovym ohodnotenim a pod. vie vyhlasovatel vyzvy do velkej miery modelovat a ovplyvnit predkladane ZoNFP z ich obsahoveho hladiska, planovanych aktivit…ak napr. UPVII ma ambiciu, aby sa realizovale male projekty, ktore prinesu vysledok rychlo (napr. projekt s rozpoctom do 200k a dodany za 6-8 mesiacov) tak vie takymto projektom udelit v hodnoteni dodatocne body, alebo ak ma UPVII ambiciu podporovat open source technoilogie, tak opat vie postavit kriterium, ktore riesenia s open source technologiami zvyhodni bodmi navyse a zaroven v ZoNFP a jej prilohach uz budu musiet byt konkretnejsie informacie, aby sa dalo zhodnotit ako dana ZoNFP splna konkretne kriterium

-> ked bude mat UPVII jasne v hodnotiacich kriteriach, tak moze zacat hladat a vyberat hodnotitelov, t.j. odborne kapacity, ktore budu schopne a ochotne ist hodnotit dane ZoNFP…myslim, ze by to UPVII mal zacat robit co najskor …IT trh a zvlast public cast je maly, podla mojho nazoru, ten proces nebude uplne jednoduchy

-> v nadvaznosti na studie a odborne hodnotenie bude treba premyslat v tomto kontexte Participacia na studii uskutocnitelnosti a nasledna ucast vo verejnej sutazi na dodanie riesenia = konflikt zaujomv?**

2 Likes

Spisal som pripomienky sem: https://docs.google.com/document/d/15NTbPh88NMAjUgGFtG4US48XXdvgzgIPtIUiFEQsZsU/edit

Smelo dopisujte cez “suggest” alebo komentare tam alebo tu. Niekedy vecer to podla dohody poslem @kyselat

Poslana aktualna verzia. Pripomienkovanie - Dopytova vyzva male zlepsenia egovu.odt (21.5 KB)

V mene ÚPPVII si vás dovoľujem pozvať na ďalšie zasadnutie pracovnej skupiny Lepšie služby. Prešli by sme si tému publikovania služieb do multikanálového prostredia.:

Kontext ešte z minulého behu PS Lepšie služby (prečo je potrebné sa témou zaoberať)
Informácia o metodike, ktorú dáva dokopy PS Architektúra
Ktoré služby by bolo dobré publikovať ako OpenAPI pre dosiahnutie „quick wins“ (krátky vstup pre nás pripravia kolegovia z Slovensko.digital, ale ak má niekto v hlave nápady k tejto téme, pošlite mi mail a pridám do programu)

Ja idem prezentovat otvorenie API/formularov pre podania na slovensko.sk, ktore by podla nasho nazoru velmi zjednodusili sposob integracie tretim stranam. Idea je nasledovna

  1. clovek na stranke tretej strany v nejakom peknom “wizarde” vyplni potrebne udaje (napr. na zalozenie zivnosti)
  2. klikne na button “poslat cez slovensko.sk”
  3. treto stranou vytvorene formularove xml (kedze to je vymenny format) sa odosle na povedzme podanie.slovensko.sk, tam sa zobrazi TXT/HTML vizualizacia a jeden button dole podpisat a odoslat.
  4. Nasledne zbehne prihlasovaci flow a pripadne aj podpisovaci. centralne.
  5. po uspesnom alebo neuspesom odoslani je clovek presmerovany spat na tretiu stranu, ktora sa dozvie o vysledku podania. (cez callback co tam posle)

V principe by toto mohlo fungovat aj uplne bez akychkolvek dohodach o integracii s tretimi stranami. (predpokladam, ze pravnici a bezpecaci budu mat okamzite nejaky iny nazor).

V minimalistickom rezime by stacilo otvorit API na podania, takato podstranka by vsak zjednodusila cely proces este ovela viac. V principe aj vyvojari systemov pre OVM by nemuseli prechadzat zlozitou komplikovanou integraciou ale vyuzili tento centralny komponent. Nie je to nic svetoborne, do velkej miery to takto presne bolo navrhnute a schvalene aj strategickej priorite interakcia s VS…

Ked mate nejake tipy na otvaranie API alebo “male zlepsenia egovu” sem s nimi. Stretnutie je buducu stredu.

Finacna sprava - maju uz teraz moznost pre kazdy formular (s ktorym som sa stretol ja) uploadnut xml, ale manualne…otvorenie na strojove spracovanie by pomohlo

1 Like

Prezentaciu na zajtra sem davam v predstihu. Komentare privitam.

1 Like

Zapis z dnes:

  • Najprv bola prezentacia od @msurek, nie uplne som pochopil, ze preco na PS lepsie sluzby sa to bralo do takeho detailu. Ale ako info ok.
  • Potom som mal prezentaciu ja (vid vyssie). Na moje pocudovanie panovala velmi prudka zhoda, ze toto treba spravit cim skor a co najjednoduchsie.
  • @kyselat vyzval dalsich nech prichadzaju s podobnymi napadmi na male zlepsenia/otvorenia egovu. Padli navrhy na otvorenie platby kartou, mobilne prihlasovanie, otvorenie prihlasovania ako takeho tretim stranam (rovnaky navrh u nas je tu Proof of Concept pre OAuth s eID), zjednodusenie pristupu k transformaciam formularov (myslim, ze dokonca rovnaky navrh padol tu Zdielanie definícii eFormulárov a realizácia transformácii), zjednodusenie pristupu do schranky tretim stranam.

Cize ak mate nejake napady na male zlepsenia a otvorenie API, tak teraz je dobra prilezitost.

2 Likes

V mene ÚPPVII si vás dovoľujem pozvať na ďalšie zasadnutie pracovnej skupiny Lepšie služby. Pokračovali by sme v téme quick-win publikovania služieb do multikanálového prostredia. Od posledného stretnutia by bolo dobré detailnejšie prejsť nasledovné témy.:

  1. „Formulár ako služba“ (z minulého meetingu) a otázka bezpečnosti scenára (3d party landing page, vs. landing page pod gesciou napr. v NASES). Doručovanie podaní cez schránky, vs. cez portál a agendový systém (Zákon o eGov vs. výnimky a povolené prechodné obdobia). Vstup od kolegov z S.D.
  2. Od kolegov od dopytovej výzvy „Malé zlepšenia eGov služieb“ sme dostali zadanie, viď nižšie.

Zadanie nizsie:

Zadanie do PS Lepšie služby:

Aká może byť predpokladaná výška žiadaných financií per projekt - tj o váš expertný odhad, čo všetko sa dá doručiť 1 projektom, ak oprávnené aktivity sú dané nasledovne:

Žiadateľ projektom prinesie povinne

  1. všetky zlepšenia služby alebo časti konkrétnej služby v súlade so zoznamom a popisom atribútov uvedených v prílohe č.12, ktoré popisujú čo všetko má e-služba obsahovať pre zabezpečenie dobrej zákazníckej skúsenosti používateľa v súlade s jednotným dizajn manuálom e-služieb; v prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní; a

  2. responzívny dizajn, v prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní.

  3. používateľské rozhranie (front-end, GUI) a postupnosť krokov pri realizovaní elektronickej služby nadizajnované na základe kompletnej UX analýzy, pozostávajúcej minimálne z nasledovného:

    i. definovanie hypotéz vlastníka IS

    ii. identifikovanie persón/typov používateľov,

    iii. user needs research (prieskum potrieb používateľa),

    iv. identifikovanie a prioritizácia problémov vyplývajúcich z user needs researchu

    v. návrh testovacích scenárov.

    vi. testovanie podľa testovacích scenárov s využitím focus groups.

    vii. pri testovaní má byť využitá forma A/B testovania, alebo RCT (Randomized Controlled Trials), alebo iná podobná bežne akceptovaná forma UX testovania.

V prípade ak je aktivita podľa bodu 3 pre jednotlivú službu nerelevantná, žiadateľ to zdôvodní.

  1. elektronické poskytovanie informácie pre občana / podnikateľa o stave vybavovania elektronickej služby. Ide o poskytnutie informácie o zmene stavu podania, ktorá nastane po zrealizovaní samotného podania.

  2. imlementáciu štandardného Google Analytics, tak aby bolo možné analyzovať početnosti prístupov k elektronickej služby, počet úspešne zrealizovaných podaní, zdroje návštevnosti elektronickej služby, a pod. V prípade ak je to pre jednotlivú službu nerelevantné, žiadateľ to zdôvodní.

  3. bude minimálne pripravené (ak nebude možné riadne zrealizovať) automatizované (napr. pomocou web služby) poskytovanie informácie o úspešne zrealizovanom podaní pre ÚPVS; ide o poskytnutie základnej informácie - identifikátora služby (ID) spolu s informáciou, že bolo úspešne zrealizované podanie.

K tomu žiadateľ je oprávnený priniesť aj ostatné typy zlepšenia e-služieb výberom od 7) až 11):

  1. nastavenie aktívnych „listenerov“ pre registráciu udalostí, vytvorenie integračných väzieb cez platformu integrácie údajov,

  2. umožnenie online platenia,

  3. prihlasovanie/ podpisovanie pomocou Smartfonu (vtedy, keď bude centrálne riešenie k dispozícii),

  4. dosiahnutie multikanálového prístupu,

  5. zriadenie proaktívnej služby (úroveň 5 v zmysle výnosu o štandardoch)

PLUS ešte povinne:

12.) Žiadateľ zabezpečí, že služba bude zrealizovaná, resp. upravená tak, aby sa pri jej volaní realizoval prístup na backend (volanie backendových služieb) výlučne cez webAPI Gateway (v zmysle zákona o eGovernmente Modul procesnej integrácie a integrácie údajov, bod a) jednotné pripojenie a interakcia prístupových miest). Toto platí v prípade všetkých prípadov spustenia služby, tzn. aj v prípade spustenia služby cez rezortný portál. Takto publikovanú službu je možné prepoužiť aj v budúcich scenároch (napr. sprístupnenie tretím stranám) a umožní to monitorovanie využívanosti služby.

V prípade, ak nebude webAPI Gateway v danom čase k dispozícii, je potrebné zabezpečiť aspoň definíciu rozhrania služby v zmysle otvoreného API kedykoľvek publikovateľnej pre priamy prístup tretích strán.

13.) Žiadateľ zabezpečí, že služba bude dostupná cez ÚPVS. (portál ÚPVS prinajmenšom odkáže na konkrétnu webovú stránku verejnej správy poskytujúcej službu, alebo poskytuje priamo konkrétnu službu).

@lubor poznamenal, ze k 1. je to vyriesene v zakone (a.k.a - podanie kliknutim) https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2013/305/20180401#paragraf-23.odsek-1.pismeno-a.bod-2

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

  1. kvalifikovaným elektronickým podpisom17) alebo kvalifikovanou elektronickou pečaťou,18)
  2. použitím na to určenej funkcie informačného systému prístupového miesta a po úspešnej autentifikácii osoby ktorá autorizáciu vykonáva, zodpovedajúcej najmenej úrovni zabezpečenia „pokročilá“ podľa osobitného predpisu,20a) ak sa zabezpečí uvedenie tejto osoby ako odosielateľa elektronickej správy, nemennosť obsahu autorizovaného dokumentu do momentu uloženia v elektronickej schránke adresáta, spojenie autorizovaného dokumentu s identifikátorom osoby odosielateľa a zachovanie väzby medzi nimi, ak to osobitný predpis nezakazuje alebo
  3. uznaným spôsobom autorizácie, ak to osobitný predpis nezakazuje,

Áno, pri autorizácii kliknutím musí ÚPVS zabezpečiť autentifikáciu+vloženie (vyplneného) formulára+zobrazenie formulára+veľké tlačítko “podávam”. Toto ak sa spraví dobre, tak sa môže priamo použiť ako realizácia autorizácie kliknutím pre používateľov ÚPVS ktorí prišli “štandardne”, pre tých čo budú presmerovaní z app tretích strán, a detto aj pre používateľov z mobilných platforiem.

Pri podaniach autorizovaných KEPom stačí, ak ÚPVS umožní čo najjednoduchšie použitie API na podanie. Nie je potrebná ani autentifikácia používateľa (jej vyžadovanie je imho porušenie zákona), ani žiadna interakcia s používateľom (netreba GUI).

Ak má zmysel, môže samozrejme existovať aj služba, ktorá umožní zobrazenie+podpísanie KEPom+odoslanie podania.

1 Like

Keď čítam definíciu v zákone, osobne sa mi nezdá tento výklad automaticky ako jediný možný. Som samozrejme “za” myšlienku “Formuláru ako služby”, ale nezdieľam presvedčenie, že postačuje argumentácia štýlu - “stačí ak dodržíte zákon”. Podstatu návrhu “Formuláru ako služby” vnímam v tom, že prístupové miesto publikuje tech. rozhranie, na ktoré je možné sa pripojiť (aj keď sú to redirecty - teda prepojenie na “UI” vrstve). Úprava v zákone rieši len samotné vyjadrenie vôle (podpis), nie povinnosť publikovať tech. rozhranie. Prakticky: prístupovému miestu (napr. ÚPVS) postačuje zaviesť framework pre “centrálne” definície vypĺňacích formulárov, ktorý dá k dispozícii OVM nech si pomocou nich formuláre vytvoria. A tieto formuláre budú mať na konci to tlačítko “podpísať”. Podstatný rozdiel je, že napriek 100% kompatibilite so znením v zákone, “integračné rozhranie”, na ktoré by sa mohol niekto pripájať nikde nevznikne.

Plus malá technická poznámka k podpisu klikom - bez ohľadu na to akou technickou formou sa vyjadrenie vôle udeje, na konci je elektronický podpis (nejakej úrovne) - inak sme mimo právneho rámca EIDAS. Takže služba, ktorá umožní zobrazenie + podpísanie (nemusí byť len najvyššia úroveň) + odoslanie podania je jediná možná, nie len akýsi doplnok.

Ach, opäť táto téma. S eIDAS toto nemá nič. Presnejšie, eIDAS nijako nelimituje možnosť krajiny spraviť si pre seba hocaké autorizačné mechanizmy aké len chce. Čiže nie, “na konci” elektronický podpis byť NEMUSÍ.

(Dôkaz sporom: už dnes existuje plno podaní, ktoré nie sú autorizované el. podpisom. eIDAS platí a tieto podania sú zjavne legálne a platné. ČBTD)

Samozrejme, že eIDAS nelimituje možnosť spraviť si v rámci krajiny proprietárny mechanizmus pre vyjadrenie vôle, mimo rámca, štandardov (a regulácie) EU (eIDAS). Ale načo by to tá krajina robila, s čím presne si pomôže? Ak krajina použije elektronické podpisy (nemusia byť iba KEP a teda môžu byť aj lacné), tak získava synergický efekt z toho, že prípadné hrozby a príležitosti (inovácie) sleduje a rozvíja okrem danej krajiny aj kopec iných krajín. Nehovoriac o otvorení dverí pre budúce interoperabilné scenáre (budem môcť vyjadriť vôľu prostriedkom, ktorý používam v SR - aj pri podaní v inej krajine EÚ).

Naspäť k pôvodnej téme (“formulár ako služba”), pretože to ma kvôli zajtrajšej pracovnej skupine zaujíma viac. Proti mnou navrhnutej interpretácii zákona si nenamietal, takže ju beriem ako “uznané spresnenie”?

Ani ja, z čoho máš pocit že áno? O PODaaS v zákone nie je nič a nevidím potrebu tam v tejto súvislosti ani niečo pridávať/meniť.

Áno, to je predsa súčasť definície. Písal som, že aká asi funkčnosť má nasledovať v rôznych scenároch “po” pripojení sa na toto rozhranie. A konkrétne vidím 3 dosť rôzne scenáre, ktoré všetky majú opodstatnenie - samozrejme je na zváženie je ktorý/kedy/kto implementuje. Najjednoduchší scenár je to podanie už autorizované KEPom, stále nechápem prečo takéto niečo ešte neexistuje.

Toto imho nemá s PODaaS taktiež nič spoločné. Stále sa vlastne vraciame k téme “čo všetko má formulár robiť”. Pri téme PODaaS je “vypĺňacia” funkčnosť úplne irelevantná. Jediná potrebná je definícia formulára a vizualizačná transformácia. A tie si môže (z pohľadu PODaaS) vytvoriť kto chce ako chce. Tlačítko “podpísať” nie je súčasťou vizualizácie (a teda nie je súčasťou “formulára” v zmysle o akom tu hovoríme), je to funkčnosť obslužnej aplikácie, či už ide o KEP, autorizáciu kliknutím, alebo Tebou preferovaný AdES.

Btw. teraz tu píšeš za seba, či za ÚPVII, alebo ako?

Naopak, každá krajina (a aj SR odjakživa) má množstvo takýchto spôsobov. Robia to tak, lebo je to efektívne. A najmä - verejná správa nie je pupok sveta, ani v EÚ (a eIDAS nie je o verejnej správe). Pozri sa na komerčnú a občiansku sféru. Napr. také e-shopy, alebo veľké platformy, interné procesy vo firmách atď. atď. “Proprietárny mechanizmus” kam len pozrieš a (skoro) nikde elektronické podpisy! (a je to v poriadku)

Veľmi rád si pozriem porovnania jednotlivých variantov z hľadiska ceny, technických nárokov, aj požiadaviek na používateľa.

Nemajme veľké oči. Práve autorizácia kliknutím má byť pre tie jednoduché veci, ktoré netreba nijako komplikovať.

Mimochodom, EÚ po 20 rokoch snaženia nedokázala poriadne spraviť interoperabilným ani ten KEP.

Ale ja vlastne súhlasím s tým čo píšeš - “použije elektronický podpis”, v zmysle eIDAS. Tam podľa čl.3.10 elektronický podpis “sú údaje v elektronickej forme, ktoré sú pripojené alebo logicky pridružené k iným údajom v elektronickej forme a ktoré podpisovateľ používa na podpisovanie”. Napr. do príslušného políčka v XML vpíše podpisovateľ svoje meno.

Palec Hore … toto umozni vstup konkurencie na vyarendovane pole … :slight_smile:

Ad.: “Ani ja, z čoho máš pocit že áno? O PODaaS v zákone nie je nič a nevidím potrebu tam v tejto súvislosti ani niečo pridávať/meniť.”. Vzniklo to z tohto.:

Poďme ďalej.:

Zjavne si ma len nepochopil. Nepotrebujem dovysvetľovať, čo by mal formulár robiť. Myslím, že sa v tom zhodujeme. Ja som uviedol príklad, ktorý sa pod tú “gumovú” definíciu podpisu “klikom” (na ktorú sa odvolal Jano a potom ty) v pohode “zmestí” a výsledok je úplne iný, než všetci chceme. Niečo na spôsob tvojho neskoršieho dôkazu sporom.

Ďalej.:

Keby si čítal-vykopíroval aj predošlú vetu, tak z nej vyplýva, že za ÚPPVII. A hlavne.: Ako toto súvisí s vecnou argumentáciou?

V eShope (a všeobecne v obchodnom vzťahu) je jasné, že niečo myslím naozaj vážne, až keď za to zaplatím. Vyjadrenie vôle zaplatením. Načo by tam bol ešte aj elektronický podpis? Interné procesy vo firmách nie sú primárne o vyjadrovaní vôle, ale o práci zamestnanca pre zamestnávateľa. Tu tiež nie je potrebný elektronický podpis. Atď.

Super, ja rovnako. Doplním ešte vecné kritérium, že ten kto vôľu vyjadruje, by mal mať (podľa možnosti danej alternatívy) čo možno najviac pod kontrolou prostriedok pomocou ktorého vôľu vyjadruje. Len aby sa nezabudlo.

Chápem, že dôvodov na optimizmus nie je veľa (nakoniec medzištátna interoperabilita asi nie je ten najväčší problém eGov implementácií - ani u nás), ale keďže si len relativizoval a neuviedol protiargument, tak sumarizujem.: Proprietárny klik bude interoperatilný takmer s nulovou pravdepodobnosťou. Pri elektronickom podpise (regulovanom cez eIDAS) je pravdepodobnosť výrazne vyššia. Zvyšok je len otázka porovnania jednoduchosti použitia, nákladov implementácie, možnosti a dopadov zneužitia, atď.

Výborne, tak sme si teraz len zopakovali, že eIDAS reguluje len od úrovene “pokročilého podpisu” a vyššie. Pod tým môže byť prakticky čokoľvek (viď tvoj príklad), ale eIDAS s tým nič nemá, neposkytuje žiadne usmernenie. A KEP sme sa zhodli (aj keď ten je naopak veľmi detialne regulovaný cez eIDAS), že je na mnohé služby “overkill”. Logicky sa AdES pre dosť služieb javí ak nie rovno optimálna, tak aspoň veľmi sľubná alternatíva (na to posudzovanie a porovnávanie, viď vyššie).