Otazka bola “Preco by mala byt pre obcana povinnost prijmat spravy (s pravnym ucinkom), ak ma moznost posielat spravy?” - naozaj ma zaujimali dovody 
pretoze to je analogia s postou, ak nemas technicke dovody na nepreberanie posty, tak mas povinnost ju prebrat ( a ak nie, tak nastupuje fikcia dorucenia ).
A to ma pravny ucinok, elektronicke dorucovanie je analogia postoveho dorucenia.
1 Like
ale tu nikto nehovori o KEP, vratme sa s pat k teme mID ako authentifikator pre prihlasenie v desktope a pre prihlasenie v modilnom zariadeni ci uz v rmaci aplikacie alebo v browsri v responzivnom dizajne. druha tema je autorizacia klikom tu si to musi kazde pristupove miesto realizovat bud samo alebo mozme uvazovat na centralnejsom rieseni pomocou mID ale zatial plati nikto nieje limitovany nicim
zatial nas nikto k tomu nenuti a predpokladam ze nebude ani v pripade ze si dam aktivovat mID
presne tak ked to prikaze zakon tak ako pre PO tak ano budeme povinny aj ako FO, suhlas, vsetko ostatne je vyhybanie sa prebrati a nastupuje fikcia. A ked bude taky zakon v pripomienkovommkonani mozme vyzuti vestky sposoby na jeho zmenu ale zamietnutie, ak bude platiti budeme preberat aj v eDesku… 
aj eKasse sa ludia branili a musia ju pouzivat 
v projekte slovensko v mobile neriesia KEP ako som pisal vyssie. Ale BTW ani na obciansko nic nešifrujes v karticke, mimo kraticky spravis HASH (ten haash podpises privatnym klucom - ano toto je nazvyme sifrovanie - ak si myslel teda toto) pricapis certifikat znovu mimo karticky v podpisovacom komponente, pribalis povodny dokument z ktoreho si robil HASH. to podrvhnutie resp ochrana pred podvrhnutim je porovanie HASHov 1. HASH vyrobeny z toho povodneho dokumentu v konatjneri 2. HASH ten ktori je v kontajneri zasifrovany tvojim privatnym kluco desifrujes verejnym) - ale toto sa v tomto projekte neriesi tu sa riesi len authetifikacny certifikat (kde privatny kluc bude v mobile, verejny pri onboardingu zaregistrujes na servri)
tvoj verejny kluc zo zariadenia priradeny k identite v IAM. A ano ked si poviem ze alternativny authentifikator bude heslo tak staci… :) ked s tym budeme spokojny preco nie 
toto sme tu uz mali planovane, sice primarne pre PO. volalo sa to UNITAS a vieme ako to dopadlo. ale s konceptom suhlasim a tam by sme sa mali uberat. ale spat k teme Slovensko v mobile, lebo fakt v tomto vlakne rozoberam vsetky projekty pod vymyslu sveta…
Bezpečnostná úroveń bude o jeden supeň nižšia. Deklarovaná úroveň vo zverejnených materáloch o SvM hovorí o bezpečnostných zárukách QAA úroveň 3. Nateraz odhliadnimi od toho, že sa odvolávali ešte naúrovne podľa STORK a tie sú preč už vyše 7 rokov, no ak to preklopíme do sveta eIDAS a požiadaviek na úrovne záruk, tak je na úrovni “Pokročilá”, nie “Vysoká”. Tie požiadavky nie sú len o tom, ako efektívne viem zablokovať prostriedok, je tam toho omnoho viac. Ochrana kryptomateriálu je tiež jedna z nich a tá nie je ako pri QSCD… Pre úplnosť a lepšiu predstavu - v konečnom dôsledku to aj znamená, že prístup pomocou mID na tejto úrovni nebude pre služby vyžadujúce úroveň autentifikácie “Vysoká”. Autorizácia klikom vs. KEP - toho už bolo popísaného dosť, zbytočne tráviť nad tým čas - je to národné špecifikum.
Prepoužijem Babišovu reč. V tom prípade “Sorry jako”. A to isté by Vám povedala každá banka, ak by Vám takto urkadli platobnú kartu. Je pravda, že bez znalosti BOK sa ku kľúču (alebo iným údajom) nedostanú, šanca je mizivá/prakticky nulová. Avšak bol by som veľmi opatrný v domnienkach, že biometria na mobiloch je bezpečnejšia alternatíva k PIN-u, práve naopak (vlastne ako hovoríte neskôr, tie možnosti a vektory útokov sú pestré a existujú aj zraniteľnosti v TEE/SE, na ktoré sa viaže overovanie používateľa pomocou biometrie). Biometrický prvok je akýmsi “pohodlnejším” doplnkom, no primárny faktor /aj aj fallback scenár/ je vždy PIN - prečo asi? A čo ak si ten PIN pre mID používateľ zapíše v plaintexte kdesi na telefóne? Alebo bude zhodný s tým, ktorý zadáva na odomknutie obrazovky? Hmm, alebo útočník toto celé obíde a získa priamo kľúč z toho “bezpečného” úložiska? A teraz do porovnania dajme ešte čisto softvérové riešenia bez TEE/SE, kde sa ochrana spolieha výhradne na SW mechanizmy - možno DEUS - myslím, že sa na S.D tiež pýtali niektorí, že či je dostupné verejné hodnotenie bezpečnosti/aspektov riešenia…? Akože na “Pokročilá” to pravdepodonbe stačí v oboch prípadoch, ale nie je riešenie ako riešenie a bezpečnosť ako bezpečnosť…
2 Likes
so vsetkym co si napisal plne súhlasím, a nevidim ze by to bolo v rozpore s tym co som uz pisal ze projekt neriesi autorizaciu na urovni KEP,
opravim sa v mojej druhej vete:
ale hadam len takyto koncept nechceme aj na atuhentifikaciu zachovat to by bolo uz moc.
inak nevidim medzi nami ziadny rozpor.
Samozrejme je potrebny ten predpoklad sa nebude zbytocne vyzadovat vysoka uroven authentifikacie QAA 4/LoA high (co je podla mňa už naplnene) a pripadne pre vacsinu sluzieb bude nasledne stacit aj autorizacia klikom
ci niekde tomu ja zle chapem ?
Toto navodzovalo dojem, akoby úroveň zabezpečenia mID malo byť rovnaké ako pri eID. Tak to však nie je a ani to nie je cieľom mID, v tom sa zhodneme. V širšom kontexte to bolo otázka smerovaná na
Nesnažil som sa hľadať rozpory - to je asi nedorozumenie. Skôr akoby sa odpoveď trochu “zatúlala” pri týchto otázkach, pretože nebude zachovaná obdobná bezpečnosť autentifikácie, ale bude realizovaná nižšia úroveň bezpečnostných záruk ako pri eID (bez ohľadu na spomínané spôsoby onboardingu). Správne, pre väčšinu služieb toto postačuje, no nie pre všetky (a to platí eventuálne aj pre niektoré citilivé scenáre v komerčnom svete), na to máme inú schému/prostriedky s “Vysokou” mierou záruk.
Čo sa týka autorizácie kliknutím, ak je toto preferencia namiesto všeobecne uznávaných konceptov eIDAS pre autorizáciu úkonov fyzických osôb, potom tomu asi nikto nezabráni - autentifikácia bude na úrovni minimálne pokročilá a za predpokladu, že sa “klik” správne implementuje na prístupovom mieste ako jeho funkcia (resp. v súlade so zákonom). Len som podotkol, že je toto národné špecifikum.
1 Like
Tento naklad je niekde v CBA projektu zapocitany?
“Paci sa mi” ako sa z postupov MIRRI stal trhaci kalendar. Projekt este sice nie je formalne schvaleny clenmi riadiaceho vyboru OP II ale my uz vieme ze bude kedze uzatvorime inde dodatok na to aby sa mohol projekt realizovat.
3 Likes
slovensko-v-mobile-pripomienky-slovensko-digital_odpovede.xlsx (16.4 KB)
Tak nas vybavili a karavana ide dalej.
NIekto cakal nieco ine? Ved rozhodli ked zalozili firmu, sotatne su len “tanecky”. Inak paci sa mi zopar odpovedi, napr. vraj lekari pozaduju ePN, urcite oni su/budu najvacsia brzda/prekazka zavedenia systemu ePN, papier vypisu rychlejsie ako ked budu robit so systemom, ich bude potrebne motivovat a nie oni budu pozadovat a tlacit na zavedenie, neviem odkial to zobralibbb)
2 Likes
-
“Hlavným kritériom musí byť použiteľnosť a komfort pre používateľa, ktorého technológia nezaujíma a potrebuje aktivity vykonať intuitívne.”
-
89/92 (tam si myslim, ze by pri vyvoji mobilnych apps mali byt defaultne pouzite zakladne dizajnove a funkcne principy a komponenty Google Material Design Guidelines a Apple Human Interface Guidelines, zbytocne nanovo vymyslat koleso a uzivatelia budu aspon v tych aplikaciach “ako doma”)
Tak si si zatlieskal, ale vidis tam odpoved na moju otazku? Lebo ja nie.
82 Ja podla mna uplny skandal. Cize podpiseme x milionov na vyvoj kompletneho projektu na zelenej luke lebo… nemame kapacity na posudenie, ze ci by sa dalo nieco hotove pouzit. Tomuto tlieskas?
92 Vie mi vysvetlit niekto kde najdem odpoved na moju otazku?
Ja vidím.
Podla mna velmi prudentne. Rozpravali sme sa s nimi viackrat, vysvetlenie mi pripadalo dostatocne. Ak tebe nie, uznavam a akceptujem.
Tiez nevidim priamu odpoved, ale zaver ktory nacrtli mi pripada v poriadku. Stavajuci dizajn manual vobec neberu do uvahy UX nativnych aplikacii. Predpokladam, ze posudili viabilitu PWA a odhodili to ako tragicke, s cim suhlasim.
Otazka ci bol channel-fit vykonany. Bol ci nebol? Cakam ano/nie.
S kym si sa rozpraval? Ci to si myslel MIRRI? Rad by som ti dal do pozornosti to, ze na stole maju riesenie rok, vlada predtym 2 roky. Cize teraz idu robit analyzu? A na tu analyzu potrebuju schvaleny projekt za x mega?
Pytal som sa na alternativy, ktore posudzovali - nevymenovali ani jednu. Z toho sudim, ze ziadne neposudzovali. V skutocnosti “novy princip”, ktory v odpovedi popisuju sa vola “proaktivnost” a je v NKIVS dokumentoch uz vyse 10 rokov. Namatkovo NKIVS 2008.
Cakal som, ze aspon normalne odpovedaju, ale nie toto je zjavne, ze to treba rychlo zbuchat, aby sa peniaze dostali do SKIT a mohli zacat pracovat.
2 Likes
Jedine ak mas iOS, ktory sice podporuje PWA, ale nie v plnej miere (pridanie na homescreen, notifikacie, atd).
Ake je riesenie? Bude sa vyvijat pre android a ios native aplikacia? Vyuzije sa nieco ako native script alebo WebView/Ionic/Cordova? Ake su naklady (vyvoj a prevadzka) na taketo riesenia v porovnani s responzivnou app (nemusi byt ani PWA)?
Dúfam a verím tomu
Vyzera to tak, ze rozhodnutie o tom, ze to bude nativna appka padlo davno predtym, ako sa zacala nejaka CBA alebo alternativy pisat. Ale poviem to, co opakujem stale. Nemam ziadny problem s nativnou appkou, pokial pojdeme normalne podla schvalenych postupov MIRRI (!!!) a ukaze sa, ze na to nativnu appku potrebujeme. Podla mna na push, autentifikaciu a nejake doklady v mobile to proste potrebujeme urobit nativne.
Potrebujem pocut, ale nejake normalne argumenty a nie vyhlasenia typu “ludia travia 90% casu v nativnych aplikaciach a preto ideme robit nativne aplikacie”. Keby si niekto dal tu pracu a precital aspon strategicku prioritu multikanalovy pristup, tak tam presne taketo nieco najde a aj vysvetlenie preco sa NAPRIEK TOMU vybrala “no apps strategy”. A keby sa niekto spytal na skupine, tak by aj vedel, ze no-apps strategy neznamena, ze sa nemoze robit nativna aplikacia. Ta pointa je uplne inde.
Mam povolenie tu zverejnit list, co bol poslany na SKIT.
List-na-P.-Mirossay-a-priloha.pdf (526.5 KB)
1 Like