did:web vysvětleno
Každý digitální credential někdo podepsal a ověřovatel musí být schopen zjistit, kdo to je a jaké klíče dnes používá. did:web na to odpovídá infrastrukturou, kterou už téměř každá organizace má: vlastním doménovým jménem. Identifikátor říká, které domény se zeptat, odpovědí je obyčejný soubor servírovaný přes HTTPS, a nic dalšího existovat nemusí, aby to fungovalo.
Co did:web vlastně je
DID je trvalý identifikátor, který si kdokoli může vyhledat, aby našel veřejné klíče toho, kdo jej drží. Metoda DID je pravidlo pro toto vyhledání a existují jich desítky. Některé zapisují záznam do blockchainu, jiné do sítě postavené právě k tomu, a každá nutí ověřovatele naučit se, jak zrovna ten systém funguje.
did:web jde opačnou cestou. Vyhledání je HTTPS požadavek na doménu uvedenou v identifikátoru a záznamem je soubor JSON, který vlastník domény publikuje a upravuje jako kteroukoli jinou stránku svého webu. Není k čemu se připojovat, kam zapisovat ani co platit.
Proto se objevuje tak brzy téměř v každém projektu. Tým, který umí nahrát soubor na svůj webový server, může vydávat a ověřovat credentials ještě týž den odpoledne, a identifikátor, který získá, je skutečný DID, jejž přijme každá odpovídající peněženka i ověřovatel, nikoli provizorium k pozdější výměně.
Jak se z identifikátoru stane URL
Mapování je mechanické a právě v tom je jeho smysl. Holá doména vede k souboru v adresáři well-known, který weby už používají pro strojově čitelná metadata. Přidáte-li za doménu části oddělené dvojtečkami, stanou se z nich části cesty, takže jedna organizace může vydat samostatný identifikátor pro každé oddělení, prostředí nebo vydávající službu, aniž by cokoli nového registrovala.
Dvě věci se snadno přehlédnou. U čísla portu je nutné dvojtečku zakódovat procentem, protože prostá dvojtečka už odděluje části identifikátoru. A soubor musí být servírován přes HTTPS s certifikátem, který se ověří, protože přenos je jediné, co stojí mezi ověřovatelem a podvrženou odpovědí.
Identifikátor, který vám někdo dá
did:web:example.com:issuer:euHTTPS adresa, na kterou se mapuje, bez vyhledávací služby mezi tím
https://example.com/issuer/eu/did.jsonVrácený DID document s klíči a koncovými body
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Proč si ji organizace volí
Prvním důvodem je rozpoznatelnost. Ověřovatel, který vidí identifikátor ukazující na firemní doménu, může tím nejjednodušším možným způsobem zkontrolovat, že jméno na credentialu odpovídá jménu na webu. Nikomu není třeba nejdříve vysvětlovat dotaz do rejstříku ani řetězec certifikátů, aby to dávalo smysl.
Druhým je, že provoz nic nestojí. Dokument stojí za stejným hostingem, stejným monitoringem a stejným procesem změn jako zbytek webu. Není tu samostatný systém, který by bylo nutné financovat, udržovat dostupný nebo vysvětlovat auditorovi, a rotace klíče je nasazení, nikoli transakce.
Třetím je přenositelnost. Protože ji podporuje každá knihovna peněženky i ověřovatele, je did:web metodou, která s největší pravděpodobností zafunguje vůči partnerovi, s nímž jste nikdy neintegrovali. To z ní dělá přirozenou volbu pro pilotní projekty, testovací prostředí a ty akce zaměřené na interoperabilitu, kde se evropské implementace peněženek potkávají.
Kde did:web končí
Vše, co metoda dává, stojí na doméně. Kdo ovládá registraci, jmenné servery a certifikát, ovládá identifikátor, takže propadlé prodloužení, unesený účet u DNS nebo chybně vydaný certifikát stačí k tomu, aby někdo mluvil vaším jménem. Pod tím není druhý podpis, o který by se dalo opřít.
Nemá ani paměť. Ověřovatel vidí dokument tak, jak vypadá právě teď, a nemá jak zjistit, co v něm stálo minulý týden, takže vyměněný klíč nelze odlišit od rotovaného. did:webvh existuje přesně kvůli tomu: stejný webhosting plus podepsaný protokol každé změny, do kterého lze jen přidávat, aby ověřovatel mohl sledovat historii od prvního záznamu po současný stav.
A není to kontrola totožnosti. Zveřejnění dokumentu pod doménou dokazuje kontrolu nad tou doménou a nic víc. Když ověřovatel potřebuje vědět, že právnická osoba je tím, za koho se vydává, přichází tato jistota z Trusted List, kvalifikovaného certifikátu nebo Trust Framework postaveného k tomu účelu, zatímco metoda DID nese jen klíče pod tím.
Co to znamená pro vás
Vydavatel
Zacházejte s dokumentem jako s produkční infrastrukturou od prvního dne. Zaveďte pro něj řízení změn, sledujte, že adresa odpovídá a že certifikát platí, a nechte vyřazený klíč uvedený pro ověřování tak dlouho, dokud je v oběhu cokoli, co jím bylo podepsáno.
Spoléhající se strana
Stáhnout dokument není totéž jako mu důvěřovat. Rozhodněte se zvlášť, které domény přijímáte, odmítněte vše, čí certifikát se neověří, a mezipaměť používejte obezřetně: zastaralá kopie udržuje odvolaný klíč při životě, chybějící položí vaši službu spolu s protistranou.
Držitel peněženky
Doména v identifikátoru vydavatele stojí za pohled. Je to jediná část credentialu, kterou přečtete bez jakýchkoli nástrojů, a jméno, které neodpovídá očekávané organizaci, je důvodem spíše přestat než pokračovat.
Související pojmy
Často kladené otázky
Potřebuji ke zpracování identifikátoru did:web zvláštní software?
Ne. Identifikátor je návod, jak sestavit URL, a stažení té adresy přes HTTPS vrátí dokument. Zvládne to libovolný HTTP klient, a proto je did:web obvykle první metodou, kterou tým rozběhne. Obecnou knihovnu pro řešení identifikátorů se v produkci přesto vyplatí použít, protože pravidla kódování a kontroly dokumentu uplatňuje jednotně, místo aby je nechávala na každém volajícím.
Je did:web méně důvěryhodný, protože tu není žádný blockchain?
Je důvěryhodný jinak. Metoda postavená na distribuované účetní knize rozkládá záznam mezi mnoho stran, aby jej žádná nemohla potichu přepsat. did:web klade tuto odpovědnost na vlastníka domény a na certifikační autority stojící za jeho TLS. Pro organizaci, jejíž jméno a web už jsou tím, co zákazníci poznají, je to často nejpoctivější místo pro takovou důvěru, pokud všichni chápou, že doména je slabé místo.
Co se stane s již vydanými credentials, když se klíče změní?
Ověřovatel stáhne dokument v tom stavu, v jakém je teď, takže credential podepsaný klíčem, který byl mezitím odstraněn, se už neověří. Ponechte vyřazený klíč v dokumentu, označený tak, aby mohl ověřovat, ale už ne podepisovat, přinejmenším po dobu, po kterou zůstávají platné credentials, jež podepsal. Pokud potřebujete, aby ověřovatel dokázal prokázat, který klíč platil k danému datu, právě tehdy si did:webvh svou složitost navíc zaslouží.
Zdroje
Tato stránka je informativní a nepředstavuje právní poradenství. Pro závazné pokyny nahlédněte přímo do specifikací W3C.