…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…
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 - #60 by kyselat), 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.
Rovnako viď Open API štandardy - #60 by kyselat a Akčný plán kapitola 7. Nikto predsa nehovorí, že má byť štandard zadefinovaný až 2022. Kde presne je to takto napísané?
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.
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…
1 Like
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ť.
Odôvodnenie:
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.
Odôvodnenie:
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.
§3:
Navrhujeme §3 odstrániť.
Odôvodnenie:
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.
§4:
Navrhujeme stanoviť dátum účinnosti vyhlášky na 1.2.2018, alebo neskôr.
Odôvodnenie:
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"
Odôvodnenie:
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.
1 Like
@msurek nasiel taketo
3 Likes
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.
V UK zacinaju riesit jednotny pristup k API, niekto stavka, kto to stihne skor? cc @ret 
1 Like
najaktualnejsie info, bod, do ktoreho sa dostalo definovanie standardov pre Otvorene API je stale na tomto linku https://wiki.finance.gov.sk/display/PS1/OpenAPI ???
dik
IMHO najcerstvejsie je toto: “§ 47a Verejne dostupné aplikačné rozhrania” v
https://www.slov-lex.sk/legislativne-procesy?p_p_id=processDetail_WAR_portletsel&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-2&p_p_col_count=1&_processDetail_WAR_portletsel_fileCooaddr=COO.2145.1000.3.2426070&_processDetail_WAR_portletsel_file=1.-Vlastny_material.DOCX&_processDetail_WAR_portletsel_action=getFile .
Nuz a kedze je ta Sl.ovk-LEx linka “cudna/pridlha” tak ako som sa k nej dostal:
- Výnos o štandardoch - MPK
- https://www.slov-lex.sk/legislativne-procesy/SK/LP/2017/951
- “sprievodna dokumentacia”: https://www.slov-lex.sk/legislativne-procesy/-/SK/dokumenty/LP-2017-951
- “1.-Vlastny_material.DOCX”
…cize este stale v meta rovine…
…v “navrhu” standardov sa pise a predpoklada sa existencia komponentu, kde sa budu udalovat pristupy a prava subjektom k jednotlivym otvorenym API…citujem: “Prístup ku každej OpenAPI službe je riadený prostredníctvom centrálnej autority identít bez nutnosti komunikácie s poskytovateľom OpenAPI služby” a “Rozhranie pre povolenie prístupu k OpenAPI službe treťostrannému subjektu” z linky https://wiki.finance.gov.sk/display/PS1/OpenAPI
UPPVII_SP_Integracia_orchestracia_vFinal.pdf (2.6 MB) tento dokument na strane 43 popisuje urcitu architekturu a jej bloky…v ktorom z tych farebnych ramcekov bude umiestneny komponent pre riadenie pristupov tretich stran k otvorenym API?
Ktora existujuca studia/teda projekt to realne bude riesit?
Aka je zavislost tych jednotlivych farabnych ramcekov navzajom a konkretne v pripade poskytovania pristupu a vyuzivania otvorenych API?
Ma v tom niekto prehlad a vie dat taky big picture pohlad a vysvetlenie?
Co sa tyka pristupu tretich stran k datam (neviem ci aj api), tak to ma v plane studia projektu Red Flags: Zvyšovanie úžitkovej hodnoty digitálnych služieb pre občanov, podnikateľov a inštitúcie verejnej správy ale videl som to aj v studii UPVII moje data.
Uz sa tesim ako nam tu vzniknu paralelne implementacie toho isteho v roznych projektoch, alebo ciastkove implementacie, ktore uz dokopy pouzitelne nebudu.
Vlastne, netesim som chcel povedat.
1 Like
Niekto to nakreslil, tak ten by mal asi vediet ake su zavislosti a co do ktoreho ramceka patri.
Architektonicka kancelaria ze by?
Tak pridávam ešte aj projekt MV, ktorý chce riešiť oprávnenia tretím stranám ako služba. Toto sú už teda fakt haluze.
2 Likes
Tak je to vonku.
https://www.gov.uk/guidance/gds-api-technical-and-data-standards
- Oauth alebo openid connect (pre tretie strany). (zmurk @ret)
- REST+JSON, pripadne JSON-LD (zmurk @msurek, @liska)
- OpenAPI specifikacia (zmurk @kyselat)
- rate limiting (zmurk NASES)
Dobre sme trafili.
4 Likes
kolko im to trvalo?
mna zaujalo toto https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice jasny dokument, s jasnym cielom a citatel vie, co sa ocakava
1 Like
Neviem, viem ze mali jedno stretnutie a potom to o dva tri tyzdne zverejnili.