Opisz, co sprawia, że identyfikatory DID różnią się od innych identyfikatorów
Jak wspomniano podczas spotkania W3C DID Working Group w Fukuoce w Japonii we wrześniu 2019 r., istniały cztery powody przypisane do finansowania rozwoju specyfikacji DID, która jest obecnie opublikowana jako zalecenie W3C dotyczące zdecentralizowanych identyfikatorów (DID) w wersji 1.0 Core architektury, modelu danych i reprezentacji.
- "Trwały (trwały) identyfikator" — element DID został zaprojektowany tak, aby był trwały. Trwałość oznacza, że "identyfikator DID nie może zostać usunięty ani uczyniony niesprawnym przez osobę trzecią bez zgody zarządcy identyfikatora".
- "Identyfikator rozpoznawalny" — DID jest identyfikatorem rozpoznawalnym, co oznacza, że można go wyszukać, aby odnaleźć coś skojarzonego z tym identyfikatorem DID, na przykład w celu odnalezienia metadanych. Informacje rozpoznawane przez DID to dokument DID.
- "Kryptograficznie weryfikowalny identyfikator" — DID to kryptograficznie weryfikowalny identyfikator, co oznacza, że jednostka, która kontroluje kontroler DID, może udowodnić kontrolę nad identyfikatorem przy użyciu kryptografii.
- "Identyfikator zdecentralizowany" — A DID jest identyfikatorem zdecentralizowanym. Oznacza to, że nie ma jednego urzędu rejestracji do tworzenia identyfikatorów DID i zarządzania nimi. DiD używają zdecentralizowanych sieci, nazywanych również weryfikowalnymi rejestrami danych, do rejestrowania i rejestrowania transakcji. Te rejestry mogą być rejestrami rozproszonymi, łańcuchami bloków, rozproszonymi systemami plików lub innym zaufanym magazynem danych. Istnieje wiele różnych typów weryfikowalnych rejestrów danych, których mogą używać DID. Zastosowane podejście zależy od metody DID.
Te cztery powody służą jako podstawowe właściwości DID. Chociaż istnieją identyfikatory, które mogą spełniać niektóre z tych właściwości, did jest pierwszym nowym typem identyfikatora, który spełnia wszystkie cztery z tych właściwości.
Możliwe do rozwiązania dokumenty DID i DID
Jeśli ogólnie myślisz o identyfikatorach, zapewniają one wartość, gdy są one używane w kontekście niektórych aplikacji, w których może dostarczyć pewne informacje lub włączyć interakcję lub komunikację. Na przykład adres URL, który jest typem identyfikatora, ma wartość tylko wtedy, gdy jest wprowadzany w przeglądarce internetowej i zwraca stronę internetową, która może być zużywana. W tym kontekście adres URL jest rozpoznawany jako strona internetowa. Ta sama koncepcja dotyczy DID, ale zamiast korzystania z przeglądarki internetowej i rozpoznawania strony internetowej, DID używa oprogramowania lub sprzętu, nazywanego resolverem, i zwraca dokument identyfikatora DID.
Dokument DID to publicznie dostępny zestaw danych, który opisuje jednostkę zidentyfikowaną przez DID, nazywaną podmiotem DID. Zalecenie W3C dotyczące zdecentralizowanych identyfikatorów (DID) w wersji 1.0 definiuje podstawowe właściwości dokumentu DID. Dostępne są następujące podstawowe właściwości:
- Metody weryfikacji — obejmuje to kryptograficzne klucze publiczne i skojarzone metadane. Na przykład kryptograficzny klucz publiczny może służyć jako metoda weryfikacji podpisu cyfrowego.
- Usługi — usługi są używane do komunikacji lub interakcji z podmiotami DID. Może to obejmować informacje, które podmiot chce anonsować. Przykłady z nich mogą obejmować weryfikowalne usługi repozytorium poświadczeń, usługi magazynu plików, usługi agenta i inne. Są one reprezentowane jako punkty końcowe usługi reprezentowane jako adres sieciowy, taki jak adres URL HTTP.
Są to tylko kilka przykładów danych, często zawartych w dokumencie DID. Dokumenty DID są publicznie dostępne dokumenty, które są używane przez aplikacje i usługi korzystające z DID (nie są przeznaczone do użycia przez użytkowników końcowych). Dokumenty DID zawierają informacje opisujące podmiot DID, takie jak klucz publiczny, punkty końcowe usługi i inne metadane, ale nie powinny zawierać danych osobowych dotyczących podmiotu. Najlepszym rozwiązaniem jest to, że jako publicznie dostępny dokument powinien zawierać minimalną ilość informacji potrzebnych do obsługi żądanej interakcji lub komunikacji.
DiD i kryptografia klucza publicznego
Aby zrozumieć, jak kontrolery DID mogą udowodnić kontrolę nad ich identyfikatorem, warto zrozumieć nieco kryptografię klucza publicznego.
DiD używają kryptografii asymetrycznej, nazywanej również kryptografią klucza publicznego. Kryptografia klucza publicznego używa pary kluczy publicznych i prywatnych, służy do zabezpieczania informacji za pośrednictwem szyfrowania oraz ustanawiania potwierdzenia autentyczności i zgody za pośrednictwem podpisów cyfrowych. Aby uzyskać bardziej szczegółowe informacje, zapoznaj się z opisem pojęć dotyczących kryptografii. W przypadku kryptografii klucza publicznego wyzwaniem jest sprawdzenie, czy klucz publiczny, który jest szeroko udostępniany, pochodzi od podmiotu, od którego oczekujesz, a nie oszusta. Innymi słowy, jak powiązać klucz publiczny z identyfikatorem reprezentującym jednostkę? W tradycyjnej kryptografii klucza publicznego zaufanie jest ustanawiane za pośrednictwem certyfikatów cyfrowych od zaufanych scentralizowanych urzędów certyfikacji (CA), które tworzą scentralizowaną infrastrukturę kluczy publicznych (PKI). Cechą DIDów jest jednak to, że są zdecentralizowane, więc nie chcesz mieć zależności od centrum certyfikacji. Identyfikatory DID rozwiązują ten problem, ponieważ ich identyfikator specyficzny dla danej metody jest uzyskiwany bezpośrednio lub pośrednio na podstawie informacji związanych z kluczem publicznym. Sprawia to, że DID z założenia jest powiązany z kluczem publicznym, bez żadnej scentralizowanej jednostki certyfikacyjnej. Wynikiem netto jest to, że jednostka, która kontroluje did, może udowodnić kontrolę nad tym identyfikatorem przy użyciu kryptografii. W ten sposób diD umożliwiają typ rozproszonej infrastruktury kluczy publicznych.
Podejście polegające na tym, że element DID jest oparty na kluczu publicznym, sugeruje, że w przypadku konieczności rotacji kluczy kryptograficznych w celu zapewnienia bezpieczeństwa należy zmienić wartość DID. Konieczność zmiany DID przeczy właściwości, że DID jest trwałe. Dokument DID rozwiązuje ten problem. Gdy klucze muszą ulec zmianie, kontroler DID może opublikować aktualizację do dokumentu DID, który zawiera nowy klucz publiczny, ale jest podpisany przy użyciu oryginalnego klucza prywatnego. Aktualizację dokumentu DID można uwierzytelnić, ponieważ oryginalny klucz publiczny można prześledzić z powrotem do oryginalnej wersji dokumentu DID. To podejście ustanawia łańcuch zaufania w ramach aktualizacji. Koncepcyjnie można to traktować jako analogię do systemu kontroli wersji oprogramowania, gdzie istnieje tylko jedna bieżąca wersja, ale można śledzić historię poprzednich wersji, aby zobaczyć, co zostało zaktualizowane.