ID4me – jednotná identifikace a domény na německý způsob

V sídle německého doménového registru DENIC se 14. srpna sešlo přes 50 zástupců internetových společností, aby se zúčastnili prvního ročníku ID4me summitu. ID4me je aktuální název projektu, který pod názvem DomainID vznikl již loni, a zmínil jsem ho krátce v prezentaci na naší loňské konferenci IT 17.2. Za jeho vznikem stojí právě správce domény .DE spolu s významným německým registrátorem 1&1 a společností Open-Xchange, provozovatelem internetových kolaborativních nástrojů. Společností, které se aktivně hlásí jako podporovatelé, je ale více a nechybí mezi nimi například britský doménový registr Nominet. Cíle, které si projekt stanovil, jsou nám poměrně známé – redukovat množství hesel a registrací při pohybu uživatelů po Internetu. Podobně jako CZ.NIC s projektem mojeID, došli autoři ID4me k závěru, že doménový svět je právě tím místem, kde je možné pokusit se těchto cílů dosáhnout.

RDAP – nástupce WHOIS protokolu

Jsou to už čtyři roky, co jsem zde na blogu poprvé zmiňoval iniciativu na vytvoření alternativního protokolu pro službu WHOIS. Tento „vousatý“ protokol z roku 1982 přežil několik pokusů o jeho nahrazení (1995 – Whois++, 1997 – RWhois, 2005 – IRIS) a bude zajímavé sledovat, zda-li mu stávající iniciativa zasadí pověstný poslední hřebíček do rakve.

Offline přístup v mojeID

Jeden z nedostatků mojeID, na který čas od času upozorňovali poskytovatelé služeb, bylo omezení možnosti předání údajů o uživateli pouze na proces přihlášení tohoto uživatele k jejich službě. Hlavní výhoda mojeID, kterou je centrální správa údajů z jednoho místa, v takovém případě nemůže fungovat dokonale, jelikož některé služby nevyžadují, aby se uživatel přihlašoval k jejich službě příliš často. Pokud taková služba například pravidelně měsíčně fakturuje a uživatel si v mojeID změní fakturační adresu, služba se to bez přihlášení uživatele nedozví. Na tuto situaci nejspíš mysleli také architekti protokolu OpenID Connect, jelikož do jeho návrhu zahrnuli i možnost takzvaného offline přístupu. Tento offline přístup je nově dostupný také v mojeID.

Obamacare má technické problémy kvůli chybě v jednotném přihlašování

Možná jste již v médiích zaznamenali, že Barack Obama připustil rozsáhlé technické problémy své zdravotnické reformy. Jeden z architektů protokolu OpenID Connect John Bradley k tomu na svém blogu napsal krátké shrnutí, ve kterém tvrdí, že jednou z příčin těchto problémů je zvolený způsob implementace jednotného přihlašování na hlavním webu healthcare.gov.

Velké instituce, zejména ve státní správě (samozřejmě myšleno mimo ČR), nejdou úplně rychle z dobou a pro jednotné přihlašování (anglicky „single sign-on“) v rámci svých digitálních agend používají léta prověřený protokol SAML.  Platí to jak pro připravovaný systém propojení evropských digitálních identit STORK, kterého se účastníme, tak i pro systémy federální vlády Spojených států. SAML je předchůdce OpenID a psal jsem o něm i na našem blogu.

Příčinou problémů je nestandardní použití jednoho atributu protokolu SAML. To způsobuje, že poskytovatelé služeb zdravotního pojištění, kteří se chtějí napojit na centrální systém, musí aktualizovat svoje systémy, aby se nestandardnímu chování přizpůsobili.

U nás v České republice, kde v digitalizaci státní správy teprve dobíháme vyspělejší státy, a kde jsem si také užili své při startu různých centrálních registrů,  může tato situace vyvolat lehký posměch. Ani ve Spojených státech se spouštění velkých projektů neobejde bez komplikací. Na druhou stranu je třeba ocenit, že tyto vyspělejší státy sáhnou radši po prověřeném standardu, než aby vymýšlely vlastní proprietární řešení. V České republice vedle mojeID, které je již používáno i městy a obcemi, nabízí jednotné přihlašování i systém datových schránek. Ten se však vydal cestou vlastního technického řešení a zatím jej využívá jen jeden subjekt.

Jaromír Talíř

Ohlédnutí za IETF 83

Jelikož jsem v předchozích dvou blogpostech o OpenID a WHOISu nalákal čtenáře na IETF 83, sluší se přinést nějaký report o tom, jak tato konference splnila očekávání. Dá se říct, že více než dostatečně.

Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.

Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.

Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.

Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.

A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.

Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.

Jaromír Talíř