Source: https://platforma.slovensko.digital/t/open-api-standardy/4376?page=5
Timestamp: 2018-12-17 04:37:04+00:00

Document:
peter_k 2017-11-20 14:05:57 UTC #82
msurek:
Ja osobne vidim najvacsi problem momentalne v tom ze projekt, ktory to ma systematicky riesit je naplanovany 2022? Akoze dovtedy sa to tu bude nejako bastlit s tym co mame? Ja fakt nerozumiem ze preco projekty, ktore v principe s nikym nekoliduju a mozeme ich povazovat ako centralne bloky na ktore sa maju ostatny integrovat nejdu v prvej vlne ale az nakonci
…presne z tohto dovodu sa pytam, lebo realne na urovni projektov by sa dali take veci robit uz aj teraz…a aj sa robit budu, nikto nebude cakat do 2022 alebo cca dalsi rok, kym sa zadefinuje standard…hrozi riziko, ze sa nakoniec realne implementacie netrafia do standardu a potom v 2022 bude treba opat prerabat alebo v 2022 sa nic robit nebude a necha sa stav, ktory vtedy bude…
kyselat 2017-11-20 14:18:43 UTC #83
Myslím si, že to len nie správne interpretuješ. Ako už bolo uvedené aj v tomto vlákne v príspevku vyššie (Open API štandardy), systematické riešenie (urobiť si jasno a mať špecifikáciu) je možné mať okamžite. Akčný plán v kapitole 7 k tomu jasne smeruje. A potrebujeme mať okamžite aj centrálnu infraštruktúru pod systematickým riešením? To zrejme nie.
kyselat 2017-11-20 14:22:19 UTC #84
…presne z tohto dovodu sa pytam, lebo realne na urovni projektov by sa dali take veci robit uz aj teraz…a aj sa robit budu, nikto nebude cakat do 2022 alebo cca dalsi rok, kym sa zadefinuje standard…
Rovnako viď Open API štandardy a Akčný plán kapitola 7. Nikto predsa nehovorí, že má byť štandard zadefinovaný až 2022. Kde presne je to takto napísané?
msurek 2017-11-20 14:56:55 UTC #85
A potrebujeme mať okamžite aj centrálnu infraštruktúru pod systematickým riešením? To zrejme nie.
Asi je to len uhol pohladu, ale musis uznat ze ked vsetci vieme ze smerujeme k takemu komponentu a nakonci dna ho chceme (a MyData uz mohol na nom aj fungovat), tak aky je dovod potom tento projekt oddalovat a cakat nanho 5 rokov a dovtedy vymyslat riesenia ako by to mohlo fungovat aj bez neho?
Koncepcne by to mala zastresovat jedna autorita, aby nebolo N roznych endpointov. Takym sposobom vies potom tieto autority pisat aj do legislativy a nie len standardu a tym zvysovat vynutitelnost. Mne to v principe pride len zbytocne. Nepovedal by som ak by na UPVII momentalne bezalo 20 projektov a dalsie projekty by sa nestihali, ale v stave ked sa vlastne este nic nerozbehlo mi to pride ako premarneny cas, lebo toto urcite nie je tema, ktora by bola blokovana verejnostou ako neopodstatnena.
peter_k 2017-11-20 16:22:43 UTC #86
Nikto predsa nehovorí, že má byť štandard zadefinovaný až 2022. Kde presne je to takto napísané?
A kde som ja napisal, ze ma byt standard 2022?
@msurek uviedol, ze centralny komponent ako projekt je planovany 2022…ja som mu iba reagoval, ze potreba je teraz a ze nikto nebude cakat na 2022 a ani dalsi rok na zadefinovnie standardu…precital som kapitolu 7. Akcneho planu a pise sa tam toto:
“Základným predpokladom teda je vydanie metodiky a pravidiel štandardizovaného publikovania
rozhraní, ktoré budú kvalitatívne popísané tak, ako je v prostredí OpenAPI bežné – ÚPPVII do
12/2017.”
…cize na konci decembra 2017 bude definovany standard, ak tomu spravne citam ten Akcny plan…ano sekol som sa, uznavam…
Lubor 2017-12-01 22:48:40 UTC #87
Dnes končí MPK na vyhlášku o AC. Zdá sa že vyhláška zaujala viaceré orgány, je podaných viac ako 50 pripomienok. Najvážnejšie sú od Úradu jadrového dozoru , MV a NBÚ.
Za S.D som podal tieto (ako som písal vyššie):
§1, ods.3, písm.f), g) a h):
Navrhujeme písm. f), g) a h) odstrániť.
Nie je dostatočne špecifikované, čo je “informácia o rozsahu oprávnení”. Súčasne považujeme túto informáciu za zbytočné uvádzať v žiadosti o zápis autentifikačného certifikátu do registra, keďže táto informácia sa neviaže na autentifikačný certifikát, počas jeho používania sa môže meniť a nie je rozhodujúca pre zápis certifikátu do registra.
§2, ods.2:
Navrhujeme ods.2 odstrániť, alebo nahradiť nasledovným znením: Dátum konca platnosti certifikátu podľa ods.1 písm.c) môže byť najviac 20 rokov odo dňa podania žiadosti.
Nie je potrebné konkretizovať kto “vydáva certifikát”. Zároveň platnosť certifikátu v zmysle jeho možnosti použitia podľa zákona č.305/2013 sa riadi tým, či certifikát je zapísaný v registri a nie tým “ako bol vydaný”. Zo zákona nikde nevyplýva, že po uplynutí doby uvedenej v položke certifikátu “valid-to” by autentifikačný certifikát mal byť automaticky z registra odstránený, alebo že ho v tomto prípade má/môže Nases z registra odstrániť. Naopak, v odôvodnenom prípade (napr. podozrenie na prelomenie bezpečnostných algoritmov v certifikáte použitých) bude certifikát z registra odstránený bez ohľadu na túto jeho položku. Z tohto dôvodu považujeme za irelevantné sústrediť sa na túto položku certifikátu, a teda aj ods.2 odstrániť.
Ak z nejakých dôvodov považuje Nases za nevyhnutné špecifikovať maximálnu dĺžku “životnosti” certifikátu, a existuje legislatívne zdôvodnenie na takéto obmedzenie a jeho vykonanie zo strany Nases, považujeme limit 2 roky za zásadne nedostatočný a v praxi by prinášal iba problémy. Navrhujeme stanovenie tejto doby na 20 rokov, alebo viac.
Navrhujeme §3 odstrániť.
Zákon č.305/2013, konkrétne §59 ods.2 písm.f), nedáva zmocnenie upraviť vydávanie zoznamu platných autentifikačných certifikátov vyhláškou. Zároveň nie je jasné, aký účel sleduje navrhnuté znenie §3. V súlade s aktuálnym rozpracovaním témy OpenAPI (viď. schválené dokumenty Strategických priorít NKIVS) skôr považujeme za potrebné sústrediť úsilie na správnu implementáciu tohto konceptu, v rámci ktorej nie je pre OVM potrebné pri prístupe k API žiadnym spôsobom pracovať s autentifikačným certifikátom, ale majú interpretovať STS token vydaný IAM ÚPVS.
Navrhujeme stanoviť dátum účinnosti vyhlášky na 1.2.2018, alebo neskôr.
Vzhľadom na dátum konca platnosti MPK bude vyhlášku možné vydať až počas decembra 2017. S jej vydaním súvisia zmeny v už realizovaných integráciách používajúcich autentifikačný certifikát, a je potrebné nechať dostatočný čas na ich vykonanie. Súčasne v tomto období sú vianočné a koncoročné sviatky.
Príloha, ods.1 písm.a):
Navrhujeme nahradiť nasledovným znením: "dĺžka kľúča je minimálne 4096 bitov"
Dostatočná dĺžka kľúča je vhodná aj v súvislosti s potrebným dlhodobým používaním certifikátu, viď. aj pripomienka k §2 ods.2.
jsuchal 2017-12-06 09:52:57 UTC #88
@msurek nasiel taketo
databusiness.fi
20171116_APIrecommendations_WEB.pdf
1177.81 KB
Lubor 2018-01-12 22:43:16 UTC #89
Takže v práve končiacom MPK výnosu o štandardoch je celý nový §47a pre OpenAPI. Áno, ani ja som to predtým nevidel. Dal som k tomu aspoň zopár pripomienok.
jsuchal 2018-01-29 12:06:50 UTC #90
Identifying the challenges of designing cross-government APIs - Technology at...
peter_k 2018-02-08 12:30:53 UTC #91
hanecak 2018-02-12 10:02:56 UTC #92
peter_k 2018-02-12 11:23:15 UTC #93
peter_k 2018-02-12 11:53:10 UTC #94
jsuchal 2018-02-12 11:59:51 UTC #95
miso 2018-02-12 12:24:54 UTC #96
peter_k 2018-02-13 16:04:42 UTC #97
jsuchal 2018-02-13 17:11:17 UTC #98
jsuchal 2018-02-13 18:17:54 UTC #99
peter_k 2018-02-14 07:40:45 UTC #100
jsuchal 2018-02-14 08:09:50 UTC #101

References: §1

§2
 §3
 §59
 §3
 §2
 §47