Formularz został pomyślnie przesłany.
Więcej informacji można znaleźć w skrzynce pocztowej.
Zatrudnij nas
O nas
UsługiTechnologiePortfolio
Prawdopodobnie sam to widziałeś: prześlij GPT selfie, poproś o dokument w stylu paszportu, a w ciągu kilku minut otrzymasz coś, co może ominąć podstawowe kontrole wizualne. Dodajmy do tego klonowanie głosu i syntetyczne wideo, a “żywotność” zaczyna wyglądać jak teatr. To jest prawdziwy przełom w cyfrowej tożsamości w 2026. Sam model KYC oparty na zdjęciach zużywa się. Jeśli dowód tożsamości nadal zależy od tego, czy zdjęcia są trudne do podrobienia, budujesz na piasku.
Więc gdzie nas to zostawia? Dość oczywista zmiana: odejście od przechowywania danych tożsamości w kierunku kryptograficznej weryfikacji roszczeń. Zamiast pobierać skan paszportu i umieszczać go w innej bazie danych, system prosi o dowód: czy masz ukończone 18 lat, czy przeszedłeś KYC, czy jesteś zatwierdzony do tej transakcji i Czy możesz to udowodnić bez ujawniania czegokolwiek innego?
Ale co dokładnie się zmieniło? Dlaczego nagle mówimy o DID i weryfikowalnych referencjach?
Ponieważ w modelu opartym na DID zaufanie nie wynika z tego, jak coś wygląda. Pochodzi ono od tego, kto je podpisał i czy można udowodnić kontrolę nad nim. Selfie typu deepfake nie pomaga, jeśli weryfikator oczekuje poświadczenia podpisanego przez zaufanego wystawcę i powiązanego z kluczami kryptograficznymi. Nie próbujesz już “wyglądać prawdziwie”. Udowadniasz posiadanie ważnego, podpisanego roszczenia. Obrazy przestają być źródłem zaufania. Ich rolę przejmują podpisy.
I to właśnie jest celem tego przewodnika: Pokażę, jak działa ten model, dlaczego staje się poważną drogą naprzód i gdzie pasuje do niego blockchain.
Zdecentralizowany identyfikator (DID) to identyfikator oparty na URI, zaprojektowany do kontrolowania za pomocą kluczy kryptograficznych, a nie wydawany i zarządzany przez centralny katalog. W ramach Konsorcjum World Wide Web (W3C) Zgodnie ze standardem DID, identyfikator DID odnosi się do dokumentu DID, który informuje inne systemy o tym, jak zweryfikować podpisy, uwierzytelnić administratora lub wykryć punkty końcowe usługi powiązane z tym identyfikatorem. Mówiąc prostym językiem: DID nie jest Twoim profilem, paszportem ani rekordem konta. Jest to wskaźnik używany przez inne strony do weryfikacji, że kontrolujesz określony identyfikator i klucze za nim stojące.
W tym miejscu ludzie często spłaszczają wszystko do “tylko kolejnego ID”. Tak nie jest.
Adres e-mail jest tak naprawdę lokalizatorem w czyimś systemie. Jeśli dostawca zawiesi konto, identyfikator faktycznie zniknie. Numer SSN jest identyfikatorem nadawanym przez państwo, ale nie ma wbudowanej warstwy dowodu kryptograficznego; każdy, kto zdobędzie numer, może go odtworzyć. Tokeny OAuth znów są inne: nie są w ogóle identyfikatorami tożsamości, ale artefaktami delegowanego dostępu wydawanymi przez serwer autoryzacji, aby klient mógł wywołać chroniony zasób. Przydatne, tak. Przenośna warstwa tożsamości, nie.
DID działa inaczej. Ma ona zostać rozwiązana, a nie tylko wyszukana w bazie danych dostawcy. Kontrola leży po stronie podmiotu poprzez kluczowe materiały i zasady metody DID, a nie po stronie dostawcy poczty, platformy SaaS lub brokera tożsamości. To rozróżnienie ma znaczenie w praktyce. Jeśli tworzysz poświadczenia wielokrotnego użytku, logowanie oparte na portfelu lub przepływy weryfikatora, które powinny działać ponad granicami organizacyjnymi, identyfikator użytkownika specyficzny dla poczty e-mail lub aplikacji nie będzie miał wystarczającej semantyki zaufania. DID może.
Na poziomie składni model W3C jest prosty: DID składa się z trzech części: schematu DID, nazwy metody i identyfikatora specyficznego dla metody. Innymi słowy: did:method:identifier.
Weźmy na przykład did:web:example.com jako konkretny przykład.
Posiadając did:web, Rozdzielczość zazwyczaj mapuje dokument DID opublikowany w dobrze znanej lokalizacji HTTPS w tej domenie. Z czymś takim jak did:ethr, Rozdzielczość zależy od reguł metod powiązanych z Ethereum. Ta sama składnia DID, inny model zaufania i aktualizacji.
To kluczowa kwestia: sam ciąg DID jest tylko uchwytem. Metoda mówi, jak go rozwiązać. Dokument DID zawiera materiał weryfikacyjny. Po jego uzyskaniu można zweryfikować podpisy, uwierzytelnić posiadacza lub zweryfikować prezentację poświadczeń bez traktowania identyfikatora jako kolejnego wiersza w czyjejś tabeli użytkowników.
Do tej pory przyglądaliśmy się DID i weryfikowalnym poświadczeniom jako strukturom danych: identyfikatorom, dokumentom, podpisom. Ale to tylko część działającego systemu tożsamości. W rzeczywistych wdrożeniach trudniejszym problemem jest interakcja: w jaki sposób poświadczenia są wydawane, jak są prezentowane i jak weryfikatorzy decydują, czy im zaufać.
W systemach produkcyjnych, takich jak Portfel tożsamości cyfrowej UE lub Amerykańskie mobilne prawo jazdy (mDL) Piloci, portfele i weryfikatorzy nie tylko “rozwiązują DID” i na tym poprzestają. Komunikują się za pośrednictwem zdefiniowanych protokołów i formatów poświadczeń:
Ważnym rozróżnieniem jest to, że DID i weryfikowalne dane uwierzytelniające definiują co jest weryfikowany. Protokoły te definiują jak przemieszcza się między emitentem, posiadaczem i weryfikatorem w rzeczywistych systemach.
Bez tej warstwy identyfikatory DID pozostają mechanizmem rozwiązywania. Z nią stają się częścią działającej infrastruktury tożsamości.
Zdecentralizowana tożsamość to model, w którym identyfikatory, dane uwierzytelniające i przepływy weryfikacji nie są kontrolowane przez jednego dostawcę. Zamiast tego tożsamość jest zakotwiczona w kluczach kryptograficznych (za pośrednictwem DID), a roszczenia dotyczące tej tożsamości są wydawane i weryfikowane niezależnie od tego, gdzie są używane. Przydatny sposób myślenia o tym: Tożsamość przestaje być kontem przechowywanym w czyjejś bazie danych i staje się zestawem weryfikowalnych oświadczeń, które kontrolujesz i ponownie wykorzystujesz.
Porównajmy to z modelami, z którymi już pracujesz.
Scentralizowana tożsamość jest nadal domyślna wszędzie. Platforma jest właścicielem rekordu użytkownika, przechowuje dane i działa jako organ weryfikujący. Jeśli chcesz uzyskać dostęp, uwierzytelniasz się w tym systemie. Wszystko, w tym logowanie, uprawnienia, odzyskiwanie, przepływa przez niego.
Problemem nie jest tylko bezpieczeństwo (choć naruszenia są stałym problemem). Jest nim architektura:
Zdecentralizowana tożsamość odwraca tę sytuację. System nie musi przechowywać danych użytkownika. Musi jedynie weryfikować przedstawiane przez ciebie twierdzenia. Zaufanie zmienia się z “mamy twoje dane” na “możemy zweryfikować ten dowód kryptograficzny”.”
Tożsamość federacyjna (OAuth, SAML, OpenID Connect) próbowała rozwiązać problem fragmentacji poprzez wprowadzenie dostawców tożsamości, takich jak Google, Microsoft lub Apple, którzy ręczą za użytkowników w różnych usługach.
Działa to do pewnego momentu. Ale tożsamość federacyjna nadal ma centralną zależność:
Zdecentralizowana tożsamość usuwa tę zależność. Nie ma jednego emitenta, który musi być online w momencie weryfikacji. Poświadczenia są weryfikowane za pomocą podpisów, a nie wywołań API. Oznacza to:
Jest to bliższe temu, jak działają fizyczne dane uwierzytelniające: nie dzwonisz do biura paszportowego za każdym razem, gdy ktoś sprawdza twój dowód osobisty.
Terminy te są często mylone. SSI to bardziej filozofia projektowania: jednostka kontroluje swoją tożsamość, wybiera, co chce udostępniać i nie jest związana z żadnym dostawcą. Zdecentralizowana tożsamość to stos techniczny, który to umożliwia:
Można wdrożyć zdecentralizowane systemy tożsamości, które nie są w pełni “suwerenne” (na przykład portfele kontrolowane przez przedsiębiorstwo lub sieci z uprawnieniami). Można też mówić o SSI bez określania infrastruktury. W rzeczywistych systemach te dwa pojęcia są zwykle zbieżne, ale warto zachować jasne rozróżnienie podczas projektowania architektury.
Portfele są miejscem, w którym zdecentralizowana tożsamość spotyka się z rzeczywistymi ograniczeniami. Teoretycznie kontrola nad tożsamością wynika z kontrolowania kluczy kryptograficznych. W praktyce stwarza to problem, którego nie mają tradycyjne systemy: Co się stanie, gdy użytkownik utraci dostęp?
Jeśli DID jest powiązany z kluczem prywatnym i klucz ten zostanie utracony, nie ma domyślnego mechanizmu odzyskiwania. Nie ma przepływu “resetowania hasła”, chyba że system jest wyraźnie zaprojektowany do jego obsługi. Utrata klucza może oznaczać utratę kontroli nad identyfikatorem i powiązanymi z nim poświadczeniami.
Dlatego systemy produkcyjne wprowadzają modele odzyskiwania i przechowywania danych na wierzchu warstwy DID:
Kompromis jest nieunikniony: im więcej kontroli przechodzi na użytkownika, tym więcej odpowiedzialności przechodzi na zarządzanie kluczami. Dlatego większość rzeczywistych wdrożeń równoważy niezależność z użytecznością, zamiast przenosić pełną własność klucza całkowicie na użytkownika.
Warto zatrzymać się w tym miejscu, ponieważ tożsamość oparta na DID naprawdę działa dopiero po oddzieleniu jej podstawowych prymitywów. Identyfikator nie jest poświadczeniem, poświadczenie nie jest portfelem, a znacznik w łańcuchu nie jest samą tożsamością. Każda warstwa ma odrębną funkcję, a to oddzielenie jest tym, co sprawia, że model działa.
Te dwa komponenty stanowią rdzeń zdecentralizowanego modelu tożsamości. W niektórych systemach, zwłaszcza w środowiskach Web3, dodatkowe mechanizmy on-chain są wykorzystywane do wymuszania dostępu lub ról.
Żetony Soulbound (SBT) są jednym z przykładów. Są to niezbywalne tokeny powiązane z portfelem i używane do takich rzeczy jak bramkowanie KYC, akredytacja lub uprawnienia do protokołów. Inteligentne kontrakty mogą sprawdzać je bezpośrednio.
SBT nie są jednak częścią samego stosu tożsamości. Są opcjonalną warstwą egzekwowania zbudowaną na sygnałach tożsamości i wiążą się z kompromisami: publiczną widocznością w łańcuchu, ograniczoną przenośnością oraz wyzwaniami związanymi z unieważnianiem i odzyskiwaniem kluczy.
Tradycyjne systemy tożsamości zawodzą, ponieważ traktują zaufanie jako problem związany z przechowywaniem danych. Każda platforma gromadzi te same surowe dowody, takie jak skany paszportów, selfie i potwierdzenie adresu, a następnie przechowuje je we własnym obszarze zgodności. Tworzy to wszędzie ten sam bałagan: powielone dane osobowe, słaba przenośność, szerokie powierzchnie naruszeń i przepływy onboardingu, które stają się coraz cięższe, ale nie stają się dużo lepsze.
W tradycyjnym modelu systemy tożsamości kumulują ryzyko w czasie. Dostawcy KYC, giełdy, aplikacje fintech, platformy HR i platformy handlowe przechowują mniej więcej ten sam zestaw dowodów: identyfikator rządowy, skan twarzy, dane adresowe i metadane z samej sesji weryfikacji.
Z punktu widzenia implementacji, problem jest zwykle potęgowany przez mnożenie kopii. Te same dane użytkowników trafiają do systemów onboardingowych, narzędzi fraudowych, warstw CRM, narzędzi wsparcia, hurtowni danych i archiwów zgodności. Nawet jeśli główny stos weryfikacyjny jest zablokowany, otaczające go systemy często nie są utrzymywane w tym samym standardzie.
Tradycyjna tożsamość nie daje użytkownikowi prawie żadnej kontroli nad stanem weryfikacji. Platforma kontroluje rekord, politykę przechowywania, harmonogram ponownej weryfikacji i zasady ponownego wykorzystania.
Oznacza to, że użytkownik nie może przenosić zaufania z jednego kontekstu do drugiego. Zaliczenie KYC na platformie A nic nie daje na platformie B, ponieważ wynik weryfikacji jest uwięziony wewnątrz obwodu zgodności platformy A. Podstawowe twierdzenie może być nadal ważne, ale nie ma przenośnego artefaktu kryptograficznego, na którym mógłby polegać kolejny weryfikator.
W tym miejscu model zaczyna się załamywać ekonomicznie. Każdej platformie opłaca się odbudowywać zaufanie od zera, ponieważ tożsamość jest przechowywana jako dane wewnętrzne, a nie jako dowód wielokrotnego użytku.
Starszy model również domyślnie ujawnia zbyt wiele. Aby udowodnić wąski fakt, użytkownicy są zwykle proszeni o ujawnienie pełnego dokumentu źródłowego.
Jest to zły wzorzec prywatności, ale jest to również zły wzorzec systemowy. Gdy tożsamość zostanie powiązana z rejestrami opartymi na kontach i wielokrotnym przesyłaniem dokumentów, korelacja staje się łatwa między usługami, sesjami i kontrahentami. Weryfikator otrzymuje więcej danych niż potrzebuje, przechowuje więcej niż powinien i zwiększa odpowiedzialność bez proporcjonalnej poprawy jakości zaufania.
Jest to podatek operacyjny, który wszyscy już znają. Ta sama osoba wypełnia KYC w kółko, ponieważ każda platforma obsługuje swój własny stos zaufania i nie może wykorzystać weryfikacji jako przenośnego poświadczenia.
Jeśli pracowałeś nad tokenizacją, onboardingiem giełd lub regulowanymi przepływami portfeli, widziałeś, jak marnotrawstwo to się dzieje. Wąskim gardłem jest fakt, że zaufanie nie może przenosić się w sposób czysty między systemami, więc każda instytucja odbudowuje ten sam potok weryfikacji wokół własnej granicy bazy danych.
I nawet weryfikowalne poświadczenia same w sobie tego nie naprawiają. Ważny podpis dowodzi jedynie, że roszczenie zostało wydane przez określoną stronę. Nie dowodzi, że ta strona miała uprawnienia do wystawienia tego roszczenia. Jest to część, której wielu pilotów DID nie docenia. Weryfikatorzy muszą wiedzieć, którzy wystawcy są legalni, które schematy poświadczeń są akceptowane i na jakich zasadach można polegać na oświadczeniu.
W produkcji jest to obsługiwane przez struktury zaufania: eIDAS 2.0 listy zaufania w UE, Styl VICAL koordynacja zaufania dla mobilnych praw jazdy zgodnie z ISO 18013-5, Federacja OpenID łańcuchy zaufania i krajowe rejestry dostawców usług zaufania.
Bez tej warstwy nie można uzyskać tożsamości wielokrotnego użytku. Otrzymujesz poświadczenia, które weryfikują matematycznie, ale nic nie znaczą operacyjnie. Podpis jest ważny. Brakuje zaufania.
“Dlaczego zdecentralizowany model tożsamości działa? Ponieważ daje każdej ze stron mniej do przechowywania, mniej do ujawniania i mniej do ponownego sprawdzania. Użytkownik ponownie wykorzystuje zaufany dowód, weryfikator otrzymuje tylko to, czego potrzebuje, a platforma unika stania się kolejnym skarbcem PII. W Innowise oznacza to zwykle poświadczenia poza łańcuchem dla przenośności, poświadczenia w łańcuchu dla kontroli dostępu i selektywne ujawnianie dla kontroli wrażliwych na prywatność.”.
Ekspert Blockchain i analityk DeFi
Dość z definicjami. Ważna jest tutaj ścieżka weryfikacji: w jaki sposób DID staje się rozpoznawalny, w jaki sposób emitent wiąże z nim roszczenie i w jaki sposób to roszczenie jest później sprawdzane bez konieczności powrotu do centralnego rejestru. Przejdźmy przez przepływ od końca do końca.
DID staje się użyteczny dopiero wtedy, gdy można go rozwiązać. Jest generowany z kluczowym materiałem i publikowany zgodnie z metodą DID. Rozwiązanie zwraca dokument DID, który ujawnia klucze publiczne i metody weryfikacji używane przez innych do walidacji podpisów.
Gdy podmiot ma identyfikator DID, wystawca może dołączyć do niego podpisane oświadczenie jako weryfikowalne dane uwierzytelniające. Wystawca najpierw przeprowadza swoje kontrole, a następnie podpisuje poświadczenie, które wiąże oświadczenie z identyfikatorem podmiotu. To, co idzie naprzód, nie jest surowym dowodem, ale poświadczonym wynikiem.
Posiadacz przechowuje dane uwierzytelniające, zwykle w portfelu, i przedstawia je, gdy potrzebny jest dowód. W zależności od stosu, może to być pełne poświadczenie lub dowód pochodny. Chodzi o ponowne użycie: posiadacz przedstawia już zweryfikowane roszczenie zamiast ponownego uruchamiania onboardingu.
Weryfikator sprawdza podpis wystawcy, potwierdza powiązanie podmiotu i ocenia status poświadczeń, taki jak wygaśnięcie lub unieważnienie. W tym celu rozwiązuje DID wystawcy i pobiera klucz publiczny z dokumentu DID. Nie jest wymagane wywołanie zwrotne wystawcy.
DID staje się użyteczny dopiero wtedy, gdy można go rozwiązać. Jest generowany z kluczowym materiałem i publikowany zgodnie z metodą DID. Rozwiązanie zwraca dokument DID, który ujawnia klucze publiczne i metody weryfikacji używane przez innych do walidacji podpisów.
Gdy podmiot ma identyfikator DID, wystawca może dołączyć do niego podpisane oświadczenie jako weryfikowalne dane uwierzytelniające. Wystawca najpierw przeprowadza swoje kontrole, a następnie podpisuje poświadczenie, które wiąże oświadczenie z identyfikatorem podmiotu. To, co idzie naprzód, nie jest surowym dowodem, ale poświadczonym wynikiem.
Posiadacz przechowuje dane uwierzytelniające, zwykle w portfelu, i przedstawia je, gdy potrzebny jest dowód. W zależności od stosu, może to być pełne poświadczenie lub dowód pochodny. Chodzi o ponowne użycie: posiadacz przedstawia już zweryfikowane roszczenie zamiast ponownego uruchamiania onboardingu.
Weryfikator sprawdza podpis wystawcy, potwierdza powiązanie podmiotu i ocenia status poświadczeń, taki jak wygaśnięcie lub unieważnienie. W tym celu rozwiązuje DID wystawcy i pobiera klucz publiczny z dokumentu DID. Nie jest wymagane wywołanie zwrotne wystawcy.
Gdy przepływ jest już jasny, pojawiają się prawdziwe pytania projektowe: w jaki sposób identyfikatory są używane i jak klucze są zarządzane w czasie.
Publiczny DID jest stabilna i wykrywalna. Emitenci zazwyczaj używają go, ponieważ weryfikatorzy potrzebują spójnego sposobu rozwiązywania kluczy i walidacji podpisów. Z drugiej strony, DID parami jest generowany dla każdej relacji. Ten sam użytkownik przedstawia różne identyfikatory różnym weryfikatorom, co zapobiega korelacji między usługami.
Wybór ten nie jest kosmetyczny. Ponowne użycie pojedynczego identyfikatora DID w różnych usługach sprawia, że powiązanie jest trywialne. Pairwise DIDs przerywają to powiązanie na poziomie identyfikatora.
Następnie jest zarządzanie kluczami, z którym większość systemów boryka się w produkcji. DID jest tylko tak niezawodny, jak klucze, które za nim stoją, więc trzeba to zaplanować:
W praktyce na tym właśnie polega złożoność. Weryfikacja podpisu jest prosta. Trudniejszym problemem inżynieryjnym jest utrzymanie użyteczności, odzyskiwalności i nieskorelowania identyfikatorów w czasie.
Po przejściu przez przepływ, kolejnym pytaniem jest, w jaki sposób identyfikatory są faktycznie rozwiązywane i utrzymywane. Sprowadza się to do dwóch rzeczy: w Struktura dokumentu DID i w Metoda DID która definiuje sposób jej tworzenia, aktualizacji i rozwiązywania.
Dokument DID jest wynikiem rozdzielczości identyfikatora DID. Informuje weryfikatorów, które klucze, kontrolery i punkty końcowe usługi są autoryzowane dla tego identyfikatora. W praktyce nie jest to profil użytkownika. Jest to deskryptor weryfikacji.
Podstawowe pola, na których zwykle ci zależy:
Punkt implementacji klucza pozostaje taki sam: weryfikator rozwiązuje DID, wybiera odpowiednią metodę weryfikacji i sprawdza, czy klucz jest autoryzowany dla wykonywanej operacji.
Do tej pory rozmawialiśmy głównie o tożsamości jako o czymś, co kontroluje osoba. W systemach B2B kluczowym podmiotem jest często organizacja. Banki, dostawcy usług logistycznych i platformy RWA muszą weryfikować nie tylko kto podpisała coś, ale czy ta osoba była upoważniona do działania w imieniu spółki.
W tym miejscu organizacyjne DID stają się bardziej złożone. Kontrola jest rozproszona między role, systemy przechowywania, zasady podpisywania i zasady delegowania. Konfiguracja produkcyjna musi definiować, kto może podpisywać, co może podpisywać i jak to uprawnienie jest odwoływane.
W praktyce może to obejmować vLEI z GLEIF do identyfikacji podmiotów prawnych, portfele korporacyjne z Podpisywanie oparte na HSM, i łańcuchy możliwości autoryzacji, takie jak ZCAP-LD.
Dokumenty DID nie są statyczne. Klucze wygasają, urządzenia są gubione, infrastruktura podpisywania zmienia się, a klucze wystawcy wymagają rotacji. Poważny projekt DID musi sobie z tym poradzić bez naruszania istniejących danych uwierzytelniających.
Rotacja kluczy zwykle oznacza dodanie nowej metody weryfikacji, zmianę klucza autoryzowanego dla danej relacji i wycofanie starego klucza. Ale szczegół, który ma znaczenie to cel. Obracanie uwierzytelnianie wpływa na przepływy logowania lub odpowiedzi na wyzwanie. Obracanie klucza assertionMethod Klucz wpływa na wydawanie i weryfikację poświadczeń.
Ścieżka aktualizacji zależy od metody DID. Z did:web, aktualizujesz hostowany dokument DID. Z did:ethr, publikujesz transakcję w rejestrze. Najtrudniejszą częścią jest ciągłość: weryfikatorzy muszą wiedzieć, który klucz był ważny w momencie wydania poświadczenia i czy to poświadczenie zostało od tego czasu unieważnione, wygasło lub zostało zastąpione.
I to prowadzi nas do metod DID, ponieważ metoda definiuje dokładnie, jak tworzenie, rozwiązywanie, aktualizacje i dezaktywacja działają w rzeczywistym systemie.
Metoda DID jest warstwą implementacji za standardową składnią DID.
Określa zasady dotyczące:
Innymi słowy, składnia DID jest standardowa (did:method:identifier), ale metoda kształtuje cały model infrastruktury za DID.
Te trzy metody obejmują większość rzeczywistych przypadków użycia:
Teraz tabela przedstawia mechanikę. Trudniejszą częścią jest podjęcie decyzji, z którym trybem awarii można żyć: Zależność od DNS, koszt łańcucha, brak rotacji, możliwość publicznego audytu lub słabsza przenośność. Oto moje podejście do wyboru.
Przed dokonaniem wyboru należy zadać brzydkie pytania dotyczące produkcji:
W rzeczywistych wdrożeniach zwykle miesza się metody. Emitenci często używają did:web lub did:ethr; Posiadacze kart używają identyfikatorów parami lub identyfikatorów efemerycznych. Taki podział utrzymuje zaufanie emitenta na stabilnym poziomie, jednocześnie zmniejszając ryzyko korelacji dla użytkowników.
Wyjaśnijmy to wcześniej: nie potrzebujesz łańcucha bloków, aby wdrożyć zdecentralizowaną tożsamość. Specyfikacja World Wide Web Consortium DID Core tego nie wymaga, a wiele systemów produkcyjnych działa całkowicie poza łańcuchem.
Dlaczego więc blockchain w ogóle pojawia się w rozmowach? Ponieważ bardzo dobrze rozwiązuje jeden konkretny problem: Współdzielone zaufanie bez centralnego właściciela. Nie przechowywanie, nie sama tożsamość, ale koordynacja wokół kluczy, identyfikatorów i statusu.
W systemach opartych na DID, blockchain działa jako Publiczny, odporny na manipulacje rejestr. W zależności od metody można go użyć do:
Kluczowa kwestia: blockchain nie weryfikuje tożsamości. Zapewnia on wspólny punkt odniesienia na których weryfikatorzy mogą polegać, nie ufając pojedynczej stronie.
Na przykład z did:ethr, DID jest rozpoznawany na podstawie danych w łańcuchu. Weryfikator ufa stanowi łańcucha, a nie infrastrukturze emitenta.
To właśnie tutaj wiele implementacji DID idzie źle. Blockchain jest przydatny dla współdzielonego stanu, ale jest to okropne miejsce dla surowych danych tożsamości. W łańcuchu nie umieszcza się paszportów, danych biometrycznych, pełnych danych uwierzytelniających ani danych osobowych. Używasz łańcucha jako materiału dowodowego i danych koordynacyjnych, a następnie przechowujesz wrażliwe ładunki tożsamości poza łańcuchem.
Czysty podział zazwyczaj wygląda następująco:
On-chain:
Poza łańcuchem:
Powód jest prosty: prywatność i koszty. Łańcuchy bloków są publiczne, trwałe i kosztowne w aktualizacji. Dane tożsamości wymagają prywatności, usuwania, poprawiania i kontroli dostępu. Te dwie rzeczy nie idą ze sobą w parze.
Blockchain jest zwykle używany do kotwiczenia, a nie przechowywania. Użytkownik przekazuje do łańcucha niewielki dowód stanu, taki jak skrót dokumentu DID, aktualizacja rejestru wystawcy, odniesienie do statusu poświadczenia lub zdarzenie rotacji klucza, podczas gdy rzeczywiste dane tożsamości pozostają poza łańcuchem.
Daje to weryfikatorom trzy przydatne właściwości:
Kompromisem jest trwałość. Jeśli umieścisz niewłaściwe dane w łańcuchu, nie możesz ich łatwo usunąć. Właśnie dlatego dojrzałe systemy DID zakotwiczają hashe, referencje i przejścia stanów, a nie pełne poświadczenia, dokumenty lub dane osobowe.
Blockchain to niewłaściwe narzędzie gdy nie usuwa zależności zaufania. Jeśli ta sama organizacja kontroluje emitenta, weryfikatora i aplikację, umieszczenie stanu DID w łańcuchu zwykle dodaje tylko opłaty, opóźnienia i szum operacyjny.
Pomiń blockchain, gdy:
Dlatego did:web działa tak dobrze w przypadku wielu przepływów tożsamości w przedsiębiorstwach. Zachowuje model DID, ale wykorzystuje istniejącą infrastrukturę internetową zamiast wymuszać każdą aktualizację poprzez transakcję blockchain.
Używaj łańcucha bloków, gdy niezależne strony potrzebują współdzielonego stanu, który mogą zweryfikować bez ufania Twojemu serwerowi. W przeciwnym razie trzymaj to poza łańcuchem. Większa decentralizacja na papierze nie oznacza automatycznie lepszej architektury tożsamości.
W systemach takich jak EU Digital Identity Wallet lub mobilne prawa jazdy (ISO 18013-5), PKI zostało wybrane głównie dlatego, że publiczne sieci L1/L2 nie spełniają podstawowych wymagań dotyczących tożsamości: prywatności, suwerenności danych i kontroli regulacyjnej. Dane tożsamości nie mogą być publicznie replikowane, a jurysdykcje wymagają ścisłej kontroli nad tym, gdzie dane są przetwarzane i przechowywane.
Nowsze architektury wprowadzają jednak trzecią opcję: dozwolone systemy zk-L2. Łączą one w sobie:
Kluczową ideą jest rozdzielenie obaw na poziomie infrastruktury:
Pozwala to uniknąć podstawowego ograniczenia łańcuchów publicznych: ujawniania danych. Jednocześnie pozwala to uniknąć ograniczenia czystego PKI: polegania na zamkniętych hierarchiach zaufania bez możliwości wspólnego audytu.
Kolejną ważną właściwością jest Architektura wielodomenowa. Różne podmioty - ministerstwa, organy regulacyjne, banki lub regiony - mogą działać w oddzielnych strefach realizacji z własnymi granicami zgodności, jednocześnie przyczyniając się do wspólnego weryfikowalnego stanu za pomocą dowodów.
Rozszerza to przestrzeń projektową dla systemów tożsamości. Zamiast wybierać między scentralizowanym PKI a publicznym blockchainem, nowe wdrożenia mogą łączyć prywatność, zgodność i współdzielone zaufanie w jednym modelu.
Ok, więc do tej pory powinno być jasne, czym DID różnią się od standardowego KYC. Ale bardziej praktyczne pytanie brzmi: Co to właściwie dla mnie zmienia? Słuszne pytanie. Z tego, co widziałem w rzeczywistych implementacjach, wpływ zależy w dużej mierze od tego, po której stronie się znajdujesz, więc warto to rozbić.
Dla użytkowników największą zmianą jest kontrola nad kiedy i w jaki sposób tożsamość jest udostępniana.
W praktyce zmienia to tożsamość z czegoś, co ciągle przesyłasz ponownie, w coś, co obecny w razie potrzeby.
Dla organizacji zmiana dotyczy mniej UX, a bardziej ryzyko i struktura kosztów.
Operacyjnie zmienia się to w ten sposób, że przestajesz być administratorem danych, a zaczynasz być administratorem danych. weryfikator roszczeń.
Dla deweloperów wartość ta wynosi jak zbudowana jest logika tożsamości.
Z inżynieryjnego punktu widzenia, przejście od “zarządzania użytkownikami i sesjami” do weryfikacja dowodów i egzekwowanie warunków.
Porzućmy na chwilę teorię i po prostu przejdźmy przez to tak, jak w prawdziwym systemie. Co właściwie oznacza DID czuć się jak w praktyce? W którym momencie przestaje to być diagramem, a zaczyna być czymś, co można wysłać?
Zauważysz, że obiekty się zmieniają - dyplom, historia zatrudnienia, status KYC - ale przepływ prawie się nie zmienia.
Załóżmy, że właśnie ukończyłeś studia i musisz udowodnić swój dyplom przyszłemu pracodawcy. Zwykła ścieżka jest niezgrabna: prześlij plik PDF, załącz skan, może poczekaj, aż ktoś wyśle e-mail do rejestratora. To działa, ale ledwo. Cały proces zależy od ręcznego zaufania.
W przypadku poświadczeń opartych na DID, uniwersytet wydaje weryfikowalne poświadczenie po ukończeniu studiów. Znajduje się ono w portfelu, podpisane kluczem opublikowanym w uniwersyteckim dokumencie DID.
Miesiące później ubiegasz się o pracę. Pracodawca nie musi kontaktować się z uczelnią. Przedstawiasz dane uwierzytelniające, a system je sprawdza:
Na tym polega piękno tego modelu: uniwersytet podpisuje raz, można ponownie wykorzystać dowód, a każdy weryfikator może go sprawdzić niezależnie..
Jak bardzo można ufać CV? Tytuły są zawyżone. Daty stają się niewyraźne. “Kierowanie zespołem” może oznaczać wszystko, od zarządzania dziesięcioma osobami po prowadzenie standupów.
Teraz odwróćmy model. Kiedy odchodzisz z firmy, wydają ci poświadczenie:
Następnym razem, gdy ktoś zapyta: “Czy możesz udowodnić, że zrobiłeś X?”, nie wyjaśniaj. Prezentujesz. I nie, nie oznacza to ujawniania całej historii pracy za każdym razem. Dzięki odpowiedniemu formatowi poświadczeń posiadacz może udowodnić węższe roszczenie, takie jak:
...bez przekazywania pełnej historii zatrudnienia. To zupełnie inna postawa niż “wyślij nam całe CV i referencje”.”
Tutaj tożsamość wielokrotnego użytku staje się oczywista. Dokonujesz jednorazowej weryfikacji u zaufanego dostawcy: sprawdzasz paszport, przechodzisz kontrolę sankcji, potwierdzasz jurysdykcję. Dostawca wydaje poświadczenie KYC do portfela.
Następna platforma? Przedstawiasz dane uwierzytelniające zamiast ponownie przesyłać te same dokumenty. Platforma sprawdza:
Niektóre zespoły tokenizacyjne używają również żetony związane z duszą jako znaczniki KYC w łańcuchu: ten adres przeszedł wymaganą kontrolę. Dane tożsamości pozostają poza łańcuchem; łańcuch przenosi tylko sygnał kwalifikowalności.
Przydatne, ale tylko wtedy, gdy znacznik jest szeroki, odwoływalny i nie powoduje trwałego wycieku prywatności.
Opieka zdrowotna to obszar, w którym architektura DID wymaga krótkiej smyczy. Załóżmy, że klinika wystawia poświadczenie szczepienia, laboratorium podpisuje wynik badania krwi, a lekarz wystawia poświadczenie recepty. Przechowujesz je w portfelu, zamiast pozwalać każdemu rekordowi zniknąć w innym portalu.
Następnie zmieniasz lekarza. Czy czekasz, aż jeden system porozmawia z drugim? Gonić za plikami PDF? Nie. Udostępniasz konkretne dane uwierzytelniające, których potrzebuje nowy dostawca. Weryfikują wystawcę, podpis i status.
I żeby było jasne: nic z tego nie wymaga umieszczania danych medycznych w łańcuchu. Łańcuch jest dla identyfikatorów, kluczy, być może rejestrów statusu. Wrażliwe rzeczy pozostają poza łańcuchem. Jeśli ta granica nie jest przestrzegana, projekt jest zepsuty.
Odejdźmy teraz od ludzi. Weźmy do ręki produkt - powiedzmy butelkę oliwy z oliwek. Etykieta premium, ładne opakowanie. Czy to prawda? Zamiast ufać marce, dotknij telefonem tagu NFC. Za tym tagiem znajduje się DID powiązany z partią produktu.
Zwracane są podpisane dane:
Możesz dosłownie śledzić produkt od źródła do półki. Czy to rozwiązuje wszystko? Nie. Jeśli pierwszy wpis danych jest błędny, wszystko po nim po prostu zachowuje błąd. Ale przynajmniej teraz wiesz kto podpisał każdy krok. To duży postęp w stosunku do “zaufaj nam”.”
Rząd jest miejscem, w którym tożsamość w stylu DID opuszcza bańkę kryptowalutową. Jednym z głównych punktów odniesienia jest unijny portfel tożsamości cyfrowej w ramach eIDAS 2.0, zakrojonej na szeroką skalę inicjatywy mającej na celu zapewnienie portfeli obywatelom, mieszkańcom i firmom we wszystkich państwach członkowskich.
Szerszy krajobraz jest jednak bardziej zróżnicowany. Niektóre z największych i najbardziej dojrzałych systemów tożsamości cyfrowej na świecie nie są ściśle oparte na DID, ale podążają za podobnymi wzorcami w zakresie poświadczeń wielokrotnego użytku i danych kontrolowanych przez posiadacza:
Wspólna zmiana w tych systemach jest taka sama: przejście od scentralizowanych rejestrów tożsamości do dowodów wielokrotnego użytku, przedstawianych przez użytkownika. Jednocześnie ważne jest, aby rozdzielić modele zaufania. Systemy takie jak eIDAS opierają się na sfederowanym PKI i listach usług zaufania, podczas gdy systemy oparte na DID opierają się na identyfikatorach kryptograficznych i weryfikowalnych poświadczeniach. W praktyce modele te często współistnieją, a nie zastępują się nawzajem.
Jak dotąd wszystko działa dobrze wewnątrz jednego systemu. Ale co się dzieje, gdy poświadczenia przekraczają granice systemu? Tutaj sprawy stają się bardziej rygorystyczne. Potrzebujesz wspólnych standardów, aby dane miały sens wszędzie, i potrzebujesz zarządzania, aby weryfikatorzy wiedzieli, którym wystawcom zaufać. Oto standardy i warstwy zarządzania, które mają największe znaczenie.
Standardy sprawiają, że dane uwierzytelniające są interoperacyjne. Zarządzanie sprawia, że są one akceptowalne. Bez standardów nic nie jest parsowane. Bez zarządzania nic nie jest zaufane. Prawdziwe systemy działają tylko wtedy, gdy obie warstwy są zdefiniowane razem.
Standardy mówią, jak powinien zachowywać się system DID. Produkcja mówi, gdzie robi się bałagan. Obecnie większość zagrożeń nie wynika ze składni DID lub samych algorytmów podpisu. Pojawiają się one wokół portfeli, odzyskiwania kluczy, unieważniania, interoperacyjności i tego, czy wystarczająca liczba emitentów i weryfikatorów faktycznie zgadza się na korzystanie z tego samego modelu zaufania.
W systemach DID tożsamość zależy od kontroli kluczy. To potężne, ale bezlitosne. Jeśli użytkownik zgubi klucz, jego odzyskanie nie jest automatyczne. Jeśli atakujący zdobędzie klucz, może podszyć się pod jego posiadacza. Dlatego poważne implementacje rzadko polegają wyłącznie na surowej frazie seed. Zwykle potrzebują MPC, odzyskiwania społecznościowego, kluczy sprzętowych lub jakiegoś hybrydowego modelu przechowywania.
Poświadczenia się starzeją. KYC wygasa, pracownicy odchodzą, licencje zostają zawieszone. Tak więc weryfikacja nie może zatrzymać się na “czy podpis jest ważny?”. Weryfikator sprawdza status poświadczeń w momencie ich użycia. Zwykle oznacza to listy statusów, rejestry unieważnień lub krótkoterminowe poświadczenia. Jeśli pominiemy tę część, stare dane uwierzytelniające nadal będą wyglądać na ważne.
Standardy pomagają, ale nie sprawiają, że każdy portfel, emitent i weryfikator jest kompatybilny. Jeden stos może używać poświadczeń JSON-LD, inny może preferować metody JWT. Metody DID. Protokoły prezentacji są różne. Więc tak, ekosystem zmierza w kierunku interoperacyjności, ale rzeczywiste projekty nadal wymagają pracy integracyjnej i ścisłego wyboru profilu.
Najtrudniejszą częścią jest koordynacja. System DID potrzebuje emitentów, którym ludzie ufają, weryfikatorów chętnych do akceptowania danych uwierzytelniających, użytkowników zdolnych do zarządzania portfelami i zasad zarządzania, które wszyscy rozumieją. Dopóki te elementy się nie zgrają, adopcja odbywa się w kieszeniach: najpierw regulowane finanse, tokenizacja, dane uwierzytelniające pracowników, identyfikatory rządowe i zamknięte ekosystemy.
Większość dzisiejszych systemów DID opiera się na kryptografii krzywych eliptycznych: Ed25519, secp256k1 lub P-256. Schematy te są szeroko stosowane, ale nie są one bezpieczne post-kwantowo. Wystarczająco potężny komputer kwantowy mógłby je złamać za pomocą algorytmu Shora, czyniąc fałszowanie podpisów realnym długoterminowym ryzykiem.
Ma to znaczenie, ponieważ poświadczenia tożsamości często żyją przez lata. Dyplomy, licencje i poświadczenia prawne wydane dzisiaj mogą nadal wymagać weryfikacji długo po tym, jak kryptografia za nimi się zestarzeje.
Standardy już zmierzają w tym kierunku. NIST sfinalizował schematy podpisów post-kwantowych, takie jak ML-DSA (Dilithium) i SLH-DSA (SPHINCS+), podczas gdy ekosystem DID/VC bada podpisy hybrydowe i krypto-zwinność.
Systemy DID powinny obsługiwać wiele metod weryfikacji, nowe zestawy podpisów i jasne ścieżki rotacji kluczy od pierwszego dnia. Podpisy postkwantowe są znacznie większe niż podpisy Ed25519 lub ECDSA, co wpływa na prezentacje QR, rejestry i mechanizmy statusu w łańcuchu. Jednak w przypadku długotrwałej tożsamości rządowej i korporacyjnej krypto-zwinność jest koniecznością.
Najczęściej spotykanym błędem jest traktowanie DID jako czegoś, co “dodaje się” do istniejącego stosu tożsamości. W praktyce jest to zmiana sposobu modelowania zaufania, przepływu danych i odpowiedzialności. Elementy techniczne rzadko są najtrudniejsze. Większość projektów kończy się sukcesem lub porażką dzięki koordynacji, zarządzaniu i integracji.
Zacznij od zidentyfikowania miejsc, w których przechowujesz dane tożsamości, aby później je zweryfikować: Status KYC, wiek, zatrudnienie, licencje, akredytacje i prawa dostępu. Celem jest przechowywanie mniejszej ilości nieprzetworzonych danych i weryfikowanie większej liczby podpisanych oświadczeń. Zmniejsza to odpowiedzialność, upraszcza zgodność z przepisami i umożliwia przenoszenie tożsamości między systemami.
Przed wyborem narzędzi należy konkretnie zdefiniować model zaufania. W rzeczywistych projektach zazwyczaj skutkuje to:
Bez tego uzyskuje się poświadczenia, które weryfikują się poprawnie, ale nie są akceptowane przez weryfikatorów.
Teraz wybierz stos techniczny. Wybierz metodę DID, format poświadczeń, przepływ portfela i model odwołania. did:web zwykle pasuje do przepływów korporacyjnych i SaaS. did:ethr pasuje do egzekwowania inteligentnych kontraktów i tożsamości w łańcuchu. did:key pasuje do identyfikatorów krótkotrwałych lub lokalnych.
Nie wybieraj najbardziej “zdecentralizowanej” opcji. Wybierz tę, która pasuje do twojej granicy zaufania.
Nie zaczynaj od “tożsamości dla wszystkiego”. Zacznij od jednego przepływu, w którym ból jest wyraźny. Dobrymi pilotami są:
Ścisły zakres: jeden typ poświadczeń, jeden lub dwóch wystawców, jeden przepływ weryfikatora, jasne zasady unieważniania. Unikaj rozpoczynania od:
Udowodnij przepływ od końca do końca, a następnie rozwiń.
Po przejściu z fazy pilotażowej do produkcyjnej, wydawanie poświadczeń to tylko połowa problemu. Trudniejszą kwestią jest to, co się stanie, gdy poświadczenie nie będzie już godne zaufania: kontrola KYC wygaśnie, pracownik odejdzie, licencja zostanie zawieszona lub portfel zostanie naruszony.
Nie ma jednego standardowego podejścia, a każdy model wiąże się z pewnymi kompromisami:
Różne ekosystemy przyjmują różne podejścia. Na przykład mobilne prawa jazdy ISO 18013-5 opierają się na walidacji wydawcy i listach zaufania, a nie na unieważnianiu w stylu W3C. Bez jasnej strategii unieważniania, model “poświadczeń wielokrotnego użytku” załamuje się. Zaatakowane dane uwierzytelniające mogą być nadal prezentowane, chyba że ich status jest aktywnie sprawdzany.
Typowy projekt DID/VC przebiega etapami. Pilotaż zwykle trwa 3-4 miesiące i weryfikuje jeden przypadek użycia od końca do końca, zazwyczaj w zakresie $150K–$300K, w zależności od zakresu. Wdrożenie produkcyjne trwa 9-12 miesięcy i rozszerza się na wielu emitentów, weryfikatorów i typy poświadczeń, zwykle od $800K do $2M+, w zależności od złożoności integracji i wymogów zgodności.
W skład typowego zespołu wchodzą:
W praktyce złożoność rzadko dotyczy kryptografii. Chodzi o integrację, zarządzanie i doświadczenie użytkownika.
Aby to podsumować, pomniejszmy nieco. Tożsamość oparta na DID nie jest gotowym stosem. Wciąż ewoluuje, głównie wokół systemów dowodowych, infrastruktury portfela, warstw interoperacyjności i integracji regulacyjnej. Z tego, co widzę w rzeczywistych implementacjach, kilka kierunków staje się jasnych.
Tożsamość wielokrotnego użytku jest oczywistym celem, ale wąskim gardłem nie jest weryfikacja podpisu. Ta część już działa. Trudniejszą częścią jest zaufanie emitenta, schematy poświadczeń i zasady akceptacji.
W przyszłości poświadczenie KYC wydane w jednym regulowanym środowisku powinno być możliwe do ponownego wykorzystania na giełdach, platformach tokenizacyjnych, produktach pożyczkowych i zgodnych interfejsach DeFi, pod warunkiem, że DID wystawcy jest rozpoznawalny, schemat jest zrozumiały, a weryfikator akceptuje wystawcę w ramach swoich ram zaufania. Na tym polega prawdziwa praca: nie udowadnianie, że podpis jest ważny, ale uzgadnianie, co faktycznie oznacza podpisane roszczenie.
Obecnie wiele systemów nadal ujawnia atrybuty. Przyszłość to udowadnianie warunków. Zamiast pokazywać datę urodzenia, udowadniasz, że masz ukończone 18 lat. Zamiast ujawniać pełne dane KYC, udowadniasz, że przeszedłeś określoną politykę zgodności. Zamiast udostępniać pole jurysdykcji, udowadniasz, że kwalifikujesz się do transakcji.
Technicznie rzecz biorąc, wskazuje to na podpisy BBS+ dla selektywnego ujawniania i zk-SNARK lub zk-STARK dla dowodów predykatów. Weryfikator sprawdza dowód pod kątem kluczy publicznych kontrolowanych przez emitenta, podczas gdy podstawowe dane osobowe pozostają ukryte. Zmienia to model prywatności z “udostępniaj mniej danych” na “nie udostępniaj danych w ogóle, gdy dowód jest wystarczający”.”
Interoperacyjność zadecyduje o tym, czy zdecentralizowana tożsamość pozostanie rozdrobniona, czy też stanie się użyteczną infrastrukturą.
Słabe punkty są nadal znane: Poświadczenia JSON-LD vs JWT, różne metody DID, różne protokoły portfela, różne przepływy prezentacji. Dlatego systemy produkcyjne coraz częściej definiują ścisłe profile: zatwierdzone formaty poświadczeń, obsługiwane metody DID, zaufani emitenci i akceptowane protokoły prezentacji.
Z biegiem czasu spodziewam się większej konwergencji wokół przepływów między portfelem a weryfikatorem, wymiany prezentacji i rejestrów zaufania. Bez tego każdy projekt DID staje się kolejną wyspą tożsamości. Dzięki temu poświadczenia mogą być przenoszone między platformami bez konieczności każdorazowej niestandardowej integracji.
Regulacje zmieniają zdecentralizowaną tożsamość z opcji technicznej w infrastrukturę publiczną.
W UE, eIDAS 2.0 i Portfel Tożsamości Cyfrowej UE są wielkim sygnałem. Państwa członkowskie są zobowiązane do zapewnienia infrastruktury portfela z danymi uwierzytelniającymi dla atrybutów tożsamości, licencji, kwalifikacji i przypadków użycia w sektorze publiczno-prywatnym. Tworzy to regulowaną warstwę poświadczeń w całej Europie.
W Stanach Zjednoczonych Narodowy Instytut Standardów i Technologii aktualizuje wytyczne dotyczące tożsamości cyfrowej (np. NIST 800-63), aby uwzględnić poświadczenia kryptograficzne, poziomy pewności i weryfikację z zachowaniem prywatności. Stany Zjednoczone prawdopodobnie utrzymają model bardziej rynkowy, podczas gdy UE będzie dążyć do skoordynowanych ram portfela.
Więc dokąd to zmierza? W kierunku mniejszej liczby przesyłanych dokumentów, większej liczby danych uwierzytelniających wielokrotnego użytku, większej liczby lokalnych kontroli kryptograficznych i bardziej selektywnego ujawniania. Zwycięzcami nie będą systemy, które przechowują najwięcej danych dotyczących tożsamości. Będą to te, które będą w stanie zweryfikować właściwe roszczenie przy jak najmniejszej ekspozycji.
Zdecentralizowany identyfikator jest unikalnym, rozpoznawalnym identyfikatorem, który wskazuje na dokument DID zawierający klucze publiczne i metody weryfikacji. Pozwala on podmiotom na udowodnienie tożsamości lub kontroli bez polegania na centralnym organie. W praktyce zastępuje on wyszukiwanie w bazie danych weryfikacją kryptograficzną.
Identyfikator DID odnosi się do dokumentu DID z kluczami publicznymi. Wystawca podpisuje poświadczenie, posiadacz je przechowuje, a weryfikator sprawdza podpis i status przy użyciu DID wystawcy. Nie jest wymagane bezpośrednie połączenie z wystawcą. Dzięki temu weryfikacja jest przenośna i niezależna od jakiegokolwiek pojedynczego systemu.
Zdecentralizowana tożsamość to ogólny model wydawania i weryfikowania roszczeń bez centralnego przechowywania. DID jest tylko jednym z elementów tego modelu. Działa jako warstwa identyfikatora używana do rozwiązywania kluczy i weryfikacji podpisów. Bez identyfikatorów DID system nie miałby spójnego sposobu lokalizowania i ufania materiałom weryfikacyjnym.
Niekoniecznie. Niektóre metody DID wykorzystują łańcuchy bloków do rozdzielczości lub kotwiczenia, ale wiele z nich, takich jak did:web, opierają się na standardowej infrastrukturze internetowej. Sam DID jest referencją, a nie rekordem danych. To, co może być przechowywane w łańcuchu, to klucze, skróty lub odniesienia do statusu, a nie dane tożsamości.
Są one wykorzystywane do łączenia tożsamości z kluczami kryptograficznymi, umożliwiają weryfikowalne poświadczenia, wspierają wielokrotnego użytku KYC, weryfikację siły roboczej, cyfrowe identyfikatory i kontrolę dostępu zarówno w systemach internetowych, jak i opartych na blockchain. Ich rolą jest zapewnienie przenośności weryfikacji tożsamości w różnych systemach.
Użytkownik generuje parę kluczy i tworzy identyfikator DID zgodnie z wybraną metodą. Następnie publikujesz lub rejestrujesz go, aby można go było rozwiązać w dokumencie DID. Dokładny proces zależy od metody DID (np. internetowej, blockchain lub opartej na kluczach). Metoda określa, w jaki sposób DID jest zakotwiczony, aktualizowany i rozwiązywany.
Ekspert Blockchain i analityk DeFi
Andrew przekłada zdecentralizowane koncepcje na bezpieczne, funkcjonalne narzędzia finansowe. Porusza się po niestabilnym krajobrazie DeFi, aby budować skalowalne infrastruktury blockchain, które odnoszą się do rzeczywistej użyteczności, wykraczając poza modne hasła, aby zapewnić wartość techniczną.
