DID magyarázva: mi az a decentralizált azonosító
A decentralizált azonosító, szinte mindig DID formában írva, olyan név egy félre, amelyet senkinek nem kell kibocsátania és senki nem vehet vissza. Válasz arra a kérdésre, amelybe előbb-utóbb minden digitális hitelesítő adat beleütközik: a tárcában egy aláírt állítás van, tehát ki írta alá, és hogyan ellenőrizhető ez anélkül, hogy a nyilvántartás vezetőjének írnánk?
Ez az oldal a közérthető változat. Bemutatja, miből áll egy DID, mi történik a feloldásakor, miben különböznek a gyakori módszerek, és, ugyanilyen fontos, mit nem mond el önmagában egy DID.
Miből áll egy DID
A DID egyetlen szövegsor három, kettősponttal elválasztott részből. Az első rész soha nem változik. A második megnevezi a módszert, a harmadik pedig az, amire annak a módszernek szüksége van a megfelelő dokumentum megtalálásához.
A középső rész az egyetlen valódi döntés. Minden, amiről a DID-ek kapcsán vitatkozni szoktak, hol vannak az adatok, ki módosíthatja őket, mennyibe kerül az üzemeltetés, a módszerből következik és semmi másból.
did:web:credenco.com
did
Séma
Mindig ugyanaz a három betű. Nem mond többet annál, hogy ami következik, az decentralizált azonosító.
web
Módszer
A dokumentum megtalálásának és frissítésének szabályai. Ez az a döntés, amelynek valódi következményei vannak, mert eldönti, kinek kell elérhetően tartania az azonosítót.
credenco.com
Módszerspecifikus azonosító
Az a rész, amelyet csak az a módszer tud olvasni. Itt egy domainnév, máshol lehet nyilvántartási bejegyzés vagy maga a nyilvános kulcs.
Mi történik a feloldáskor
Önmagában egy DID nem csinál semmit. Az értéke abban a pillanatban jelenik meg, amikor valaki feloldja: a karakterláncot átalakítja a mögötte álló kis dokumentummá, amely felsorolja az alany által használt nyilvános kulcsokat és azt, hol érhető el az alany.
1. Van egy azonosítója
Érkezik egy hitelesítő adat, amely megnevezi az aláíró felet. Egyelőre ez csak egy karakterlánc, és semmit sem bizonyít.
2. Egy feloldó elolvassa a módszert
A módszer neve megmondja a feloldónak, hová menjen: fájlt letölteni egy domainről, nyilvántartást olvasni, vagy kibontani a kulcsot magából az azonosítóból.
3. Visszaérkezik egy dokumentum
Felsorolja a nyilvános kulcsokat, amelyeket az alany most használ, és a végpontokat, ahol elérhető.
4. Ön ellenőrzi az aláírást
Sehol sem kell fiók, nem kell API-kulcs, és nem kell engedélyt kérni attól, aki a módszert üzemelteti.
Miért ne domainnév vagy tanúsítvány
A webnek már vannak módjai megmondani, ki kicsoda, így jogos a kérdés, mit tesz hozzá egy DID. Egy domainnév megmondja, hová küldjünk kérést, de semmit nem mond arról, mely kulcsok tartoznak a mögötte álló félhez. A tanúsítvány valóban kulcsot köt névhez, és jól teszi, de csak addig, amíg egy hatóság ezt fenntartja, és csak arra a kulcsra, amelyre kiállították.
A hitelesítő adatnak kellemetlen szokása mindkettőt túlélni. Egy diploma húsz év múlva is diploma, jóval azután, hogy az aláíró kulcsot lecserélték és a hozzá tartozó tanúsítvány lejárt. Mivel a DID elválasztja a nevet a kulcsoktól, a kibocsátó lecserélheti a kulcsot anélkül, hogy az azonosító megváltozna, és anélkül, hogy újra kibocsátaná mindazt, amit valaha aláírt.
A kulcsok változnak, a név nem
Egy kompromittált kulcs cseréje azt jelenti, hogy új dokumentumot tesznek közzé ugyanazon az azonosítón. A kibocsátóra mutató minden hivatkozás érvényes marad.
Az ellenőrzéshez senki engedélye nem kell
Az ellenőrző feloldja az azonosítót és ellenőrzi a matematikát. Nem kell fiókot nyitni a kibocsátónál, és nincs kéréskorlát más szolgáltatásán.
A módszerek, amelyekkel valóban találkozni fog
Jóval több mint száz módszert regisztráltak, és szinte mindegyiket nyugodtan figyelmen kívül hagyhatja. Három lefedi szinte mindazt, amivel egy szervezet az európai ökoszisztémában találkozik.
did:web
A dokumentum egy fájl egy olyan domainen, amelyet már felügyel. Semmi újat nem kell üzemeltetni, és a belépési küszöb közel nulla, ezért a legtöbb szervezet innen indul. A bökkenő az, hogy aki a domaint felügyeli, az felügyeli az azonosítót is, és semmi nem őrzi meg, mit mondott a dokumentum tegnap.
Olvassa el a meghatározástdid:webvh
Ugyanaz a domainen tárolt fájl, kiegészítve egy csak bővíthető naplóval minden verziójáról. Az ellenőrző látja, hogy a ma megbízhatónak tartott kulcsot az a fél helyezte oda, amely tegnap birtokolta az azonosítót, és épp ezt a rést hagyja nyitva a did:web.
Olvassa el a meghatározástdid:key
Az azonosító maga a kódolt nyilvános kulcs. Nincs mit tárolni és nincs mit letölteni, ezért ideális rövid életű és eldobható identitásokhoz. Azt is jelenti viszont, hogy a kulcs soha nem cserélhető, így rossz választás bármihez, aminek tartósnak kell lennie.
A többit a W3C DID-módszerek nyilvántartása sorolja fel. Az olyan módszert, amely nincs benne, vagy amelyet csak egyetlen termék támogat, kezelje az adott terméktől való függőségként.
Mit nem mond el egy DID
Itt a DID-ekről szóló magyarázatok többsége csendben abbamarad, pedig épp ez a rész dönti el, működik-e egy tárcaprogram. A DID folytonosságot bizonyít: az a fél, aki ezt a hitelesítő adatot aláírta, ugyanazt a kulcsot birtokolja, mint aki a másikat aláírta. Arról, hogy ez a fél kicsoda a világban, semmit sem bizonyít.
Bárki létrehozhat egy DID-et néhány másodperc alatt, az is, aki egyetemnek adja ki magát. Annak megállapítása, hogy egy azonosító valóban akkreditált intézményhez tartozik, külön munka, amelyet egy megbízható lista, egy minősített tanúsítvány vagy egy olyan fél igazolása végez el, amelyben az ellenőrző már megbízik. Az eIDAS 2.0 alatt pontosan ezért vannak a megbízható listák és az igénybe vevő felek nyilvántartásba vétele.
A kettőt együtt olvasva a kép egyszerű: a DID hordozza a kulcsokat, a bizalmi keretrendszer hordozza a jelentést, és az ellenőrzőnek mindkettőre szüksége van, mielőtt bármit elfogad.
Mit jelent ez Önnek
Kibocsátó
Egyetlen azonosító, amely túlél minden kulcscserét, így egy évekkel ezelőtt aláírt hitelesítő adat továbbra is ellenőrizhető, a kompromittált kulcs pedig üzemeltetési feladat lesz visszahívás helyett.
Ellenőrző
Aláírást fiók, szerződés vagy kibocsátónkénti integráció nélkül ellenőrizhet. Amire továbbra is szüksége van, az egy megbízható lista, amely megmondja, mely azonosítókat fogadhatja el.
Tárcabirtokos
Nincs mit kezelni. Az azonosítók a hitelesítő adataiban vannak, és a tárca feloldja őket ön helyett, amikor megmutatja, ki mit bocsátott ki.
Kapcsolódó fogalmak
Gyakori kérdések
Kell blokklánc a DID-ek használatához?
Nem. Ez a társítás az elsőként megépített módszerekből ered, nem a szabványból. A specifikáció semmit sem mond arról, hol kell a dokumentumnak lennie, és az Európában naponta használt módszerek, a did:web és a did:webvh, mindkettő közönséges HTTPS-en kiszolgált fájl egy olyan domainről, amellyel a tulajdonos már rendelkezik.
Miért ne egyszerűen egy domainnevet használnánk?
Egy domain megmondja, hol találhatunk valamit, azt nem, mely kulcsok tartoznak hozzá, a tanúsítvány pedig addig köti a kulcsokat egy névhez, amíg egy hatóság ezt fenntartja. A DID egyszerre adja mindkettőt, és stabilan tartja az azonosítót, miközben a mögötte lévő kulcsok cserélődnek. Épp ettől ellenőrizhető ma is egy három éve aláírt hitelesítő adat.
Melyik módszert válasszuk?
Induljon ki abból, meddig kell kitartania az azonosítónak, és ki módosíthatja. Olyan kibocsátónak, akinek a hitelesítő adatai túlélik a kulcsait, a did:webvh megadja az ellenőrzőknek azt az előzményt, amely alapján megbízhatnak egy kulcscserében. Belső pilotokhoz és rövid életű identitásokhoz általában elég a did:web vagy a did:key, a későbbi váltás pedig szokásos migráció, nem átépítés.
Bizonyítja-e egy DID, hogy egy szervezet az, akinek mondja magát?
Nem, és ennek feltételezése a leggyakoribb hiba. A DID azt bizonyítja, hogy aki két dolgot aláírt, ugyanazt a privát kulcsot birtokolta. Hogy az a kulcs egy akkreditált egyetemé-e, vagy valakié, aki meggyőző domaint regisztrált, külön kérdés, amelyre egy megbízható lista, egy minősített tanúsítvány vagy egy olyan fél igazolása válaszol, akiben már megbízik.
Források
Ez az oldal tájékoztató jellegű, és nem minősül jogi tanácsadásnak. A mérvadó szöveget közvetlenül a W3C specifikációjában találja.