Este 1 fakticky dovod. Spomina sa to tam len v situacii ked sa dva subjekty dohodnu !
Ale 2 subjekty sa mozu dohodnut aj na cinskych znakoch, alebo NAVAJO kode … Ked sa 2 subjekty dohodnu, nech si robia co chcu - ALE NIE JE TO STANDARD. Neviem preco vo vynose o standardoch spominame nieco na com sa mozu 2 subjekty dohodnut. …
Ze som taky smely … nieco sa udialo ?
Prave prisla pozvanka na PS1 na 11.6 od 13 do 15. Co sa dialo na PS2 netusim. Na PS1 planujem ist.
Len do toho, ale teda v spravnom chlieviku: Komisia pre štandardy ISVS - PS2 - Bezpečnostné štandardy - #22 by Lubor 
PS1 veci pribudnu neskor tu.
Dnes prebehlo zasadnutie PS1. Hlavny dovodom znovu nastartovania standardizacnych skupin je potreba transformovat vynos 55/2014 pravdepodobne na vyhlasku, kvoli novemu zakonu o ITK. UPVII chce do tohto noveho vynosu zapracovat co najviac novych veci,ktore sa udiali od poslednej aktualizacie aby uz nove projekty nabiehali podla novych standardov.
Casovy predpoklad je ze diskutovane temy budu v rozpracovanom stave vo forme navrhov zaslane aj emailom clenom, kde bude priestor na pripomienkovanie. Ocakava sa ze nasledne bude spustene distancne hlasovanie.
Tem ktore boli preberane bolo velke mnozstvo a preto poviem len o novych zaujimavych temach :
-
pomenovanie data.gov.sk ako centralny repozitar zdrojovych kodov (vzhladom na pripravovany projekt OpenData 2.0). Okrem toho budu specifikovane aj pravidla pouzivania tj. kto vsetko bude povinny tam kody davat, aka bude urovne spristupnenia (project private, “OVM-only”, public). Detailne znenie bude na zaklade diskusie zaslane.
-
zavedenie povinnosti aktualizacie metadat datasetov, aby neboli “mrtve” datasety ale aby bol tlak ich periodicky aktualizovat a starat sa o ne
Ked budu jasne znenie vsetkych bodov (bude ich naozaj dost a z roznych oblasti) tak ich sem pridam.
toto sa tiez preberalo, co som navrhoval o par prispevkov vyssie ?
Pravda je taka ze sa tam nestihli uplne prejst ani vsetky historicke rozrobene veci preto sa to tam explicitne nespominalo. Ako som hovoril, ta agenda bola velmi velka a preto sa nestihlo o mnohych veciach ist do hlbky a dohodlo sa ze pride rozpracovany navrh s N navrhmi pre rozne oblasti. Poslem to sem a ak to tam nebude tak dame pripomienku.
Prepáč @robert.kuchar, až teraz som to tu našiel. Ja som zo štandardizačných skupín členom iba PS2 - Bezpečnostné štandardy, tam toto fakt nepatrí.
Ináč s Tebou v tomto súhlasím. SR si síce môže určiť vlastné formáty nad rámec eIDAS, ale z.305/2013 jasne hovorí že akceptovateľný je iba KEP podľa eIDAS. Čiže bez ohľadu na to čo sa píše v nejakom výnose o štandardoch, ak ZEPf nie je súladný s nariadením, nesmie byť akceptovaný.
cize formulacie ostali a najblizisa sanca na zmenu je v nedohladne ?
V rámci jedného súdneho sporu riešim riadne doručovanie EUD v súvislosti s vyzadovanymi standardami týchto EUD (ide zjednodušene o to, či je možné považovať doručenie úradného dokumentu v nesúladnom formáte podpisu a kontajneru za riadne doručený EUD). Zatiaľ sa 1 a 2 stupeň k tomu vôbec nevyjadril a posunuli “čierneho Petra” na NSSR (budem podávať dovolanie).
Toto ma celkom zaujíma, keď budeš vedieť niečo nové daj tu niekde prosím vedieť.
1 Like
Dobrý deň, táto téma patrí do pracovnej skupiny PS4, ktorá sa zaoberá technickými štandardmi a aj štandardmi elektronických dokumentov podpisovaných el. podpisom alebo pečaťou. PS1 sa zaoberá hlavne dátovými štandardmi, centrálnym modelom údajov, referencovateľnými identifikátormi a podobne.
Formát ZEPf je vo Výnose v §57b predpísaný ako formát, ktorý je povinnosť prijímať výlučne prostredníctvom centrálnej elektronickej podateľne a ak takýto podpis spoliehajúca sa strana akceptuje. Nemôže ho verejná správa vytvárať (viď §57c), kým sa všetky strany príslušnej komunikácie nedohodnú, s vedomím možných škôd a nezrovnalostí v ďalšom konaní vyplývajúcich z takého postupu. Je možné návrh prerokovať na PS4 ale táto textácia bola konzultovaná s NBU a súhlasili s ňou. Citujem z Výnosu §57b:.
Štandardom pre prijímanie a čítanie podpisových kontajnerov je prijímanie a čítanie
c) modulom centrálnej elektronickej podateľne externe podpísaných elektronických dokumentov alebo v ZEPf transportnom kontajneri obsahujúcom podpísaný dokument a jeho podpis CMS AdES alebo XML AdES podľa zverejnenej technickej špecifikácie11ec), pričom modul centrálnej elektronickej podateľne zabezpečuje aj overenie elektronického podpisu vyhotoveného podľa pravidiel platných do 30. júna 2016, ak takýto podpis strana spoliehajúca sa na podpis akceptuje; na overenie podpisov sa obsah transportného kontajnera ZEPf alebo samostatné podpisy a nimi podpísané dokumenty môžu uložiť do formátu ASiC, podľa písmena a),
No ja som nikdy nepovedal ze to je nespravne napisane, alebo nesuladne so zakonom.
Problem je, ze je to pre normalneho cloveka nezrozumitelne = tazko pouzitelne.
Na jednej strane sa tu legalizuje (za urcitych podmienok) pozuivanie ZEPf, na druhej strane sa ZEPf neda overit na pritomnost KVALIFIKOVANEHO podpisu. Podla NBU ak by sa prebalil vramci Zar. Konv. zo ZEPf do ASiC tak by to overovat islo, lebo binarne je ten podpis v poridku len je zabaleny do nesuladnej obalky. A kvalifikovany podpis je zase pri EUD jedina forma uznanej Autorizacie.
Cize suma sumarum viem v ZEPf vyrobit NEAUTORIZOVANE dokumenty, ktore po dohode dvoch stran mozu byt akceptovane. Len ci si niekto na tej druhej strane uvedomil ze dostal NEAUTORIZAVNY dokument. Lebo sice sa format akceptoval (dokument sa prijal0, ale v nom sa nenachadza platna autorizacia (305/2013, par.23, odsek 1). …
Preto nerozumiem NACO je vo vynose O STANDARDOCH potrebne uvadzat nejaky NESTANDARD, ktorý platí len za okolností ak dvaja podpisu nejaku zmluvu a plati len pre tych dvoch. To tam mozme uvadzat vsetky nestandardy, na ktorych sa dvaja dohodnu…
Sposobi to iba chaos.
Prebieha hlasovanie o zmenach vo vynose o standardoch. Za najvacsi uspech povazujem repozitar zdrojovych kodov tj. by default su zdrojove kody verejne a budu zverejnene na jednom mieste.
finálna verzia návrhov na schvaľovanie pre PS.docx (47.7 KB)
1 Like
Neviem ci to patri do tohto vynosu, ale bolo by fajn, ak by sa IT riesenia a zakazky s tym spojene neriesili formou “spravime vsetko v JAVA ale pre Win prosim nativne cez .NET”, pretoze to potom vytvara zbytocne separovane aplikacie a riesi sa vzdy primarne a sekundarne debugovanie. Nech maju vsetci rovnake podmienky, tz. bud vsetci multiplatformove, alebo vsetci nativne pre tu ktoru platformu.
Neviem ci dobre rozumiem navrhu.
Treba brat do uvahy rozne prostredia a stav danych rieseni ktore sa obstaravaju. To moze vytvorit logicku poziadavku vsetkych kombinacii.
Su situacie ked nema vyznam pozadovat nativne riesenie a naopak.
Poziadavka debugu je asi niekde viac vzadu za poziadavkami celkovej architektury a je viac dev ops zalezitost. Nastavit striktne pravidla by podla mojho nazoru mohlo skomplikovat situaciu.
Ok, skusim príkladom. Pred nejakým časom som sa dostal k zmluvnej dokumentácii obstaravania, kde sa riešilo mobilne eID. Rozpočet bol dajme tomu 200.000,- EUR. Za cca 25.000 sa obstaralo multiplatformove riešenie (Win/macOS/linux) a zároveň za 175.000 sa obstaralo .NET Win riešenie. Moj navrh by smeroval k tomu, aby sa riešilo buď obstarávanie multiplatformového riešenia, alebo natívne pre každú platformu zvlášť.
A nebolo to tak, ze klient mID je multi a server .net?
1 Like