Open API štandardy

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 :open_mouth: , 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 :smiley:

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:

  1. Výnos o štandardoch - MPK
  2. https://www.slov-lex.sk/legislativne-procesy/SK/LP/2017/951
  3. “sprievodna dokumentacia”: https://www.slov-lex.sk/legislativne-procesy/-/SK/dokumenty/LP-2017-951
  4. “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.

V zasade “bez ohladu na to co je v (buducom) Vynose” je cielom (mojim, nasim, komunitnym :slight_smile:) to, co medzicasom vyrazne lepsie (nez ja, my, oni) sformulovalo GDS:

Ak bude KS ISVS este nejako fungovat (hint: Komisia pre štandardy ISVS - #19 by hanecak), tak sa urcite budem snazit zosuladit nas (buduci) Vynos s tym, co je v UK standarde.

1 Like

Mne sa na tom UK gov standarde paci dlzka. Preco u nas vzdy musia vznikat 100+ stranove dokumenty :roll_eyes:

Tak toto este standard asi neni, ale podla mna to rozumnemu cloveku staci. Nejaky komunitny destilat a checklist z NKVS a strategickych priorit ma zmysel robit? :smiley:

Podla mna ma zmysel z toho spravit checklist, lebo ved zvycajne je tam tolko balastu, az sa to cloveku nechce citat (teraz strielam, ale kto by cital 10 dokumentov po 100 stran…)

Uz dlhsie sa pohravam s touto myslienkou, ale potom sa vzdy zamyslim, ze kto by bol vlastne cielovka a ci by to vlastne bral vazne. A tam si nie som uplne isty.