did:web selgitatuna
Iga digitaalse credentiali on keegi allkirjastanud ja kontrollija peab suutma välja selgitada, kes see on ja milliseid võtmeid ta täna kasutab. did:web vastab sellele taristuga, mis on peaaegu igal organisatsioonil juba olemas: tema enda domeeninimega. Identifikaator ütleb, millist domeeni küsida, vastuseks on tavaline HTTPS-i kaudu serveeritav fail, ja midagi muud ei pea selle toimimiseks olemas olema.
Mis did:web tegelikult on
DID on püsiv identifikaator, mille abil igaüks saab leida selle hoidja avalikud võtmed. DID-meetod on reegel selle otsingu tegemiseks ja neid on kümneid. Mõni kirjutab kande plokiahelasse, mõni selleks ehitatud võrku, ja iga meetod sunnib kontrollijat õppima, kuidas just see süsteem töötab.
did:web läheb vastupidist teed. Otsing on HTTPS-päring identifikaatoris nimetatud domeenile ja kanne on JSON-fail, mille domeeni omanik avaldab ja muudab nagu iga teise lehe oma saidil. Puudub võrk, millega liituda, pearaamat, kuhu kirjutada, ja tasu, mida maksta.
Seepärast ilmub see peaaegu igas projektis nii vara välja. Meeskond, kes oskab faili oma veebiserverisse panna, saab samal pärastlõunal credentiale väljastada ja kontrollida, ning saadud identifikaator on päris DID, mille iga nõuetele vastav rahakott või kontrollija aktsepteerib, mitte ajutine lahendus, mis tuleb hiljem välja vahetada.
Kuidas identifikaatorist saab URL
Vastendus on mehaaniline ja just see ongi mõte. Paljas domeen viib failini selles well-known kataloogis, mida saidid juba kasutavad masinloetavate metaandmete jaoks. Kui lisada domeeni järele koolonitega eraldatud osad, saavad neist teeosad, nii et üks organisatsioon saab avaldada eraldi identifikaatori iga osakonna, keskkonna või väljastusteenuse kohta ilma midagi uut registreerimata.
Kaks üksikasja jäävad sageli märkamata. Pordinumbri puhul tuleb koolon protsentkodeerida, sest lihtne koolon eraldab juba identifikaatori osi. Ja fail tuleb serveerida HTTPS-i kaudu kehtiva sertifikaadiga, sest transport on ainus asi kontrollija ja võltsitud vastuse vahel.
Identifikaator, mille keegi sulle annab
did:web:example.com:issuer:euHTTPS-aadress, millele see vastendub, ilma vahepealse otsinguteenuseta
https://example.com/issuer/eu/did.jsonTagastatav DID document koos võtmete ja lõpp-punktidega
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Miks organisatsioonid selle valivad
Esimene põhjus on äratuntavus. Kontrollija, kes näeb ettevõtte domeenile osutavat identifikaatorit, saab kõige lihtsamal võimalikul viisil kontrollida, et credentialil olev nimi vastab veebisaidi nimele. Kellelegi ei pea enne selgitama registripäringut ega sertifikaadiahelat, et see kohale jõuaks.
Teine on see, et selle käigushoidmine ei maksa midagi. Dokument asub sama majutuse, sama seire ja sama muudatusprotsessi taga nagu ülejäänud sait. Ei ole eraldi süsteemi, mida rahastada, käigus hoida või audiitorile selgitada, ja võtme vahetamine on juurutus, mitte tehing.
Kolmas on ülekantavus. Kuna iga rahakoti- ja kontrollijateek seda toetab, on did:web meetod, mis kõige tõenäolisemalt töötab partneriga, kellega sa pole kunagi varem liidestunud. See teeb sellest loomuliku valiku pilootprojektide, testkeskkondade ja nende koostalitlusvõime ürituste jaoks, kus Euroopa rahakotilahendused kokku saavad.
Kus did:web lõpeb
Kõik, mida meetod annab, toetub domeenile. Kes kontrollib registreeringut, nimeservereid ja sertifikaati, kontrollib identifikaatorit, nii et aegunud pikendus, kaaperdatud DNS-konto või ekslikult väljastatud sertifikaat on piisav, et sinu nimel rääkida. Selle all ei ole teist allkirja, millele toetuda.
Sel ei ole ka mälu. Kontrollija näeb dokumenti sellisena, nagu see praegu on, ega saa kuidagi teada, mis seal eelmisel nädalal kirjas oli, nii et asendatud võtit ei saa eristada vahetatud võtmest. did:webvh ongi täpselt selleks olemas: sama veebimajutus ning lisaks allkirjastatud ja üksnes juurdekirjutatav logi igast muudatusest, nii et kontrollija saab jälgida ajalugu esimesest kandest kuni praeguse seisuni.
Ja see ei ole isikusamasuse kontroll. Dokumendi avaldamine domeeni all tõendab kontrolli selle domeeni üle ja mitte midagi muud. Kui kontrollija peab teadma, et juriidiline isik on see, kes ta väidab end olevat, tuleb see kindlus usaldusnimekirjast, kvalifitseeritud sertifikaadist või selleks ehitatud usaldusraamistikust, kusjuures DID-meetod kannab üksnes nende all olevaid võtmeid.
Mida see sinu jaoks tähendab
Väljastaja
Kohtle dokumenti tootmistaristuna esimesest päevast peale. Võta see muudatuste kontrolli alla, jälgi, et URL vastaks ja sertifikaat kehtiks, ning hoia kasutuselt kõrvaldatud võti kontrollimiseks nimekirjas seni, kuni midagi sellega allkirjastatut on veel kasutuses.
Tuginev osapool
Dokumendi pärimine ei ole sama mis selle usaldamine. Otsusta eraldi, milliseid domeene aktsepteerid, keeldu kõigest, mille sertifikaat ei kehti, ja puhverda hoolikalt: aegunud koopia hoiab tühistatud võtme elus, puuduv koopia tõmbab sinu teenuse koos teise poolega alla.
Rahakoti valdaja
Väljastaja identifikaatoris olev domeen väärib pilku. See on credentiali ainus osa, mida saad lugeda ilma tööriistadeta, ja nimi, mis ei vasta oodatud organisatsioonile, on põhjus pigem peatuda kui jätkata.
Seotud mõisted
Korduma kippuvad küsimused
Kas did:web identifikaatori lahendamiseks on vaja eritarkvara?
Ei. Identifikaator on retsept URL-i koostamiseks ja selle aadressi pärimine HTTPS-i kaudu tagastab dokumendi. Iga HTTP-klient suudab seda teha ja just seetõttu on did:web tavaliselt esimene meetod, mille meeskond tööle saab. Üldotstarbeline lahendamisteek tasub tootmises siiski kasutusele võtta, sest see rakendab kodeerimisreegleid ja dokumendi kontrolle ühtemoodi, selle asemel et jätta need iga kutsuja hooleks.
Kas did:web on vähem usaldusväärne, sest plokiahelat ei ole?
See on usaldusväärne teisiti. Hajusraamatul põhinev meetod jaotab kande paljude osapoolte vahel, nii et ükski neist ei saa seda vaikselt ümber kirjutada. did:web paneb selle vastutuse domeeni omanikule ja tema TLS-i taga olevatele sertifitseerimiskeskustele. Organisatsioonile, kelle nimi ja veebisait on niigi see, mida kliendid ära tunnevad, on see sageli kõige ausam koht usalduse jaoks, kui kõik mõistavad, et domeen on nõrk koht.
Mis saab juba väljastatud credentialitest, kui võtmed muutuvad?
Kontrollija pärib dokumendi sellisena, nagu see praegu on, nii et credential, mis on allkirjastatud vahepeal eemaldatud võtmega, ei kontrollu enam. Hoia kasutuselt kõrvaldatud võti dokumendis alles, märgituna nii, et see saab kontrollida, kuid mitte enam allkirjastada, vähemalt seni, kuni sellega allkirjastatud credentialid kehtivad. Kui kontrollija peab suutma tõendada, milline võti oli teatud kuupäeval kehtiv, siis on see koht, kus did:webvh oma lisakeerukuse ära teenib.
Allikad
See leht on informatiivne ega kujuta endast õigusnõu. Autoriteetsete juhiste saamiseks tutvu otse W3C spetsifikatsioonidega.