did:web forklaret
Ethvert digitalt credential er signeret af nogen, og en verifikator skal kunne slå op, hvem det er, og hvilke nøgler den part bruger i dag. did:web svarer på det med den infrastruktur, næsten enhver organisation allerede har: sit eget domænenavn. Identifikatoren fortæller, hvilket domæne du skal spørge, svaret er en ganske almindelig fil serveret over HTTPS, og der skal ikke eksistere andet, for at det virker.
Hvad did:web egentlig er
Et DID er en permanent identifikator, som enhver kan slå op for at finde de offentlige nøgler hos den, der har den. En DID-metode er reglen for det opslag, og der findes snesevis af dem. Nogle skriver registreringen til en blockchain, andre til et netværk bygget til formålet, og hver af dem tvinger en verifikator til at lære, hvordan netop det system fungerer.
did:web går den modsatte vej. Opslaget er en HTTPS-forespørgsel til det domæne, der står i identifikatoren, og registreringen er en JSON-fil, som domæneejeren udgiver og redigerer som enhver anden side på sit websted. Der er intet netværk at tilslutte sig, ingen hovedbog at skrive til og intet gebyr at betale.
Derfor dukker den op så tidligt i næsten ethvert projekt. Et team, der kan lægge en fil på sin webserver, kan udstede og verificere credentials samme eftermiddag, og den identifikator, de ender med, er et ægte DID, som enhver standardkonform wallet eller verifikator accepterer, ikke en midlertidig løsning, der skal udskiftes senere.
Hvordan identifikatoren bliver til en URL
Oversættelsen er mekanisk, og det er netop pointen. Et bart domæne fører til en fil i den well-known-mappe, websteder allerede bruger til maskinlæsbare metadata. Tilføjer man kolonadskilte segmenter efter domænet, bliver de i stedet stisegmenter, så én organisation kan udgive en separat identifikator pr. afdeling, pr. miljø eller pr. udstedelsestjeneste uden at registrere noget nyt.
To detaljer bliver let overset. Et portnummer kræver, at kolonet procentkodes, fordi et almindeligt kolon allerede adskiller identifikatorens dele. Og filen skal serveres over HTTPS med et certifikat, der validerer, eftersom transporten er det eneste, der står mellem en verifikator og et forfalsket svar.
Den identifikator, nogen giver dig
did:web:example.com:issuer:euDen HTTPS-URL, den oversættes til, uden en opslagstjeneste imellem
https://example.com/issuer/eu/did.jsonDet DID document, der kommer retur, med nøglerne og endepunkterne
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Hvorfor organisationer vælger den
Den første grund er genkendelighed. En verifikator, der ser en identifikator pege på et firmadomæne, kan på den enkleste måde, der findes, kontrollere, at navnet på credentialet svarer til navnet på webstedet. Ingen skal først have forklaret et registeropslag eller en certifikatkæde, før det lander.
Den anden er, at driften intet koster. Dokumentet ligger bag den samme hosting, den samme overvågning og den samme ændringsproces som resten af webstedet. Der er intet separat system at finansiere, holde tilgængeligt eller forklare for en revisor, og at rotere en nøgle er en udrulning frem for en transaktion.
Den tredje er portabilitet. Fordi ethvert wallet- og verifikatorbibliotek understøtter den, er did:web den metode, der mest sandsynligt virker over for en partner, du aldrig har integreret med før, hvilket gør den til det naturlige valg til pilotprojekter, testmiljøer og de interoperabilitetsarrangementer, hvor europæiske wallet-implementeringer mødes.
Hvor did:web stopper
Alt, hvad metoden giver dig, hviler på domænet. Den, der kontrollerer registreringen, navneserverne og certifikatet, kontrollerer identifikatoren, så en udløbet fornyelse, en kapret DNS-konto eller et fejlagtigt udstedt certifikat er nok til at tale i dit navn. Der ligger ingen anden signatur nedenunder at falde tilbage på.
Den har heller ingen hukommelse. En verifikator ser dokumentet, som det er lige nu, og har ingen måde at finde ud af, hvad der stod i sidste uge, så en udskiftet nøgle kan ikke skelnes fra en roteret. did:webvh findes netop derfor: den samme webhosting plus en signeret log over hver ændring, som der kun kan føjes til, så en verifikator kan følge historikken fra første post til den nuværende tilstand.
Og det er ikke en identitetskontrol. At udgive et dokument under et domæne beviser kontrol over det domæne og intet andet. Når en verifikator skal vide, at en juridisk person er den, den udgiver sig for at være, kommer den sikkerhed fra en Trusted List, et kvalificeret certifikat eller et Trust Framework bygget til formålet, mens DID-metoden kun bærer nøglerne nedenunder.
Hvad det betyder for dig
Udsteder
Behandl dokumentet som produktionsinfrastruktur fra dag ét. Sæt det under ændringsstyring, overvåg at adressen svarer, og at certifikatet er gyldigt, og lad en udfaset nøgle stå på listen til verifikation, så længe noget, den har signeret, stadig er i brug.
Relying party
At hente dokumentet er ikke det samme som at stole på det. Beslut særskilt, hvilke domæner du accepterer, afvis alt, hvis certifikat ikke validerer, og cache med omtanke: en forældet kopi holder en tilbagekaldt nøgle i live, en manglende trækker din tjeneste ned sammen med modpartens.
Tegnebogsindehaver
Domænet i en udsteders identifikator er et blik værd. Det er den ene del af et credential, du kan læse uden værktøjer, og et navn, der ikke passer til den organisation, du forventede, er en grund til at stoppe frem for at fortsætte.
Relaterede begreber
Ofte stillede spørgsmål
Kræver det særlig software at slå en did:web-identifikator op?
Nej. Identifikatoren er en opskrift på at bygge en URL, og henter man den adresse over HTTPS, får man dokumentet. Enhver HTTP-klient kan gøre det, og derfor er did:web som regel den første metode, et team får til at virke. Et alment resolver-bibliotek er alligevel værd at bruge i produktion, fordi det anvender kodningsreglerne og kontrollerne af dokumentet ensartet i stedet for at overlade dem til hver enkelt kalder.
Er did:web mindre troværdig, fordi der ikke er nogen blockchain?
Den er troværdig på en anden måde. En metode baseret på en distribueret hovedbog fordeler registreringen over mange parter, så ingen enkelt part kan skrive den om i stilhed. did:web lægger det ansvar hos domæneejeren og hos de certifikatudstedere, der står bag deres TLS. For en organisation, hvis navn og websted allerede er det, kunderne genkender, er det ofte det ærligste sted for tilliden at ligge, så længe alle forstår, at domænet er det svage punkt.
Hvad sker der med allerede udstedte credentials, når nøglerne skiftes?
En verifikator henter dokumentet, som det ser ud nu, så et credential signeret med en nøgle, der siden er fjernet, verificerer ikke længere. Behold en udfaset nøgle i dokumentet, markeret så den kan verificere, men ikke længere signere, i det mindste så længe de credentials, den har signeret, stadig er gyldige. Skal en verifikator kunne påvise, hvilken nøgle der var gældende på en bestemt dato, er det dér, did:webvh gør sin ekstra kompleksitet fortjent.
Kilder
Denne side er informativ og udgør ikke juridisk rådgivning. For autoritativ vejledning henvises direkte til W3C-specifikationerne.