did:web explicat
Orice credential digital este semnat de cineva, iar un verificator trebuie să poată afla cine este și ce chei folosește astăzi. did:web răspunde la asta cu infrastructura pe care aproape orice organizație o are deja: propriul nume de domeniu. Identificatorul vă spune ce domeniu să întrebați, răspunsul este un fișier obișnuit servit prin HTTPS, și nimic altceva nu trebuie să existe pentru ca lucrurile să funcționeze.
Ce este de fapt did:web
Un DID este un identificator permanent pe care oricine îl poate căuta pentru a găsi cheile publice ale celui care îl deține. O metodă DID este regula pentru acea căutare și există zeci dintre ele. Unele scriu înregistrarea într-un blockchain, altele într-o rețea construită special, iar fiecare obligă un verificator să învețe cum funcționează exact acel sistem.
did:web merge pe drumul opus. Căutarea este o cerere HTTPS către domeniul numit în identificator, iar înregistrarea este un fișier JSON pe care proprietarul domeniului îl publică și îl editează ca pe orice altă pagină a site-ului său. Nu există rețea la care să aderați, registru în care să scrieți sau taxă de plătit.
De aceea apare atât de devreme în aproape orice proiect. O echipă care poate urca un fișier pe serverul său web poate emite și verifica credentiale chiar în acea după-amiază, iar identificatorul obținut este un DID real, acceptat de orice portofel sau verificator conform, nu o soluție provizorie de înlocuit mai târziu.
Cum devine identificatorul o adresă URL
Corespondența este mecanică și tocmai asta este ideea. Un domeniu simplu duce la un fișier din directorul well-known pe care site-urile îl folosesc deja pentru metadate citibile de mașini. Dacă adăugați după domeniu segmente separate prin două puncte, ele devin segmente de cale, astfel încât o organizație poate publica un identificator separat pe departament, pe mediu sau pe serviciu de emitere fără să înregistreze nimic nou.
Două detalii scapă adesea. Un număr de port impune codificarea procentuală a celor două puncte, pentru că două puncte simple separă deja părțile identificatorului. Iar fișierul trebuie servit prin HTTPS cu un certificat care se validează, din moment ce transportul este singurul lucru care stă între un verificator și un răspuns falsificat.
Identificatorul pe care vi-l dă cineva
did:web:example.com:issuer:euAdresa HTTPS în care se traduce, fără niciun serviciu de căutare între
https://example.com/issuer/eu/did.jsonDID document returnat, cu cheile și punctele finale
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
De ce îl aleg organizațiile
Primul motiv este recunoașterea. Un verificator care vede un identificator îndreptat către domeniul unei companii poate verifica, în modul cel mai simplu cu putință, că numele de pe credential se potrivește cu numele de pe site. Nimănui nu trebuie să i se explice mai întâi o interogare în registru sau un lanț de certificate pentru ca lucrul acesta să se așeze.
Al doilea este că exploatarea nu costă nimic. Documentul stă în spatele aceleiași găzduiri, aceleiași monitorizări și aceluiași proces de schimbare ca restul site-ului. Nu există un sistem separat de finanțat, de menținut disponibil sau de explicat unui auditor, iar rotirea unei chei este o punere în producție, nu o tranzacție.
Al treilea este portabilitatea. Pentru că orice bibliotecă de portofel și de verificare o susține, did:web este metoda cu cele mai mari șanse să funcționeze cu un partener cu care nu v-ați integrat niciodată, ceea ce o face alegerea firească pentru proiecte-pilot, medii de test și acele evenimente de interoperabilitate unde se întâlnesc implementările europene de portofel.
Unde se oprește did:web
Tot ce vă dă metoda se sprijină pe domeniu. Cine controlează înregistrarea, serverele de nume și certificatul controlează identificatorul, așa că o reînnoire expirată, un cont DNS deturnat sau un certificat emis greșit sunt suficiente pentru a vorbi în numele dumneavoastră. Dedesubt nu există o a doua semnătură pe care să vă bazați.
Nici memorie nu are. Un verificator vede documentul așa cum este chiar acum și nu are cum să afle ce scria săptămâna trecută, deci o cheie înlocuită nu se deosebește de una rotită. did:webvh există exact pentru asta: aceeași găzduire web, plus un jurnal semnat al fiecărei modificări la care se poate doar adăuga, astfel încât un verificator să poată urmări istoricul de la prima intrare până la starea actuală.
Și nu este o verificare de identitate. Publicarea unui document sub un domeniu dovedește controlul asupra acelui domeniu și nimic mai mult. Când un verificator trebuie să știe că o persoană juridică este cea care pretinde a fi, acea siguranță vine dintr-o Trusted List, un certificat calificat sau un Trust Framework construit în acest scop, metoda DID purtând doar cheile de dedesubt.
Ce înseamnă asta pentru dumneavoastră
Emitent
Tratați documentul ca infrastructură de producție din prima zi. Puneți-l sub control al schimbărilor, urmăriți dacă adresa răspunde și dacă certificatul este valabil și păstrați o cheie retrasă listată pentru verificare atât timp cât ceva semnat cu ea este încă în uz.
Parte care se bazează
A descărca documentul nu înseamnă a avea încredere în el. Decideți separat ce domenii acceptați, refuzați orice al cărui certificat nu se validează și folosiți memoria cache cu grijă: o copie învechită ține în viață o cheie revocată, iar una lipsă vă doboară serviciul odată cu cel al celeilalte părți.
Deținător de portofel
Domeniul din identificatorul unui emitent merită o privire. Este singura parte a unui credential pe care o puteți citi fără niciun instrument, iar un nume care nu se potrivește cu organizația așteptată este un motiv să vă opriți, nu să continuați.
Termeni conexi
Întrebări frecvente
Am nevoie de software special pentru a rezolva un identificator did:web?
Nu. Identificatorul este o rețetă pentru construirea unei adrese URL, iar descărcarea acelei adrese prin HTTPS returnează documentul. Orice client HTTP poate face asta și tocmai de aceea did:web este de obicei prima metodă pe care o echipă o pune în funcțiune. O bibliotecă generală de rezolvare merită totuși folosită în producție, pentru că aplică unitar regulile de codificare și verificările asupra documentului, în loc să le lase în seama fiecărui apelant.
Este did:web mai puțin de încredere pentru că nu există blockchain?
Este de încredere altfel. O metodă bazată pe un registru distribuit împarte înregistrarea între multe părți, astfel încât niciuna să nu o poată rescrie pe tăcute. did:web pune această responsabilitate pe proprietarul domeniului și pe autoritățile de certificare din spatele TLS-ului său. Pentru o organizație al cărei nume și site sunt deja ceea ce recunosc clienții, acela este adesea locul cel mai onest pentru încredere, atâta timp cât toată lumea înțelege că domeniul este punctul slab.
Ce se întâmplă cu credentialele deja emise când cheile se schimbă?
Un verificator descarcă documentul așa cum este acum, deci un credential semnat cu o cheie eliminată între timp nu se mai verifică. Păstrați în document o cheie retrasă, marcată astfel încât să poată verifica, dar nu să mai semneze, cel puțin cât timp rămân valabile credentialele pe care le-a semnat. Dacă aveți nevoie ca un verificator să poată dovedi ce cheie era în vigoare la o anumită dată, acela este momentul în care did:webvh își merită complexitatea în plus.
Surse
Această pagină are caracter informativ și nu constituie consultanță juridică. Pentru îndrumări cu valoare oficială, consultați direct specificațiile W3C.