Zdecentralizowana tożsamość i verifiable credentials

2026-08-12

Zdecentralizowana tożsamość rozdziela identyfikację, wystawianie, przechowywanie i weryfikację poświadczeń, aby jeden dostawca logowania nie był stałym strażnikiem każdej interakcji. Decentralized identifiers, czyli DID, pomagają udowodnić kontrolę nad identyfikatorem, a verifiable credentials, czyli VC, przenoszą twierdzenia podpisane przez wystawcę. Najlepsza mentalna mapa to nie magiczna tożsamość w portfelu, lecz przepływ zaufania: issuer składa twierdzenie, holder przechowuje i prezentuje, a verifier sprawdza dowód, status, kontekst i politykę.

Co oznacza decentralized identity explained

Fraza decentralized identity explained jest prostsza, gdy tożsamość podzieli się na warstwy. DID może być rozwiązywany przez DID method do dokumentu DID lub powiązanego zasobu. Dokument opisuje metody weryfikacji i usługi, lecz sam DID nie dowodzi wieku, wykształcenia, zatrudnienia ani statusu prawnego. VC to inny obiekt: twierdzenia wystawcy o subject, opakowane tak, aby verifier mógł sprawdzić autorstwo i integralność.

Decentralizacja nie znaczy anonimowości, braku śledzenia ani braku regulacji. Credential może być mocno związany z rzeczywistym proofingiem, a verifier nadal może stosować zasady kwalifikacji, fraudu, sankcji i dostępu. Trzeba zapytać, kto kontroluje identyfikator, kto tworzy claim, kto aktualizuje klucze i kto może polegać na wyniku.

DID, issuer, holder i verifier w jednym przepływie zaufania

Issuer składa twierdzenie i tworzy credential. Holder przechowuje go w wallet lub chronionym repozytorium i decyduje, kiedy go pokazać. Verifier otrzymuje credential albo verifiable presentation i sprawdza mechanizm zabezpieczenia, wystawcę, subject, okres ważności, status i cel biznesowy. Holder i subject często są tą samą osobą, ale rodzic może przechowywać credential dziecka, a organizacja credential urządzenia.

DID document pomaga verifierowi znaleźć publiczne materiały weryfikacyjne. Data Integrity proof może powiązać dowód z metodą i celem, ale poprawny podpis nie oznacza automatycznej akceptacji każdego claimu. Verifier nadal ocenia, czy issuer jest uznany, schema jest odpowiedni, presentation świeży, a zakres ujawnienia proporcjonalny.

Cykl życia VC od proofingu do prezentacji

Cykl życia zaczyna się przed kryptografią. Podczas rejestracji issuer ustala, jakie dowody są wystarczające i jaki poziom assurance jest potrzebny. Następnie tworzy claims o subject, dodaje typ i ważność, zabezpiecza credential, a wallet przechowuje kopię holdera. Przy presentation holder tworzy pokazanie dla konkretnego verifiera i może ujawnić tylko wybrane claims.

Weryfikacja jest sekwencją, nie jednym zielonym znakiem. Verifier sprawdza model danych, mechanizm zabezpieczenia, materiał weryfikacyjny, purpose proof, binding holdera, okres ważności i status. Credential może być autentyczny kryptograficznie, ale wygasły, odwołany, wystawiony przez niegodnego zaufania issuera lub niepasujący do celu. Odnowienie, zawieszenie, odwołanie i usunięcie są zdarzeniami cyklu życia, których blockchain nie zarządza automatycznie.

Klucze, DID documents i revocation to różne kontrole

Sekretny klucz jest uprawnieniem do podpisu. Klucz publiczny pozwala sprawdzić proof, ale nie utworzyć nowego ważnego proof. Issuer musi chronić klucze, określić relacje weryfikacyjne, monitorować kompromitację oraz mieć plan rotacji i odzyskania. Holder potrzebuje bezpiecznego urządzenia, backupu i sposobu odróżnienia prośby o presentation od prośby o sekret walleta.

Nie należy mieszać trzech zegarów: proof ma czas utworzenia i wygaśnięcia, credential ma validFrom i validUntil, a verification method może zostać obrócona lub odwołana po kompromitacji. Credential status jest osobnym sygnałem, że uprawnienie lub claim nie jest już aktualny. Trzeba więc sprawdzać mechanizm statusu, jego świeżość, dostępność, prywatność, integralność i governance.

Selective disclosure i granica minimalizacji danych

Selective disclosure pozwala holderowi wybrać, jakie dane udostępnić. Jeśli usługa musi wiedzieć tylko, czy ktoś przekroczył próg, pełna data urodzenia może być zbędna. Presentation może nieść abstrakcyjny claim albo zero-knowledge proof zamiast atrybutu źródłowego. Właściwości prywatności zależą od formatu credential, cryptosuite, walleta, żądania verifiera i możliwości powiązania powtórnych prezentacji.

DID i VC nie zapewniają prywatności automatycznie. Stabilny identyfikator, ponowny podpis, zapytanie statusu, telemetria portfela lub publiczny rejestr mogą tworzyć korelację. Minimalizacja danych zaczyna się od pytania: jaki najmniejszy claim jest potrzebny, na jak długo i komu? Danych osobowych nie należy bez potrzeby umieszczać w niezmiennym rejestrze publicznym; trzeba ograniczać retencję i chronić logi.

Gdzie blockchain pasuje do self sovereign identity blockchain

Fraza self sovereign identity blockchain może sugerować, że każdy rekord tożsamości musi być on-chain. DID Core tego nie wymaga. DID method może używać distributed ledger, bazy danych, zdecentralizowanego systemu plików albo innego zaufanego registry. Blockchain może służyć publicznemu rejestrowi operacji metody, metadanym zaufania do issuerów, rotacji kluczy lub kompaktowemu statusowi.

Blockchain wprowadza też koszty: publiczne rekordy można kopiować i korelować, trudno je usunąć, dostępność i governance się zmieniają, a hash nie dowodzi prawdziwości danych źródłowych. Dobra architektura przechowuje osobiste claims i duże dokumenty w chronionym storage oraz publikuje tylko niezbędne minimum.

Przepływ issuer, holder, verifier i registry dla DID oraz verifiable credentials

Compliance i praktyczna lista weryfikacji

Systemy tożsamości nadal mają obowiązki prawne i operacyjne. Zależnie od jurysdykcji potrzebne mogą być podstawa prawna, ograniczenie celu, minimalizacja danych, kontrola retencji, bezpieczeństwo, reakcja na incydenty, zasady transferów transgranicznych i audytowalny model zaufania. DID ani blockchain nie znoszą tych wymagań.

Przy integracji zapytaj: jaki DID method i registry są używane; któremu issuerowi ufamy i jak proofowano subject; jakie proof, cryptosuite i binding są wymagane; jak sprawdza się ważność, status, rotację, kompromitację i odzyskanie; czy żądanie nie obejmuje zbędnych danych; gdzie przechowuje się credential, logi i status oraz jak długo; jaka polityka lub jurysdykcja pozwala verifierowi polegać na claimie. Verifiable credentials blockchain opisuje możliwości infrastruktury, nie gwarancję prawdy, prywatności ani compliance.

Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w sierpniu 2026 r.; sprawdzaj aktualne oficjalne informacje.