Vlákno názorů k článku Jak funguje ověřování identifikačních údajů podle Zákona o právu na digitální služby od Filip Jirsák - Já jsem to uváděl jako klasický příklad pro...

Já jsem to uváděl jako klasický příklad pro „proč musím vyplňovat údaje, které o mně stát už ví“. Protože když ty údaje nedokážete získat bleskurychle, aby si z nich mohl uživatel vybrat, je rychlejší, když to uživatel zadá sám. Přesně takhle funguje i ten našeptávač Seznamu – má smysl jedině tehdy, pokud bude zřetelně rychlejší, než když to uživatel sám napíše.

Jenze my se bavime o eGov portale, a to ze musi odpovidat bleskurychle jste sem zakomponoval vy. Ja nic takoveho nerekl. Byl jste to vy, kdo tu ze ctyr transakci v ramci komunikace eGov komponent udelal buhvijaky problem.

Zkuste ještě víc rozmyslet, jestli opravdu z hlediska uživatele není rozdíl mezi platební bránou a našeptávačem. Třeba si zkuste představit, že vám našeptávač neodpoví do 0,5 sekundy a že se vám do 0,5 sekundy nenačte platební brána. Jestli v tom pro vás jako pro uživatele nebude nějaký rozdíl, jak třeba budete dál tu službu používat nebo jestli budete nebo nebudete čekat.

Mimochodem, já jsem o žádném strašně komplikovaném problému nepsal. Psal jsem o komplikacích a psal jsem, jaké mají řešení – akorát vy jste ještě stále nepochopil, v čem ta komplikace spočívá. Protože jste stále ještě nepochopil, v čem se liší našeptávač od platební brány.

No jeste ze vas tu mame, abyste publiku vysvetlil, jak strasny problem to je... :D

Zrovna napojeni platebnich bran na eshopy je prakticka ukazka komunikace mnoha systemu mezi sebou. To, co je podle vas strasne komplikovany problem bezne pouzivaji davy lidi kazdy den. A funguje to...

přijede velké SUV k řece, řidič stáhne okénko a ptá se nedaleko stojícího Dannyho: „Tady někde by měl být brod. nevíte, kde přesně je?“ Danny odpoví: „Přímo tady jak stojíte, normálně přejedete řeku, úplně v pohodě.“ Řidiči se to nezdá, ale Dannyho ho přesvědčí, že je místní a zná to tu jako svoje boty. Řidič tedy vjede do řeky, auto se okamžitě potopí a zavře se nad ním voda. Danny kroutí hlavou, odchází a mumlá si: „Vůbec neumí řídit. Před chvilkou tam šla kačena s mladýma a vody měly sotva po břicho.“

Ale věřím vám, že opravdu upřímně nechápete, v čem spočívá rozdíl v interakci uživatele s našeptávačem a s platební branou. Že opravdu upřímně nechápete, v čem spočívá rozdíl v síťové latenci a v objemu zpracovávaných dat. Že opravdu upřímně nechápete, v čem je rozdíl mezi jedním systémem a komunikací mezi více systémy. Akorát je teda smůla, když chcete diskutovat o něčem, o čem nevíte vůbec nic.

Srovnavat naseptavac ve vyhledavacim poli (ktery kdyz nebude fungovat, tak se nic nedej, pouze clovek ten dotaz musi dopsat cely) se standardni transakci na eGov portalech (kdy i par sekund pockat nicemu nevadi) je fakt zcestny. Priklad ze zivota - transakce na platebnich branach zrovnatak nejsou behem milisekund, a nikdo z toho zadnou aferu nedela.

Na druhou stranu - jak vidite, vyhledavace prohrabujici se obrovskymi baliky dat zvladnou behem jedne vteriny (!) klidne dvacet transakci. Je to jen o tom, jak se system optimalizuje. Takze si vyrazte od programovani molochoidnich aplikaci pro statni aparat na staz do toho Seznamu - a naucte se od nich, jak to delat, aby to nebyl ten problem. Myslim ze frontpage Seznamu snasi podstatne vetsi uzivatelskou zatez nez ty systemy, co matlate vy.

Danny: Vaše schopnost argumentovat příkladem, který se v podstatných parametrech liší od problému, je obdivuhodná.

Zkuste se podívat vedle na Root na článek Našeptávač: šikovný rádce, který má na práci 50 milisekund. Na začátku článku se řeší, jak rychle musí našeptávač odpovídat, aby byl k něčemu užitečný. Můžete jít pánům do Seznamu vysvětlit, že řeší nesmysly, protože rychlost odpovědi GUI je z pohledu koncového uživatele irelevantní. A nebo něco jednoduššího – zkuste přestat psát o UX nesmysly, které odporují elementárním zásadám UX.

A vy ty tri sekvencni dotazy pokladate po 2400-baudove lince a cely system provozujete na 8080 CPU a data nacitate z dernych stitku, nebo v cemze presne ma byt ten vas pseudo-problem? Raceji si vsimnout, ze vykon co do rychlosti sitove komunikace, IOPS ulozist i procesorovy vykon za poslednich deset let vyrazne vzrostl... zatimco obyvatelstvo se zas tak rychle nemnozi. Cely vas argument s tremi sekvencnimi volanimi je nicotny a z pohledu koncoveho uzivatele (obcana) irelevantni.
Prihlaste se na Portal obcana, tam se natahuji na uvodni strance data z hned nekolika nezavislych agend. Funguje to. Hledate problem, tam kde neni.

Technicky vzato ovšem není jedno, jestli se dotazujete jedné vlastní služby, nebo jestli se dotazujete sekvenčně tří cizích služeb. I kdybyste na ty cizí služby nastavil super SLA, to, že jsou to tři sekvenční volání, prostě neokecáte. Na auditování žádné ZR nepotřebuju, standardizovaný přístup také ne, oprávněnost vyžádání dané informace ZR neřeší.

Optimální řešení jste tu zatím nenavrhl, přičemž příležitostí jste měl dost. Takže zatím to vypadá, že rozdáváte knížecí rady „jde to i lépe“, aniž byste alespoň tušil, jak by to lépe mělo vypadat.

Technicky vzato je jedno, ceho se dotazujete. Je legitimni vest debatu o tom, jak moc je ZR optimalizovany na vyssi zatez, ale princip fungovani jako takovy spatny neni - neb jsou tam vyresene i veci jako auditovany a standardizovany pristup k informacim pri sdileni informaci napric ruznymi registry, kdy se kontroluje i opravnenost vyzadani dane informace... drobnost, kterou stale boharovne prehlizite.

A samozrejme, aplikace mohou byt navrzeny suboptimalne - typicky jsou to prave vyvojari (ci analytici pred nimi), co si v nejakem bode ponekud usnadni svuj zivot (asi aby tim nezabili tolik casi a meli vice casu na naslednou prokrastinaci)... a vyslednym produktem je nejaky paskvil. Coz zrovna mapa nacitajici vsechny koncove body do jedne mapy naraz samozrejme svym zpusobem je - a napsat to lepe zadny problem neni, staci chtit. Jenze ted strilite do vlastnich (vyvojarskych) rad... ;-)

Jasně, Alza se kvůli zobrazení doporučeného zboží dotazuje základních registrů… Navíc teda nabídka dalšího zboží či služeb k výrobku může být předpočítaná dopředu a může to být jen vrácení statického obsahu. A do třetice, nabídka dalšího zboží či služeb je v hierarchii důležitosti prvků na stránce dost nízko, protože když se to načte později nebo vůbec, uživateli to nijak nenaruší jeho práci.

Principiálně aspoň trochu podobná věc je třeba výběr místa uložení zásilky v košíku (když volíte Zásilkovnu, Uloženku, Balík na Poštu apod.). Tam volá e-shop externí službu (jenom jednu). Nevím,jak vy, ale já jako uživatel jsem vyloženě nadšený z toho, když chci zásilku uložit tam, jako vždycky, ale musím čekat, než se načte celá mapa ČR se všemi místy, pak můžu zadat PSČ a pak si konečně můžu vybrat pobočku. Kterou vím už od začátku. To je zrovna ten případ, kdy je ruční zadání rychlejší než volání služby a následný výběr. (A i kdyby to fyzicky rychlejší nebylo, z pohledu uživatele je to rychlejší rozhodně. Pocitově je výrazně rychlejší něco vyplňovat, než čekat, abyste mohl něco vyplnit možná rychleji.)

Ano, to jste popsal velmi hezky tu složitější variantu, ale do toho jsem se nechtěl pouštět... Z pohledu agenty X jsem se zeptal na údaje k AIFO 111 a nezajímá mě až tak moc, kolikrát bylo toto AIFO 111 přeloženo na jiné AIFO.

Stejně tak to vnímám i z pohledu běžného občana. Je mi putna, kolikrát se můj identifikátor převede mezi agendami, to už je jiný problém, pro mě je důležité, že mě stačí jeden identifikátor.

A copak asi dela treba takovy mimozemstan na pozadi, kdyz vam pri nakupu podbizi dalsi zbozi ci sluzby kontextove spadajici ke kupovanemu artiklu, hmm? :-) Principielne je to obdobna vec, na zaklade interakce uzivatele se neco vraci...

Parametry SZR zrovnatak nejsou staticka vec a podle definovanych potreb se muzou v case upravovat - a sluzby dnes vedene v nejnizsi kategorii se muzou napr. posunout do kategorie vyssi. Samozrejme je to spojene mj. s financemi, ona i ta rychlejsi odpoved neco stoji. Takze je to cele o tom, jak se nastavi priority...

Danny: netvařte se, že jste tak hloupý a nechápete rozdíl mezi různými voláními, která probíhají během několika minut když uživatel prochází stránky e-shopu, a postupným voláním čtyř služeb v rámci interakce s UI, kdy první službu zavoláte na základě interakce uživatele (třeba kliknutí na tlačítko) a výsledek té čtvrté služby v pořadí potřebujete uživateli na téže stránce nabídnout.

Jen pro vaši informaci, e-shop typicky volá svoje vlastní služby, u kterých si může nastavit parametry podle potřeby. Služby základních registrů mají v nejvyšší kategorii garantovánu odpověď do 2 sekund v 90 % případů volání. Třeba ty služby převodu AIFO patří do nejnižší kategorie.

No tak ja vam dam odkaz na konkretni prispevek v diskuzi, kdyz mate potize i se zrakem :-)

Pokud CUZK takovou povinnost formalne dostane, tak pres v tom prispevku popsane rozhrani si ty informace pochopitelne overit bude moct (konkretne asi dotazem do SIMS zprostredkovany referencnim rozhranim) - a samozrejme bude auditovane kazdy pristup k temto udajum. Samozrejme pusobnost SIMS bude nutne legislativne rozsirit minimalne i na zaky strednich skol, dnes tam jsou vedeni jen vysokoskolaci. A pro potreby CUZK v danem prikladu bude stacit podpoved, zda dotycny je/neni student, naopak k nicemu nepotrebuje informaci napr. o tom, jakou skolu a jaky studijni program studuje (ktera je v SIMS take zanesena)...

Ctyri volani, strasna tragedie. Podle vasi teorie "je to strasny problem" by se musela spousta sluzeb provozovanych v soukromem sektoru davno zhroutit (v podstate jakykoliv vice navstevovany eshop). Ale nehrouti se... cimpak to asi bude? ;-)

Dobře, já to zde popsané řešení neumím najít, tak pro vás jistě nebude problém popsat, jak by takové řešení mělo vypadat. Pořád se oháníte ČÚZK, tak dejme tomu, že ČÚZK dostane zákonem novou povinnost všem studentům do 26 let poskytovat 50 % slevu na veškeré zpoplatněné úkony. Takže student se přes NIA přihlásí do portálu ČÚZK, tam si něco vybere a bude to chtít zaplatit – moderně, takže hned a tedy platební kartou. Takže je potřeba před vyčíslením částky zjistit, zda je student. Za císaře pána byste se dotyčného zeptal, zda je student, a pokud ano, poslal byste ho s papírem na školu, ať přinese potvrzení. To není úplně vhodné řešení do digitálního světa. Tak popište, jak by to mělo podle vás fungovat. Můžete to zkusit dvěma variantami – ideální, jak by to podle vás mělo vypadat. A pak variantu se současnými reáliemi, tj. např. neexistuje žádný registr žáků a studentů.

Reseni tu popsane bylo. Ale vam nevyhovuje. Jeho implementace je pro vas pracnejsi a to by pak bylo mene casu na zvaneni po internetech, ze? :-)

Jenže ono se to postupně hromadí. Jeden dotaz na převod BSI na AIFO, druhý dotaz do ISEO (který stojí trochu bokem, kdyby to byl standardní nový AIS, musíte ještě před tím vytvořit úložku a cílový AIS by si ji musel vyzvednout – to už máte celkem 4 volání).

„Zneužít RČ“ je nonsens. Bavíme se o identifikátorech, což jsou z principu veřejné údaje. Místo RČ se může použít jméno, datum narození a adresa trvalého pobytu. Když to někdo „zneužije“, mám se přestěhovat? Ne, stačilo by identifikátor používat jako identifikátor a netvářit se, že je to tak trochu i zabezpečení.

Správným směrem se to posunulo až v okamžiku, kdy se vám podařilo prosadit používání čísla dokladu jako identifikátoru pro soukromou sféru. Teď už zbývá dotáhnout jenom ten poslední krok – zjistit, že číslo dokladu se mění, což je pro jednoznačný identifikátor podstatná komplikace, a vytvořit nový bezvýznamový identifikátor, který se na rozdíl od čísla dokladu nebude měnit.

To, že žádné lepší řešení nemáte, už víme, nemusíte to pořád dokola opakovat.

Soukromý sektor nemá AIFO, ale BSI, které může předat úřadu, to zákon povoluje, a úřad si ho umí přeložit na AIFO.

Stejně tak dotaz přes jméno+příjmení+ob­čanku do ROBu pro zjištění AIFO je otázka do 1 sec. (pokud jsou základní registry ve formě :-) ), aktuální trvání:
2022-07-07 11:37:30.0395 Dotaz
2022-07-07 11:37:30.2115 Odpověď
2022-07-07 11:39:19.7652 Dotaz
2022-07-07 11:39:20.0562 Odpověď

V tom bych problém opravdu neviděl. Výhoda je v tom, že pak občan vidí, že se něco dělo, protože ten dotaz uvidí ve výpisu z ROBu, a může se ptát. Pokud agenda potřebuje pro svou práci často některé údaje, může si je držet u sebe a odebírat notifikace o změnách.

"Cílový IS nemůže mít předem stažené údaje o všech vazbách rodič–dítě, a kdyby se ty údaje měly zjišťovat online, bude to trvat déle, než když uživatel ty údaje vyplňuje ručně. "

To s délkou trvání si nemyslím (konkrétně tato úloha je jeden dotaz do ISEO buď na základě jména+příjmení+ob­čanky nebo AIFO) a také to nemá nic společného s tím, zda existuje neměnný, všemi sdílený identifikátor.

Mít jeden neměnný, všemi sdílený identifikátor přes státní správu i soukromou sféru, už není potřeba. Když mám podezření, že někdo zneužil mé RČ, tak mohu jen pokrčit rameny, protože změnit RČ není jednoduché. Když budu mít problém s občankou, tak ji mohu zneplatnit a dostanu novou, s novým číslem.

Ano, má to zatím mouchy a něco se bude dělat komplikovaněji, ale z mého pohledu to jde správným směrem.

Ja dobre chapu, ze budete krecovite obhajovat soucasne reseni, ktere vas chlebodarce statni sprave dodava. Kdybyste to musel od zakladu predelavat, nemel byste tolik casu na vykecavani se na internetu ;-)

Bohužel vůbec netušíte, o čem je řeč. Zadávat se samozřejmě něco musí. Uváděl jste jako příklad katastr, tak se podívejte třeba na převod nemovitosti. Ten nemůže zahájit úřad jen tak sám od sebe, že se jednoho dne rozhodne vaši nemovitost převést někomu jinému. Ten podnět musí vyjít od vás, jako současného vlastníka nemovitosti, případně od budoucího vlastníka nemovitosti. Když to budete dělat vy, digitálně, někam se přihlásíte – tím je známá vaše identita. Pak potřebujete vědět, které se to týká nemovitosti – to si katastr dokáže ve svém IS dohledat. A pak je potřeba zadat, komu tu nemovitost převádíte. Dnes se to dělá tak, že zadáte jméno, příjmení, adresu trvalého pobytu a datum narození, a doufáte, že to bude jednoznačná identifikace. Navíc je to docela dost údajů, můžete v tom udělat překlep, většina lidí ani neví, jak správně vypadá adresa jejich bydliště. Můžete místo toho zadat číslo dokladu, jenže až se kupující do nové nemovitosti přestěhuje, změní si adresu trvalého pobytu, tím se mu změní i občanka a ten identifikátor přestane být platný. Opravdu chcete mít smlouvu o prodeji nemovitosti vázanou na něco, co za pár měsíců přestane platit? Když se tomu člověku změní občanka jen jednou, ještě ho podle ní dohledáte. Ale pak se třeba vdá, změní si jméno a tím znovu i občanku a podle toho původního čísla už ho nedohledáte. Opravdu chcete mít v ruce 2 roky starou smlouvu na prodej nemovitosti, kde je kupující identifikován způsobem, u kterého nejste schopen ověřit, kdo to je?

Jak jsem psal výše, těch strojových dotazů je několik a volají se jeden po druhém, protože další závisí na výstupu předchozího. Pokud jde o stručné údaje, které uživatel zadá rychle, je pro uživatele rychlejší, když je rovnou zadá ručně, než když se bude 5 vteřin čekat, jestli se náhodou nepodaří rychle získat data, a pak to stejně přepnout do režimu, kdy to uživatel musí zadat ručně.

Zakladni fail je uz uvaha o tom, se se musi neco (rucne) zadavat. To je pristup z dob pana cisarepana, kdy se jen papirovy formular preklopi do pocitace - nejspis to je zpusob, jakym to u vas ve firme delat.

Ja teda nevim, co popisujete... takhle funguji systemy, ktere u vas ve firme delate? Strojovy dotaz opravdu ze trva dele, nez rucni vyplneni? :-)

Tohle je ovšem jenom teorie. Prakticky ta státní správa potřebuje komunikovat i se soukromým sektorem, který ovšem nemá přístup do ZR, tudíž nemá žádné AIFO.

Druhá věc je, že tyhle překlady přes ISZR jsou sice hezké z pohledu back-office, ale z důvodu UX pak stejně potřebujete ty údaje zadat od občana a to propojení IS se využije až na back-office jenom pro kontrolu, že občan ty údaje zadal správně.

Normálně by totiž člověk čekal, že když je potřeba do aplikace zadat údaje třeba o dětech, aplikace ty údaje získá z registru obyvatel a jenom mu nabídne, kterého dítěte se daná věc týká. Cílový IS nemůže mít předem stažené údaje o všech vazbách rodič–dítě, a kdyby se ty údaje měly zjišťovat online, bude to trvat déle, než když uživatel ty údaje vyplňuje ručně. Nejprve se musí přeložit identifikátory, pak teprve se mohou v cílovém systému hledat potřebné údaje – a sekundy plynou (v optimálním případě). To samé když budete potřebovat znát třeba příjmy, nebo kdyby někdo chtěl od vás zjišťovat, zda je daná osoba vlastníkem příslušné nemovitosti. Je rychlejší, když uživatel vybere z nabídky, že je vlastníkem, a pak se to v back-office zkontroluje, než kdyby měl uživatel čekat, než se to zjistí online. A uživatelé se pak diví, proč po nich stát chce vědět, zda jsou vlastníkem té nemovitosti, když to přece stát ví. Ano, ví, výměna informací funguje, ale pro uživatele je to k ničemu.

Tady bych si dovolil nesouhlasit. Propojení státních databází a jeden univerzální a společný identifikátor osoby nemá až tak moc společného.
Tuto oblast má podle mě stát naopak navrženu z mého pohledu poměrně pěkně a bezpečně.
To, že každá fyzická osoba má v rámci různých agend jiný identifikátor je OK. Dokonce i v rámci jednoho úřadu, pokud provozuje více agend (např. ČÚZK, který provozuje 3 agendy), tak jedna fyzická osoba má v každé agendě jiný identifikátor (AIFO) a tyto agendy nejdou jednoduše napřímo propojit.
Propojit to jde, ale přes referenční rozhraní (ISSS, ISZR), které mimo jiné zajišťuje audit, kontrolu oprávnění (až na úroveň atributů) a překlad těchto identifikátorů ze zdrojové agendy na cílovou. Podmínkou je mít v agendách ztotožněné osoby.
Příklad - agenda X má osobu Pepa Novák s AIFO 111. Když se chce zeptat na údaje jiné agendy Y pro tuto osobu, tak agendě zašle dotaz přes referenční rozhraní, které zajistí, že do agendy Y doputuje dotaz na osobu a AIFO 222, což je identifikátor osoby v dané (cílové) agendě Y. Agenda Y si najde podle AIFO 222 danou osobu a vrátí požadované informace.
V obou agendách má osoba jiný identifikátor, přesto výměna informací funguje.

8. 7. 2022, 11:52 editováno autorem komentáře

Ano, všichni se diví, že stát nemá propojené databáze a úřady neustále dokola zjišťují od lidí to, co evidují jiné úřady. Přitom se ale v posledních 20 letech v českém e-governmentu řeší prakticky jediná věc – aby neexistoval jednoznačný identifikátor osob, tedy právě to, aby ty databáze propojené nebyly.

Je zajímavé, kolik úsilí se věnuje tomu, aby stát neměl jednoduchou evidenci svých občanů. Na jedné straně je pravda, že soustředit příliš údajů na jednom místě může vést k nepříjemnostem (jako v Číně: údaje o miliardě lidí jsou prý na prodej...), na druhou stranu se tak stát pomalu stává jediným ve státě, kdo podrobné údaje o občanech nemá.
Policajt nemůže snadno a rychle zjistit podle občanky, zda máte řidičák (a nemáte zákaz řízení), zbrojní pas (a registrovanou zbraň), a psychickou poruchu (takže nemáte ani řídit, ani se ozbrojovat). Ale Google, Facebook a podobní vědí, kde bydlíte, s kým se bavíte, s kým intimníte, co nakupujete, kde kupujete naftu, kde hnojiva (a nabídne, kde dostanete slevu na papiňák) - to všechno ve vašem mobilu. Banka ví, jakou máte identitu (i erár tomu věří!), kolik dlužíte a kolik vám ještě může půjčit - a dá vám to do mobilu, abyste věděli, že už vám nepůjčí. Každej obchodník vám nabídne slev, kolik jen unesete, protože ví, co u něj kupujete, jak často - a co byste si koupit mohli. Však na ty slevy máte appku v mobilu. A když něco potřebujete objednat, zaplatit, vyřídit - nic jednoduššího: přihlásíte se, opíšete kód ze SMS nebo kliknete na appku v mobilu - a hned se přidá další záznam!
Rušíme rodné číslo, abychom chránili soukromí občanů, a nehradili jsme je méně dokonalým identifikátorem: telefonním číslem. Jeden občan = jeden telefon = jedno číslo... (A kdo se tomuto vzorci vymyká, bude omezen na svém konzumním pohodlí a koleduje si o vážné problémy v běžném životě.)