DID wyjaśniony: czym jest zdecentralizowany identyfikator
Zdecentralizowany identyfikator, prawie zawsze zapisywany jako DID, to nazwa strony, której nikt nie musi wydawać i nikt nie może odebrać. To odpowiedź na pytanie, na które prędzej czy później natrafia każde cyfrowe poświadczenie: portfel przechowuje podpisane oświadczenie, więc kto je podpisał i jak to sprawdzić bez pisania do tego, kto prowadzi rejestr?
Ta strona to wersja napisana prostym językiem. Omawia, z czego składa się DID, co dzieje się przy jego rozwiązywaniu, czym różnią się popularne metody i, równie ważne, czego DID sam w sobie nie mówi.
Z czego składa się DID
DID to jedna linia tekstu złożona z trzech części oddzielonych dwukropkami. Pierwsza część nigdy się nie zmienia. Druga nazywa metodę, a trzecia to wszystko, czego ta metoda potrzebuje, aby znaleźć właściwy dokument.
Ta środkowa część to jedyna prawdziwa decyzja. Wszystko, o co toczą się spory wokół DID, gdzie leżą dane, kto może je zmieniać, ile kosztuje utrzymanie, rozstrzyga metoda i nic poza nią.
did:web:credenco.com
did
Schemat
Zawsze te same trzy litery. Mówią tylko tyle: to, co następuje, jest zdecentralizowanym identyfikatorem.
web
Metoda
Reguły odnajdywania i aktualizowania dokumentu. To wybór o realnych konsekwencjach, bo decyduje, kto musi utrzymywać dostępność identyfikatora.
credenco.com
Identyfikator właściwy dla metody
Część, którą potrafi odczytać tylko ta metoda. Tutaj jest to nazwa domeny, gdzie indziej może to być wpis w rejestrze lub sam klucz publiczny.
Co dzieje się przy rozwiązywaniu
Sam z siebie DID nic nie robi. Jego wartość pojawia się w chwili, gdy ktoś go rozwiąże: zamieni ciąg znaków w niewielki dokument, który za nim stoi, wymieniający klucze publiczne używane przez podmiot i miejsca, w których można go osiągnąć.
1. Masz identyfikator
Przychodzi poświadczenie wskazujące stronę, która je podpisała. Na razie to ciąg znaków i niczego nie dowodzi.
2. Resolwer odczytuje metodę
Nazwa metody mówi resolwerowi, dokąd iść: pobrać plik z domeny, odczytać rejestr albo wydobyć klucz z samego identyfikatora.
3. Wraca dokument
Wymienia klucze publiczne, których podmiot używa teraz, oraz punkty końcowe, pod którymi można go osiągnąć.
4. Sprawdzasz podpis
Bez konta gdziekolwiek, bez klucza API i bez pytania o zgodę tego, kto prowadzi metodę.
Dlaczego nie nazwa domeny albo certyfikat
Sieć ma już sposoby, by powiedzieć, kim ktoś jest, więc uczciwe pytanie brzmi: co dodaje DID. Nazwa domeny mówi, dokąd wysłać żądanie, ale nic nie mówi o tym, jakie klucze należą do stojącej za nią strony. Certyfikat rzeczywiście wiąże klucz z nazwą i robi to dobrze, ale tylko dopóki potwierdza to urząd i tylko dla klucza, dla którego został wydany.
Poświadczenie ma kłopotliwy zwyczaj przeżywania obu. Dyplom za dwadzieścia lat wciąż jest dyplomem, długo po tym, jak klucz podpisujący został wymieniony, a obejmujący go certyfikat wygasł. Ponieważ DID oddziela nazwę od kluczy, wydawca może wymienić klucz bez zmiany identyfikatora i bez ponownego wydawania wszystkiego, co kiedykolwiek podpisał.
Klucze się zmieniają, nazwa nie
Rotacja przejętego klucza oznacza opublikowanie nowego dokumentu pod tym samym identyfikatorem. Każde odwołanie do wydawcy pozostaje ważne.
Sprawdzanie nie wymaga niczyjej zgody
Weryfikator rozwiązuje identyfikator i sprawdza matematykę. Nie trzeba zakładać konta u wydawcy ani liczyć się z limitem zapytań w cudzej usłudze.
Metody, które naprawdę spotkasz
Zarejestrowano znacznie ponad sto metod i prawie wszystkie można spokojnie pominąć. Trzy pokrywają niemal wszystko, z czym styka się organizacja w europejskim ekosystemie.
did:web
Dokument to plik w domenie, którą już kontrolujesz. Nic nowego do utrzymania, a próg wejścia bliski zeru, dlatego większość organizacji zaczyna tutaj. Haczyk jest taki, że kto kontroluje domenę, kontroluje identyfikator, i nic nie zachowuje tego, co dokument mówił wczoraj.
Przeczytaj definicjędid:webvh
Ten sam plik w domenie, plus dziennik tylko do dopisywania, obejmujący każdą wersję, jaką kiedykolwiek miał. Weryfikator widzi, że klucz, któremu dziś ufa, umieściła tam strona, która wczoraj miała ten identyfikator, a to właśnie luka, którą did:web pozostawia otwartą.
Przeczytaj definicjędid:key
Identyfikatorem jest zakodowany klucz publiczny. Nie ma nic do hostowania ani do pobierania, co czyni go idealnym dla tożsamości krótkotrwałych i jednorazowych. Oznacza to również, że klucza nigdy nie da się zmienić, więc to zły wybór dla czegoś, co ma przetrwać.
Pozostałe wymieniono w rejestrze metod DID prowadzonym przez W3C. Metodę, której tam nie ma albo którą wspiera tylko jeden produkt, traktuj jak zależność od tego produktu.
Czego DID nie mówi
W tym miejscu większość wyjaśnień o DID po cichu się kończy, a to właśnie ta część decyduje, czy program portfela zadziała. DID dowodzi ciągłości: strona, która podpisała to poświadczenie, ma ten sam klucz co strona, która podpisała tamto. Nie dowodzi niczego o tym, kim ta strona jest w świecie.
Każdy może utworzyć DID w kilka sekund, także ktoś podszywający się pod uczelnię. Ustalenie, że identyfikator naprawdę należy do akredytowanej instytucji, to osobna praca, którą wykonują lista zaufania, kwalifikowany certyfikat lub poświadczenie strony, której weryfikator już ufa. W eIDAS 2.0 dokładnie po to są listy zaufania i rejestracja stron ufających.
Czytane razem dają prosty obraz: DID niesie klucze, ramy zaufania niosą znaczenie, a weryfikator potrzebuje obu, zanim cokolwiek zaakceptuje.
Co to oznacza dla ciebie
Wydawca
Jeden identyfikator, który przetrwa każdą rotację klucza, dzięki czemu poświadczenie podpisane lata temu nadal da się sprawdzić, a przejęty klucz staje się zadaniem operacyjnym, a nie wycofaniem.
Weryfikator
Możesz sprawdzić podpis bez konta, umowy czy integracji z każdym wydawcą osobno. Nadal potrzebujesz listy zaufania, która mówi, które identyfikatory akceptować.
Posiadacz portfela
Nic do zarządzania. Identyfikatory znajdują się w twoich poświadczeniach, a portfel rozwiązuje je za ciebie, gdy pokazuje, kto co wydał.
Powiązane terminy
Najczęściej zadawane pytania
Czy do używania DID potrzebny jest blockchain?
Nie. To skojarzenie bierze się z metod zbudowanych jako pierwsze, a nie ze standardu. Specyfikacja nie mówi nic o tym, gdzie ma znajdować się dokument, a metody używane na co dzień w Europie, did:web i did:webvh, to pliki serwowane przez zwykły HTTPS z domeny, którą właściciel już posiada.
Dlaczego nie użyć po prostu nazwy domeny?
Domena mówi, gdzie coś znaleźć, a nie jakie klucze do niej należą, a certyfikat wiąże klucze z nazwą tak długo, jak potwierdza to urząd. DID daje obie rzeczy naraz i utrzymuje identyfikator stabilnym, podczas gdy klucze za nim się zmieniają, i to właśnie sprawia, że poświadczenie podpisane trzy lata temu nadal da się dziś sprawdzić.
Którą metodę powinniśmy wybrać?
Zacznij od tego, jak długo identyfikator ma przetrwać i kto może go zmieniać. Dla wydawcy, którego poświadczenia żyją dłużej niż klucze, did:webvh daje weryfikatorom historię potrzebną, by zaufać rotacji klucza. Do pilotaży wewnętrznych i krótkotrwałych tożsamości zwykle wystarczy did:web lub did:key, a późniejsza zmiana to zwykła migracja, a nie przebudowa.
Czy DID dowodzi, że organizacja jest tym, za kogo się podaje?
Nie, a zakładanie inaczej to najczęstszy błąd. DID dowodzi, że ten, kto podpisał dwie rzeczy, miał ten sam klucz prywatny. To, czy klucz należy do akredytowanej uczelni, czy do kogoś, kto zarejestrował przekonującą domenę, to osobne pytanie, na które odpowiadają lista zaufania, kwalifikowany certyfikat lub poświadczenie od strony, której już ufasz.
Źródła
Ta strona ma charakter informacyjny i nie stanowi porady prawnej. Wiążące brzmienie znajdziesz bezpośrednio w specyfikacji W3C.