did:web wyjaśniony
Każdy cyfrowy credential jest przez kogoś podpisany, a weryfikator musi móc sprawdzić, kto to jest i jakich kluczy używa dzisiaj. did:web odpowiada na to elementem infrastruktury, który niemal każda organizacja już posiada: własną nazwą domeny. Identyfikator mówi, o którą domenę zapytać, odpowiedzią jest zwykły plik serwowany po HTTPS, i nic więcej nie musi istnieć, żeby to działało.
Czym naprawdę jest did:web
DID to trwały identyfikator, który każdy może sprawdzić, by odnaleźć klucze publiczne jego posiadacza. Metoda DID to reguła opisująca to wyszukiwanie, a metod są dziesiątki. Jedne zapisują wpis w blockchainie, inne w sieci zbudowanej specjalnie w tym celu, i każda zmusza weryfikatora do nauczenia się, jak działa właśnie ten system.
did:web idzie w przeciwną stronę. Wyszukiwanie to żądanie HTTPS do domeny wskazanej w identyfikatorze, a wpisem jest plik JSON, który właściciel domeny publikuje i edytuje jak każdą inną stronę swojej witryny. Nie ma sieci, do której trzeba dołączyć, rejestru, do którego trzeba pisać, ani opłaty do zapłacenia.
Dlatego pojawia się tak wcześnie niemal w każdym projekcie. Zespół, który potrafi wgrać plik na swój serwer WWW, może wydawać i weryfikować credentiale jeszcze tego samego popołudnia, a otrzymany identyfikator to prawdziwy DID, który przyjmie każdy zgodny portfel lub weryfikator, a nie tymczasowe rozwiązanie do późniejszej wymiany.
Jak identyfikator staje się adresem URL
Odwzorowanie jest mechaniczne i o to właśnie chodzi. Sama domena prowadzi do pliku w katalogu well-known, którego witryny używają już do metadanych czytelnych maszynowo. Jeśli po domenie dodasz segmenty rozdzielone dwukropkami, staną się one segmentami ścieżki, dzięki czemu jedna organizacja może opublikować osobny identyfikator dla działu, środowiska czy usługi wydawania, nie rejestrując niczego nowego.
Dwa szczegóły łatwo przeoczyć. Numer portu wymaga zakodowania dwukropka w postaci procentowej, bo zwykły dwukropek rozdziela już części identyfikatora. A plik musi być serwowany po HTTPS z certyfikatem, który się waliduje, bo transport jest jedyną rzeczą stojącą między weryfikatorem a sfałszowaną odpowiedzią.
Identyfikator, który ktoś ci podaje
did:web:example.com:issuer:euAdres HTTPS, na który się odwzorowuje, bez żadnej usługi wyszukiwania po drodze
https://example.com/issuer/eu/did.jsonZwrócony DID document, zawierający klucze i punkty końcowe
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Dlaczego organizacje to wybierają
Pierwszym powodem jest rozpoznawalność. Weryfikator, który widzi identyfikator wskazujący na domenę firmy, może w najprostszy możliwy sposób sprawdzić, że nazwa na credentialu zgadza się z nazwą na stronie. Nikomu nie trzeba najpierw tłumaczyć zapytania do rejestru ani łańcucha certyfikatów, żeby to trafiło.
Drugim jest to, że utrzymanie nic nie kosztuje. Dokument stoi za tym samym hostingiem, tym samym monitoringiem i tym samym procesem zmian co reszta witryny. Nie ma osobnego systemu do finansowania, utrzymywania w dostępności czy tłumaczenia audytorowi, a rotacja klucza to wdrożenie, a nie transakcja.
Trzecim jest przenośność. Ponieważ każda biblioteka portfela i weryfikatora ją obsługuje, did:web to metoda, która najpewniej zadziała wobec partnera, z którym nigdy wcześniej nie integrowałeś. To czyni ją naturalnym wyborem dla pilotaży, środowisk testowych i tych wydarzeń interoperacyjnych, na których spotykają się europejskie wdrożenia portfeli.
Gdzie did:web się kończy
Wszystko, co daje ta metoda, opiera się na domenie. Kto kontroluje rejestrację, serwery nazw i certyfikat, ten kontroluje identyfikator, więc przeterminowane odnowienie, przejęte konto DNS albo błędnie wystawiony certyfikat wystarczą, by mówić w twoim imieniu. Pod spodem nie ma drugiego podpisu, na którym można się oprzeć.
Nie ma też pamięci. Weryfikator widzi dokument taki, jaki jest w tej chwili, i nie ma jak się dowiedzieć, co było w nim w zeszłym tygodniu, więc podmienionego klucza nie da się odróżnić od rotowanego. did:webvh istnieje dokładnie po to: ten sam hosting, plus podpisany, wyłącznie dopisywalny dziennik każdej zmiany, dzięki któremu weryfikator może prześledzić historię od pierwszego wpisu do stanu obecnego.
I nie jest to weryfikacja tożsamości. Opublikowanie dokumentu pod domeną dowodzi kontroli nad tą domeną i niczego więcej. Kiedy weryfikator musi wiedzieć, że osoba prawna jest tym, za kogo się podaje, ta pewność pochodzi z Trusted List, kwalifikowanego certyfikatu albo zbudowanego w tym celu Trust Framework, a metoda DID niesie jedynie leżące pod spodem klucze.
Co to oznacza dla ciebie
Wydawca
Traktuj dokument jak infrastrukturę produkcyjną od pierwszego dnia. Obejmij go kontrolą zmian, monitoruj, czy adres odpowiada i czy certyfikat jest ważny, i pozostaw wycofany klucz na liście do weryfikacji tak długo, jak cokolwiek nim podpisanego pozostaje w użyciu.
Strona ufająca
Pobranie dokumentu to nie to samo co zaufanie mu. Osobno zdecyduj, które domeny akceptujesz, odrzucaj wszystko, czego certyfikat się nie waliduje, i buforuj ostrożnie: nieaktualna kopia utrzymuje przy życiu odwołany klucz, a brakująca kładzie twoją usługę razem z drugą stroną.
Posiadacz portfela
Domena w identyfikatorze wydawcy jest warta spojrzenia. To jedyna część credentialu, którą odczytasz bez żadnych narzędzi, a nazwa niezgodna z oczekiwaną organizacją jest powodem, by się zatrzymać, a nie iść dalej.
Powiązane pojęcia
Najczęściej zadawane pytania
Czy do rozwiązania identyfikatora did:web potrzebne jest specjalne oprogramowanie?
Nie. Identyfikator to przepis na zbudowanie adresu URL, a pobranie tego adresu po HTTPS zwraca dokument. Poradzi sobie z tym dowolny klient HTTP i właśnie dlatego did:web jest zwykle pierwszą metodą, którą zespół uruchamia. Ogólną bibliotekę rozwiązującą i tak warto stosować na produkcji, bo jednolicie stosuje reguły kodowania i kontrole dokumentu, zamiast zostawiać je każdemu wywołującemu.
Czy did:web jest mniej wiarygodny, skoro nie ma blockchaina?
Jest wiarygodny inaczej. Metoda oparta na rozproszonym rejestrze rozkłada wpis na wiele stron, tak by żadna nie mogła go po cichu przepisać. did:web składa tę odpowiedzialność na właściciela domeny i na urzędy certyfikacji stojące za jego TLS. Dla organizacji, której nazwa i witryna są już tym, co rozpoznają klienci, to często najuczciwsze miejsce dla tego zaufania, o ile wszyscy rozumieją, że domena jest słabym punktem.
Co dzieje się z już wydanymi credentialami, gdy klucze się zmieniają?
Weryfikator pobiera dokument w takiej postaci, w jakiej jest teraz, więc credential podpisany kluczem, który w międzyczasie usunięto, przestaje się weryfikować. Zostaw wycofany klucz w dokumencie, oznaczony tak, by mógł weryfikować, ale już nie podpisywać, co najmniej tak długo, jak ważne pozostają podpisane nim credentiale. Jeśli weryfikator musi umieć wykazać, który klucz obowiązywał w danym dniu, to właśnie wtedy did:webvh zasługuje na swoją dodatkową złożoność.
Źródła
Ta strona ma charakter informacyjny i nie stanowi porady prawnej. Po wiążące wskazówki sięgnij bezpośrednio do specyfikacji W3C.