did:web elmagyarázva
Minden digitális credentialt valaki aláírt, és egy ellenőrzőnek ki kell tudnia keresni, ki az, és milyen kulcsokat használ ma. A did:web erre azzal az infrastruktúrával válaszol, amivel szinte minden szervezet már rendelkezik: a saját domainnevével. Az azonosító megmondja, melyik domaint kell kérdezni, a válasz egy hétköznapi, HTTPS-en kiszolgált fájl, és semmi másnak nem kell léteznie ahhoz, hogy működjön.
Mi is valójában a did:web
A DID egy állandó azonosító, amelyet bárki kikereshet, hogy megtalálja a birtokosához tartozó nyilvános kulcsokat. A DID-módszer az a szabály, amely ezt a keresést leírja, és több tucat ilyen létezik. Egyesek blokkláncra írják a bejegyzést, mások erre a célra épített hálózatra, és mindegyik arra kényszeríti az ellenőrzőt, hogy megtanulja, hogyan működik éppen az a rendszer.
A did:web az ellenkező utat választja. A keresés egy HTTPS-kérés az azonosítóban megnevezett domainhez, a bejegyzés pedig egy JSON-fájl, amelyet a domain tulajdonosa úgy tesz közzé és szerkeszt, mint a webhelye bármely más oldalát. Nincs hálózat, amihez csatlakozni kell, nincs főkönyv, amibe írni kell, és nincs fizetendő díj.
Ezért bukkan fel ilyen korán szinte minden projektben. Egy csapat, amely fel tud tenni egy fájlt a webkiszolgálójára, már aznap délután kiállíthat és ellenőrizhet credentialokat, és a kapott azonosító igazi DID, amelyet minden szabványkövető tárca és ellenőrző elfogad, nem pedig később lecserélendő ideiglenes megoldás.
Hogyan lesz az azonosítóból URL
A leképezés gépies, és éppen ez a lényege. A puszta domain egy fájlhoz vezet abban a well-known könyvtárban, amelyet a webhelyek már most is gépi olvasásra szánt metaadatokhoz használnak. Ha a domain után kettőspontokkal elválasztott részeket ad hozzá, azokból útvonalrészek lesznek, így egy szervezet külön azonosítót tehet közzé részlegenként, környezetenként vagy kiállítási szolgáltatásonként anélkül, hogy bármi újat regisztrálna.
Két részlet könnyen elkerüli a figyelmet. A portszám kettőspontját százalékos kódolással kell írni, mert az egyszerű kettőspont már az azonosító részeit választja el. A fájlt pedig HTTPS-en, érvényes tanúsítvánnyal kell kiszolgálni, mivel az átvitel az egyetlen dolog, ami az ellenőrző és egy hamisított válasz között áll.
Az azonosító, amit valaki átad Önnek
did:web:example.com:issuer:euA HTTPS-cím, amelyre leképeződik, közbeiktatott kereső szolgáltatás nélkül
https://example.com/issuer/eu/did.jsonA visszakapott DID document a kulcsokkal és a végpontokkal
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Miért ezt választják a szervezetek
Az első ok a felismerhetőség. Egy ellenőrző, amely egy céges domainre mutató azonosítót lát, a lehető legegyszerűbb módon tudja ellenőrizni, hogy a credentialon szereplő név egyezik a webhelyen szereplővel. Senkinek nem kell előbb cégnyilvántartási lekérdezést vagy tanúsítványláncot elmagyarázni ahhoz, hogy ez célba érjen.
A második, hogy az üzemeltetése semmibe sem kerül. A dokumentum ugyanazon tárhely, ugyanazon felügyelet és ugyanazon változáskezelési folyamat mögött áll, mint a webhely többi része. Nincs külön rendszer, amit finanszírozni, rendelkezésre tartani vagy egy könyvvizsgálónak elmagyarázni kellene, és a kulcscsere telepítés, nem pedig tranzakció.
A harmadik a hordozhatóság. Mivel minden tárca- és ellenőrzőkönyvtár támogatja, a did:web az a módszer, amely a legnagyobb eséllyel működik egy olyan partnerrel, akivel még soha nem integrált. Ettől lesz természetes választás kísérleti projektekhez, tesztkörnyezetekhez és azokhoz az interoperabilitási eseményekhez, ahol az európai tárcamegvalósítások találkoznak.
Ahol a did:web véget ér
Minden, amit a módszer ad, a domainen nyugszik. Aki a regisztrációt, a névszervereket és a tanúsítványt felügyeli, az felügyeli az azonosítót is, így egy lejárt meghosszabbítás, egy eltérített DNS-fiók vagy egy tévesen kiállított tanúsítvány elég ahhoz, hogy valaki az Ön nevében beszéljen. Nincs alatta második aláírás, amire vissza lehetne esni.
Emlékezete sincs. Az ellenőrző a dokumentumot úgy látja, ahogyan éppen most áll, és semmiképp nem tudhatja meg, mi állt benne múlt héten, így egy kicserélt kulcs nem különböztethető meg egy rendben cseréltől. A did:webvh pontosan ezért létezik: ugyanaz a webtárhely, plusz minden változás aláírt, csak bővíthető naplója, hogy az ellenőrző az első bejegyzéstől a jelenlegi állapotig követhesse a történetet.
És ez nem személyazonosság-ellenőrzés. Egy dokumentum közzététele egy domain alatt az adott domain feletti felügyeletet bizonyítja, semmi mást. Amikor egy ellenőrzőnek tudnia kell, hogy egy jogi személy az, akinek mondja magát, ez a bizonyosság egy Trusted Listből, egy minősített tanúsítványból vagy egy erre épített Trust Frameworkből érkezik, miközben a DID-módszer csak az alatta lévő kulcsokat hordozza.
Mit jelent ez Önnek
Kibocsátó
Kezelje a dokumentumot az első naptól éles infrastruktúraként. Vonja változáskezelés alá, figyelje, hogy a cím válaszol-e és hogy a tanúsítvány érvényes-e, és hagyja a kivont kulcsot ellenőrzésre felsorolva addig, amíg bármi használatban van, amit vele írtak alá.
Bizalmat adó fél
A dokumentum lekérése nem ugyanaz, mint megbízni benne. Külön döntse el, mely domaineket fogadja el, utasítson el mindent, aminek a tanúsítványa nem érvényes, és óvatosan gyorsítótárazzon: egy elavult másolat életben tart egy visszavont kulcsot, egy hiányzó pedig a másik féllel együtt viszi le a szolgáltatását.
Tárcabirtokos
A kibocsátó azonosítójában szereplő domain megér egy pillantást. Ez a credential egyetlen olyan része, amelyet eszközök nélkül el tud olvasni, és egy név, amely nem egyezik a várt szervezettel, inkább megállásra, semmint folytatásra ad okot.
Kapcsolódó fogalmak
Gyakran ismételt kérdések
Kell külön szoftver egy did:web azonosító feloldásához?
Nem. Az azonosító egy recept egy URL felépítéséhez, és ha ezt a címet HTTPS-en lekérjük, visszakapjuk a dokumentumot. Bármelyik HTTP-kliens képes rá, és emiatt a did:web többnyire az első módszer, amit egy csapat működésre bír. Éles üzemben mégis érdemes általános feloldókönyvtárat használni, mert egységesen alkalmazza a kódolási szabályokat és a dokumentum ellenőrzéseit, ahelyett hogy minden hívóra bízná őket.
Kevésbé megbízható a did:web, mert nincs mögötte blokklánc?
Másképpen megbízható. Az elosztott főkönyvre épülő módszer sok fél között osztja szét a bejegyzést, hogy egyikük se írhassa át csendben. A did:web ezt a felelősséget a domain tulajdonosára és a TLS mögött álló hitelesítésszolgáltatókra helyezi. Egy olyan szervezet esetében, amelynek neve és webhelye már úgyis az, amit az ügyfelek felismernek, ez gyakran a legőszintébb hely a bizalom számára, amíg mindenki érti, hogy a domain a gyenge pont.
Mi történik a már kiállított credentialokkal, ha a kulcsok megváltoznak?
Az ellenőrző a dokumentumot a mostani állapotában kéri le, így egy időközben eltávolított kulccsal aláírt credential többé nem ellenőrizhető. Hagyja bent a kivont kulcsot a dokumentumban, úgy megjelölve, hogy ellenőrizni tudjon, aláírni viszont már ne, legalább addig, amíg az általa aláírt credentialok érvényesek maradnak. Ha egy ellenőrzőnek bizonyítania kell, melyik kulcs volt érvényes egy adott napon, ott érdemli ki a did:webvh a többletbonyolultságát.
Források
Ez az oldal tájékoztató jellegű, és nem minősül jogi tanácsadásnak. Mérvadó útmutatásért tekintse meg közvetlenül a W3C specifikációit.