did:web pojasnjeno
Vsak digitalni credential je nekdo podpisal in preveritelj mora znati poiskati, kdo je to in katere ključe ta stran uporablja danes. did:web na to odgovarja z infrastrukturo, ki jo ima skoraj vsaka organizacija že zdaj: s svojim domenskim imenom. Identifikator pove, katero domeno je treba vprašati, odgovor je navadna datoteka, postrežena prek HTTPS, in nič drugega ne rabi obstajati, da to deluje.
Kaj did:web pravzaprav je
DID je trajen identifikator, ki ga lahko kdorkoli poišče, da najde javne ključe tistega, ki ga ima. Metoda DID je pravilo za to iskanje in teh je na desetine. Nekatere zapišejo vnos v verigo blokov, druge v za to zgrajeno omrežje, in vsaka prisili preveritelja, da se nauči, kako deluje prav tisti sistem.
did:web ubere nasprotno pot. Iskanje je zahteva HTTPS do domene, navedene v identifikatorju, vnos pa je datoteka JSON, ki jo lastnik domene objavi in ureja kot katero koli drugo stran svojega spletnega mesta. Ni omrežja, ki bi se mu bilo treba pridružiti, ne knjige, v katero bi bilo treba pisati, ne pristojbine.
Zato se pojavi tako zgodaj v skoraj vsakem projektu. Ekipa, ki zna datoteko naložiti na svoj spletni strežnik, lahko credentiale izdaja in preverja še isto popoldne, dobljeni identifikator pa je pravi DID, ki ga sprejme vsaka skladna denarnica ali preveritelj, in ne začasna rešitev za poznejšo zamenjavo.
Kako identifikator postane URL
Preslikava je mehanska in prav v tem je njen smisel. Gola domena vodi do datoteke v imeniku well-known, ki ga spletna mesta že uporabljajo za strojno berljive metapodatke. Če za domeno dodate dele, ločene z dvopičji, ti postanejo deli poti, tako da lahko ena organizacija objavi ločen identifikator za vsak oddelek, okolje ali storitev izdajanja, ne da bi karkoli novega registrirala.
Dve podrobnosti zlahka uidejo. Pri številki vrat je treba dvopičje kodirati z odstotkom, ker navadno dvopičje že ločuje dele identifikatorja. Datoteka pa mora biti postrežena prek HTTPS z digitalnim potrdilom, ki se preveri, saj je prenos edino, kar stoji med preveriteljem in ponarejenim odgovorom.
Identifikator, ki vam ga nekdo da
did:web:example.com:issuer:euNaslov HTTPS, na katerega se preslika, brez vmesne iskalne storitve
https://example.com/issuer/eu/did.jsonVrnjeni DID document s ključi in končnimi točkami
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Zakaj se organizacije odločajo zanj
Prvi razlog je prepoznavnost. Preveritelj, ki vidi identifikator, usmerjen na domeno podjetja, lahko na najpreprostejši možni način preveri, da se ime na credentialu ujema z imenom na spletnem mestu. Nikomur ni treba prej razlagati poizvedbe v register ali verige digitalnih potrdil, da to zaleže.
Drugi je, da obratovanje ne stane nič. Dokument je za istim gostovanjem, istim nadzorom in istim postopkom sprememb kot preostanek spletnega mesta. Ni ločenega sistema, ki bi ga bilo treba financirati, ohranjati dosegljivega ali pojasnjevati revizorju, menjava ključa pa je namestitev in ne transakcija.
Tretji je prenosljivost. Ker jo podpira vsaka knjižnica denarnice in preveritelja, je did:web metoda, ki bo najverjetneje delovala s partnerjem, s katerim še nikoli niste integrirali. Zaradi tega je naravna izbira za pilotne projekte, testna okolja in tiste dogodke o interoperabilnosti, kjer se srečujejo evropske izvedbe denarnic.
Kje se did:web ustavi
Vse, kar metoda daje, sloni na domeni. Kdor nadzoruje registracijo, imenske strežnike in digitalno potrdilo, nadzoruje identifikator, zato zapadlo podaljšanje, ugrabljen račun DNS ali napačno izdano potrdilo zadošča, da nekdo govori v vašem imenu. Spodaj ni drugega podpisa, na katerega bi se dalo opreti.
Prav tako nima spomina. Preveritelj vidi dokument takšen, kakršen je prav zdaj, in nima načina, da bi izvedel, kaj je pisalo prejšnji teden, zato zamenjanega ključa ni mogoče ločiti od zgolj menjanega. did:webvh obstaja natanko zato: isto spletno gostovanje ter podpisan dnevnik vsake spremembe, ki se mu da le dodajati, da lahko preveritelj sledi zgodovini od prvega vnosa do trenutnega stanja.
In to ni preverjanje istovetnosti. Objava dokumenta pod domeno dokazuje nadzor nad to domeno in nič več. Kadar mora preveritelj vedeti, da je pravna oseba res tista, za katero se izdaja, to gotovost daje Trusted List, kvalificirano digitalno potrdilo ali za ta namen zgrajen Trust Framework, metoda DID pa nosi le ključe pod tem.
Kaj to pomeni za vas
Izdajatelj
Z dokumentom ravnajte kot s produkcijsko infrastrukturo od prvega dne. Vključite ga v upravljanje sprememb, spremljajte, ali naslov odgovarja in ali je digitalno potrdilo veljavno, in pustite umaknjeni ključ na seznamu za preverjanje, dokler je v uporabi karkoli, kar je z njim podpisano.
Zanašajoča se stranka
Pridobiti dokument ni isto kot zaupati mu. Ločeno se odločite, katere domene sprejemate, zavrnite vse, čigar potrdilo se ne preveri, in predpomnite previdno: zastarela kopija ohranja preklican ključ pri življenju, manjkajoča pa podre vašo storitev skupaj z nasprotno stranjo.
Imetnik denarnice
Domena v identifikatorju izdajatelja je vredna pogleda. To je edini del credentiala, ki ga lahko preberete brez orodij, in ime, ki se ne ujema s pričakovano organizacijo, je razlog, da se ustavite, ne pa nadaljujete.
Sorodni pojmi
Pogosta vprašanja
Ali za razreševanje identifikatorja did:web potrebujem posebno programsko opremo?
Ne. Identifikator je recept za sestavo naslova URL, pridobitev tega naslova prek HTTPS pa vrne dokument. To zmore vsak odjemalec HTTP, zato je did:web običajno prva metoda, ki jo ekipa spravi v delovanje. Splošno knjižnico za razreševanje se v produkciji kljub temu splača uporabiti, saj enotno uveljavlja pravila kodiranja in preverjanja dokumenta, namesto da bi jih prepustila vsakemu klicatelju.
Je did:web manj zaupanja vreden, ker ni nobene verige blokov?
Zaupanja vreden je na drugačen način. Metoda, ki temelji na porazdeljeni knjigi, razprši zapis med veliko strani, tako da ga nobena ne more tiho prepisati. did:web to odgovornost naloži lastniku domene in overiteljem digitalnih potrdil za njegovim TLS. Za organizacijo, katere ime in spletno mesto sta že to, kar stranke prepoznajo, je to pogosto najbolj pošteno mesto za takšno zaupanje, dokler vsi razumejo, da je domena šibka točka.
Kaj se zgodi z že izdanimi credentiali, ko se ključi zamenjajo?
Preveritelj pridobi dokument v stanju, kakršno je zdaj, zato se credential, podpisan s ključem, ki je bil vmes odstranjen, ne preveri več. Umaknjeni ključ pustite v dokumentu, označen tako, da lahko preverja, ne more pa več podpisovati, vsaj tako dolgo, dokler ostajajo veljavni credentiali, ki jih je podpisal. Če mora preveritelj znati dokazati, kateri ključ je veljal na določen datum, je to točka, na kateri did:webvh upraviči svojo dodatno zapletenost.
Viri
Ta stran je informativna in ne pomeni pravnega nasveta. Za zavezujoče usmeritve si oglejte neposredno specifikacije W3C.