did:web izskaidrots
Katru digitālo credential kāds ir parakstījis, un pārbaudītājam ir jāspēj uzzināt, kas tas ir un kādas atslēgas viņš izmanto šodien. did:web uz to atbild ar infrastruktūru, kas gandrīz katrai organizācijai jau ir: ar pašas domēna vārdu. Identifikators pasaka, kuram domēnam jājautā, atbilde ir parasts fails, kas tiek pasniegts pa HTTPS, un nekam citam nav jāpastāv, lai tas darbotos.
Kas did:web patiesībā ir
DID ir pastāvīgs identifikators, ko ikviens var uzmeklēt, lai atrastu tā turētāja publiskās atslēgas. DID metode ir noteikums šai uzmeklēšanai, un to ir desmitiem. Dažas ieraksta datus blokķēdē, citas īpaši izveidotā tīklā, un katra liek pārbaudītājam apgūt, kā darbojas tieši šī sistēma.
did:web iet pretējo ceļu. Uzmeklēšana ir HTTPS pieprasījums identifikatorā nosauktajam domēnam, un ieraksts ir JSON fails, ko domēna īpašnieks publicē un rediģē tāpat kā jebkuru citu savas vietnes lapu. Nav tīkla, kam pievienoties, virsgrāmatas, kurā rakstīt, vai maksas, kas jāmaksā.
Tāpēc tas parādās tik agri gandrīz katrā projektā. Komanda, kas prot uzlikt failu savā tīmekļa serverī, var izdot un pārbaudīt credentials jau tajā pašā pēcpusdienā, un iegūtais identifikators ir īsts DID, ko pieņem jebkurš atbilstošs maks vai pārbaudītājs, nevis pagaidu risinājums, kas vēlāk jānomaina.
Kā identifikators kļūst par URL
Atbilstība ir mehāniska, un tieši tajā ir jēga. Kails domēns ved uz failu direktorijā well-known, ko vietnes jau izmanto mašīnlasāmiem metadatiem. Ja aiz domēna pievienojat ar kolu atdalītas daļas, tās kļūst par ceļa daļām, tāpēc viena organizācija var publicēt atsevišķu identifikatoru katrai nodaļai, videi vai izdošanas pakalpojumam, neko jaunu nereģistrējot.
Divas nianses bieži paliek nepamanītas. Porta numuram kols ir jākodē ar procentu zīmi, jo vienkāršs kols jau atdala identifikatora daļas. Un fails ir jāpasniedz pa HTTPS ar sertifikātu, kas tiek validēts, jo pārraide ir vienīgais, kas stāv starp pārbaudītāju un viltotu atbildi.
Identifikators, ko kāds jums iedod
did:web:example.com:issuer:euHTTPS adrese, uz kuru tas attiecas, bez meklēšanas pakalpojuma pa vidu
https://example.com/issuer/eu/did.jsonAtgrieztais DID document ar atslēgām un galapunktiem
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Kāpēc organizācijas to izvēlas
Pirmais iemesls ir atpazīstamība. Pārbaudītājs, kurš redz identifikatoru, kas norāda uz uzņēmuma domēnu, var vienkāršākajā iespējamajā veidā pārliecināties, ka vārds uz credential sakrīt ar vārdu vietnē. Nevienam nav vispirms jāskaidro reģistra vaicājums vai sertifikātu ķēde, lai doma nonāktu līdz galam.
Otrais ir tas, ka uzturēšana neko nemaksā. Dokuments atrodas aiz tās pašas mitināšanas, tās pašas uzraudzības un tā paša izmaiņu procesa kā pārējā vietne. Nav atsevišķas sistēmas, kas būtu jāfinansē, jāuztur pieejama vai jāskaidro revidentam, un atslēgas nomaiņa ir izvietošana, nevis darījums.
Trešais ir pārnesamība. Tā kā to atbalsta katra maka un pārbaudītāja bibliotēka, did:web ir metode, kas visdrīzāk nostrādās ar partneri, ar kuru nekad neesat integrējies, un tas padara to par dabisku izvēli pilotprojektiem, testa vidēm un tiem savietojamības pasākumiem, kur satiekas Eiropas maku ieviesumi.
Kur did:web beidzas
Viss, ko metode dod, balstās uz domēnu. Kas kontrolē reģistrāciju, vārdu serverus un sertifikātu, tas kontrolē identifikatoru, tāpēc nokavēta pagarināšana, nolaupīts DNS konts vai kļūdaini izdots sertifikāts ir pietiekams, lai runātu jūsu vārdā. Apakšā nav otra paraksta, uz ko atkāpties.
Tam nav arī atmiņas. Pārbaudītājs redz dokumentu tādu, kāds tas ir tieši tagad, un viņam nav iespējas uzzināt, kas tajā bija pagājušajā nedēļā, tāpēc nomainītu atslēgu nevar atšķirt no rotētas. did:webvh pastāv tieši tāpēc: tā pati tīmekļa mitināšana plus parakstīts katras izmaiņas žurnāls, kuram var tikai pievienot, lai pārbaudītājs varētu izsekot vēsturei no pirmā ieraksta līdz pašreizējam stāvoklim.
Un tā nav identitātes pārbaude. Dokumenta publicēšana zem domēna pierāda kontroli pār šo domēnu un neko vairāk. Kad pārbaudītājam ir jāzina, ka juridiska persona ir tā, par ko uzdodas, šī pārliecība nāk no Trusted List, kvalificēta sertifikāta vai šim nolūkam veidota Trust Framework, bet DID metode nes tikai zem tā esošās atslēgas.
Ko tas nozīmē jums
Izsniedzējs
Izturieties pret dokumentu kā pret ražošanas infrastruktūru no pirmās dienas. Pakļaujiet to izmaiņu kontrolei, uzraugiet, vai adrese atbild un vai sertifikāts ir derīgs, un atstājiet izņemtu atslēgu sarakstā pārbaudei tik ilgi, kamēr kaut kas ar to parakstīts vēl ir lietošanā.
Paļāvēja puse
Dokumenta ielāde nav tas pats, kas uzticēšanās tam. Atsevišķi izlemiet, kurus domēnus pieņemat, noraidiet visu, kā sertifikāts netiek validēts, un kešojiet uzmanīgi: novecojusi kopija uztur atsauktu atslēgu dzīvu, bet trūkstoša novelk jūsu pakalpojumu kopā ar otru pusi.
Maka turētājs
Domēns izdevēja identifikatorā ir skatiena vērts. Tā ir vienīgā credential daļa, ko varat izlasīt bez jebkādiem rīkiem, un nosaukums, kas neatbilst gaidītajai organizācijai, ir iemesls apstāties, nevis turpināt.
Saistītie termini
Biežāk uzdotie jautājumi
Vai did:web identifikatora atrisināšanai ir vajadzīga īpaša programmatūra?
Nē. Identifikators ir recepte URL izveidei, un šīs adreses ielāde pa HTTPS atgriež dokumentu. To spēj jebkurš HTTP klients, un tieši tāpēc did:web parasti ir pirmā metode, ko komanda iedarbina. Vispārēju atrisināšanas bibliotēku ražošanā tomēr ir vērts izmantot, jo tā vienveidīgi piemēro kodēšanas noteikumus un dokumenta pārbaudes, nevis atstāj tās katra izsaucēja ziņā.
Vai did:web ir mazāk uzticams tāpēc, ka nav blokķēdes?
Tas ir uzticams citādi. Uz sadalītu virsgrāmatu balstīta metode izklāj ierakstu pār daudzām pusēm, lai neviena no tām to nevarētu klusi pārrakstīt. did:web šo atbildību uzliek domēna īpašniekam un sertifikācijas iestādēm aiz viņa TLS. Organizācijai, kuras nosaukums un vietne jau tāpat ir tas, ko klienti atpazīst, tā bieži ir godīgākā vieta, kur uzticībai atrasties, kamēr vien visi saprot, ka domēns ir vājais punkts.
Kas notiek ar jau izdotajiem credentials, kad atslēgas mainās?
Pārbaudītājs ielādē dokumentu tādu, kāds tas ir tagad, tāpēc credential, kas parakstīts ar kopš tā laika noņemtu atslēgu, vairs netiek pārbaudīts. Paturiet izņemtu atslēgu dokumentā, atzīmētu tā, lai tā varētu pārbaudīt, bet vairs ne parakstīt, vismaz tik ilgi, kamēr ar to parakstītie credentials paliek derīgi. Ja pārbaudītājam ir jāspēj pierādīt, kura atslēga bija spēkā noteiktā datumā, tieši tur did:webvh nopelna savu papildu sarežģītību.
Avoti
Šī lapa ir informatīva un nav juridisks padoms. Autoritatīvām norādēm skatiet tieši W3C specifikācijas.