eKasa: pridať využitie aj pre občanov

Jasne. Lenze aj toto sa da robit uplne formalne alebo konstruktivne. Taky finstat by mohol napisat knihu o tom, ako sa sprava urad, ze @Ivet_Fercikova?

zdravim, maly update…v tejto teme sme v komunikacii s FS SR…FS SR oslovilo Urad na ochranu osobnych udajov a hladaju systematove riesenie…myslim si, ze to je na dobrej ceste

2 Likes

@peter_k , mas nejaky update k tomuto?

Tiez by ma zaujimalo, ci sa s “oficialitou” nejak pohlo. Osobne udaje tam nie su?

1 Like

ide to pomaly

FS SR oslovila UOOU o stanovisko…FS SR ide menit legislativu k tomu…cez 211tku sme si vypytali to stanovisko, lebo si nemyslime, ze zmena legislativy je koncepcne riesenie pre kazde otvorenie API
List č. 00190-2021-Op-4 zo dňa 25.5.2021 (1).pdf (651.3 KB)
Odpoveď Finančného riaditeľstva SR - 7.7.2021 (1).pdf (223.9 KB)

Ja si k tomu listu ÚOOÚ konkrétne myslím toto (aj som to dal FS vedieť):

  1. ÚOOÚ konštatuje, že služba “online overovanie pokladničných dokladov tretími stranami” je v súčasnosti prevádzkovaným spôsobom zákonom povolená.

  2. Konštatovanie ÚOOÚ, že sa rozšírením služby “mení zdroj údajov” je evidentne nedorozumenie, keďže už v súčasnej dobe je služba poskytovaná v GUI forme, kde zdrojom údajov pre jej používateľov je FSSR, o čom ÚOOÚ konštatuje že je zákonom povolené, pri API forme to bude rovnako.

  3. ÚOOÚ správne konštatuje, že dôjde k zmene formy poskytovania služby z GUI na API. Tento rozdiel však nemôže znamenať rozdielnu úroveň ochrany práv FO, ako priamo určuje rec.15 GDPR: “…by mala byť ochrana fyzických osôb technologicky neutrálna a nemala by závisieť od použitých technologických riešení…”. Jediný rozdiel doterajšieho “iba GUI” a zamýšľaného “GUI aj API” prístupu je potenciál automatizovaného spracovania u používateľov služby, ktorý sa zavedením API formy zvyšuje. FSSR už v súčasnosti všetky údaje pre túto službu spracúva automatizovane aj pri GUI forme.

  4. Z bodu 2 vyplýva, že parametre služby uvedené vo všeobecne platných právnych predpisoch (najmä zákon), musia byť rovnaké, bez ohľadu na formu spracovania. Ak sú tieto pravidlá v súčasnosti dostatočné, nevyhnutne ich treba vztiahnuť aj na API formu a doriešiť je potrebné “potenciálne automatizované spracovanie”. Naopak, ak by súčasné pravidlá neboli dostatočné pre API formu (okrem automatizovaného spracovania), nemohlo by FS poskytovať v súčasnosti ani GUI formu - čo však nie je pravda, špecificky ÚOOÚ potvrdzuje, že súčasné spracovanie je v poriadku.

  5. Špecificky bez ohľadu na GUI/API formu zostávajú rovnaké: právny základ, oprávnený prevádzkovatelia, rozsah spracúvaných údajov, povolené spracovateľské operácie, informačná povinnosť, práva DO.

  6. FSSR, aj používatelia služby, by mali v dokumentácii súladu služby s GDPR (bez ohľadu na formu) konkretizovať veci podľa bodu 5. (A verím že už to majú spravené.)

  7. V súvislosti s potenciálnym automatizovaným spracovaním osobných údajov využitím služby v API forme je potrebné u používateľov služby podľa GDPR riešiť: rec.67: a) zabrániť iným ako povoleným spracovateľským operáciám, b) zabrániť zmene údajov, c) označiť, že spracúvanie údajov je obmedzené, rec.71 a čl.22: d) profilovanie dotknutej osoby, e) rozhodnutia založené výlučne na automatizovanom spracúvaní údajov, čl.20: f) ak pokladničné bloky obsahujú osobné údaje získané na základe súhlasu DO právo na prenos údajov, čl.35.3.a GDPR: g) riešiť automatizované spracovanie v posúdení vplyvu.

  8. Za realizáciu týchto povinností nezodpovedá FSSR, ale používateľ služby, FSSR im však vie napomôcť vhodnými technickými a organizačnými opatreniami.

  9. Na podporu výkonu požiadaviek podľa bodu 7 by FSSR malo v podmienkach používania služby určiť pre používateľa aj: zákaz vykonávať iné ako povolené spracovateľské operácie, označenie osobných údajov, zákaz profilovania FO na základe využitia služby, zákaz vytvárať rozhodnutia založené výlučne na automatizovanom spracúvaní údajov služby, upozorniť na práva na prenosu údajov v prípade ak obsahujú údaje získané na základe súhlasu DO, upozorniť na povinnosť riešiť súlad spracúvania údajov s GDPR, vrátane posúdenia vplyvu.

  10. Na podporu výkonu požiadaviek podľa bodu 7 a) a b) prijme FSSR vhodné technické bezpečnostné opatrenia, ktoré neumožnia zmeniť (a zmazať) údaje a vykonávať iné ako povolené funkcie prostredníctvom tejto služby.

  11. Ďalej ÚOOÚ žiada, aby realizácia služby bola v súlade s čl.5 ods.1 písm.c) GDPR (minimalizácia spracúvaných údajov) a čl.25 GDPR (špecificky navrhnutá ochrana). Táto požiadavka sa vzťahuje na službu bez ohľadu na GUI/API formu v akej je poskytovaná.

  12. Požiadavku podľa bodu 5 FSSR nevyhnutne zabezpečí a) analýzou bezpečnosti služby, b) návrhom bezpečnostných parametrov služby s cieľoch chrániť dôvernosť a integritu údajov, c) analyzovaním prípadov použitia služby so zreteľom na minimálny nevyhnutný prístup k osobným údajom zo strany používateľov, d) návrh API podľa bodu c) - tieto veci sa ani nedajú “napísať do zákona”, musia sa riešiť organizačnými a technickými opatreniami FSSR, ako je aj v čl.25 GDPR priamo uvedené.

  13. Do analýzy prípadov použitia FSSR špecificky zahrnie aj funkciu “iba overenie pravosti pokladničného bloku”, kde požiadavkou je, aby informáciou získaná pomocou služby, že pokladničný blok je platný, neboli sprístupňované iné údaje.

Po dôkladnom preštudovaní listu ÚOOÚ je evidentné, že vo vyššie uvedených bodoch 1-13 sú riešené všetky ich požiadavky (a aj ďalšie nad rámec ich listu). Na ich splnenie je nutná kombinácia organizačných a technických opatrení na strane FSSR a používateľov služby (v nich uvedených).

Naopak, nikde nie je indikovaná potreba úpravy súčasných všeobecne platných právnych predpisov - za predpokladu, že dnes existujúca služba poskytovaná forme GUI je poskytovaná legálne, čo však potvrdzuje aj samotné ÚOOÚ.

Stručne povedané: zmena zákona nič nové neprinesie - bude iba duplikovať už existujúce práva a povinnosti, a ničomu nepomôže - uvádzané iné opatrenia bude treba spraviť rovnako.

Ja osobne v tejto situácii “prípravu novely” vnímam ako neúčelné vynakladanie prostriedkov verejnej správy.

1 Like

Tak túto otázku by sme mali vybavenú.

1 Like

Ako si to myslel ?

Ja som bol dodnes v tom, ze predavajuci ( napr. obchodny retazec ) nevie moje osobne udaje (ak mu ich dobrobolne neprezradim cez zlavovu karticku/aplikaciu ). Maximalne tak vie cislo platobnej karty, ale pri plateni v hotovosti nevie ani to. Ustavny sud teraz zatrhol statu (FS) moznost vyzadovat/odkladat si informacie o kupujucom a to aj v pripade, ze ich predavajuci pozna/posiela ich ako sucast blocku.

Tu poziadavku vyzsie som chapal v zmysle “umoznit obcanovi automatizovat stiahnutie obsahu blocku ak pozna jednoznacne ID-cko toho blocku”. Teraz take (asi) API existuje, ale z dovodu nastavenia bezpecnostnych obmedzeni (rate-limit), ho nie je mozne rozumne automatizovat. Mylim sa ?

Narazam na to, ze US rozhodoval aj o casti, ze tam nesmu byt udaje o polozkach nakupu. To zamietol.

Priklad pouzita rozhrania pre pripad OFF-LINE dokladu:

  • pouziva sa v pripade, ked registracna pokladnica v case vytvorenia blocku nemala online pristup na eKasu a vytlacila blocek s QR kodom , ktory neobsahuje idDokladu.

Vtedy qr kod obsahuje tieto informacie:

<Overovací kód podnikateľa (OKP)>:<Kód pokladnice>:<Dátum a čas vyhotovenia>:<Poradové číslo dokladu>:<Celková suma>

Toto odpoveda fieldom formulara v aplikacii over doklad:

Kompletne informacie o doklade sa ziskaju odoslanim POST request-u na:

URI: https://ekasa.financnasprava.sk/mdu/api/v1/opd/receipt/find

JSON Body:
{
“okp”: “<Overovací kód podnikateľa (OKP)>”,
“cashRegisterCode”: “<Kód pokladnice>”,
“issueDateFormatted”: “<Dátum a čas vyhotovenia>”, // format: 19.09.2021 10:19:28
“receiptNumber”: <Poradové číslo dokladu>,
“totalAmount”: <Celková suma>
}

1 Like

v ramci SD sa snazime uz od zaciatku eKasy umoznit aj jej sw podobu

MF SR planuje otvorit zakon a nad touto alternativou uvazuje

na druhej strane ako sme my, su tradicni vyrobcovia pokladnic

stvrtok ma byt k tomut zakonu a teme stretnutie…vstup do stretnutia su postrehy/navrhy vyrovbcov pokladnic
Ďalšie predložené podnety a pripomienky k súčasnému zákonu č.docx (35.4 KB)

Nechapem co tam riesia GDPR, ked sa paragon tlaci cez VRP, zadava sa len suma a cislo faktury. Na zaciatok by toto uplne stacilo. Uz by mal niekto odstavit to evidentne priame prepojenie na vyrobcov ekas.

Chcel som sa opýtať či sa diskusie niekam posunuli, keďže pracujem na študentskom projekte ktorý sa snaží využívať túto API na účtovanie bločkov. ale vzhľadom k tomu že ma to neustále blokuje vyzerá to že sa diskusia nikam nepohla…