did:web forklart
Hvert digitale credential er signert av noen, og en verifikator må kunne slå opp hvem det er og hvilke nøkler den parten bruker i dag. did:web svarer på det med den infrastrukturen nesten enhver organisasjon allerede har: sitt eget domenenavn. Identifikatoren forteller hvilket domene du skal spørre, svaret er en helt vanlig fil levert over HTTPS, og ingenting annet må finnes for at det skal virke.
Hva did:web egentlig er
En DID er en permanent identifikator som hvem som helst kan slå opp for å finne de offentlige nøklene til den som innehar den. En DID-metode er regelen for det oppslaget, og det finnes dusinvis av dem. Noen skriver oppføringen til en blokkjede, andre til et nettverk bygget for formålet, og hver av dem tvinger en verifikator til å lære hvordan akkurat det systemet virker.
did:web går motsatt vei. Oppslaget er en HTTPS-forespørsel til domenet som står i identifikatoren, og oppføringen er en JSON-fil domeneeieren publiserer og redigerer som enhver annen side på nettstedet sitt. Det er ikke noe nettverk å bli med i, ingen hovedbok å skrive til og ingen avgift å betale.
Derfor dukker den opp så tidlig i nesten hvert eneste prosjekt. Et team som kan legge en fil på webserveren sin, kan utstede og verifisere credentials samme ettermiddag, og identifikatoren de sitter igjen med er en ekte DID som enhver standardkonform lommebok eller verifikator godtar, ikke en midlertidig løsning som må byttes ut senere.
Hvordan identifikatoren blir en URL
Oversettelsen er mekanisk, og det er nettopp poenget. Et bart domene fører til en fil i den well-known-mappen nettsteder allerede bruker til maskinlesbare metadata. Legger du til kolonseparerte segmenter etter domenet, blir de i stedet stisegmenter, slik at én organisasjon kan publisere en egen identifikator per avdeling, per miljø eller per utstedelsestjeneste uten å registrere noe nytt.
To detaljer blir lett oversett. Et portnummer krever at kolonet prosentkodes, fordi et vanlig kolon allerede skiller delene i identifikatoren. Og filen må leveres over HTTPS med et sertifikat som validerer, siden transporten er det eneste som står mellom en verifikator og et forfalsket svar.
Identifikatoren noen gir deg
did:web:example.com:issuer:euHTTPS-adressen den oversettes til, uten en oppslagstjeneste imellom
https://example.com/issuer/eu/did.jsonDID document som kommer tilbake, med nøklene og endepunktene
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Hvorfor organisasjoner velger den
Den første grunnen er gjenkjennelse. En verifikator som ser en identifikator peke mot et firmadomene, kan på den enkleste måten som finnes kontrollere at navnet på credentialet stemmer med navnet på nettstedet. Ingen trenger først å få forklart et registeroppslag eller en sertifikatkjede for at det skal lande.
Den andre er at driften ikke koster noe. Dokumentet ligger bak den samme driften, den samme overvåkingen og den samme endringsprosessen som resten av nettstedet. Det finnes ikke noe eget system å finansiere, holde tilgjengelig eller forklare for en revisor, og å rotere en nøkkel er en utrulling framfor en transaksjon.
Den tredje er portabilitet. Fordi ethvert lommebok- og verifikatorbibliotek støtter den, er did:web den metoden som mest sannsynlig virker mot en partner du aldri har integrert med før, noe som gjør den til det naturlige valget for piloter, testmiljøer og de interoperabilitetsarrangementene der europeiske lommebokimplementasjoner møtes.
Der did:web stopper
Alt metoden gir deg hviler på domenet. Den som kontrollerer registreringen, navnetjenerne og sertifikatet, kontrollerer identifikatoren, så en utløpt fornyelse, en kapret DNS-konto eller et feilaktig utstedt sertifikat er nok til å tale i ditt navn. Det ligger ingen andre signatur under å falle tilbake på.
Den har heller ikke hukommelse. En verifikator ser dokumentet slik det er akkurat nå og har ingen måte å finne ut hva som sto der forrige uke, så en utskiftet nøkkel kan ikke skilles fra en rotert. did:webvh finnes nettopp for dette: den samme webhotelltjenesten, pluss en signert logg over hver endring som det bare kan legges til i, slik at en verifikator kan følge historikken fra første oppføring til dagens tilstand.
Og det er ingen identitetskontroll. Å publisere et dokument under et domene beviser kontroll over det domenet og ingenting mer. Når en verifikator må vite at en juridisk person er den den utgir seg for å være, kommer den sikkerheten fra en Trusted List, et kvalifisert sertifikat eller et Trust Framework bygget for formålet, mens DID-metoden bare bærer nøklene under.
Hva dette betyr for deg
Utsteder
Behandle dokumentet som produksjonsinfrastruktur fra dag én. Sett det under endringskontroll, overvåk at adressen svarer og at sertifikatet er gyldig, og la en utfaset nøkkel stå oppført for verifisering så lenge noe den har signert fortsatt er i bruk.
Avhengig part
Å hente dokumentet er ikke det samme som å stole på det. Bestem separat hvilke domener du godtar, avvis alt der sertifikatet ikke validerer, og bruk mellomlager med omhu: en utdatert kopi holder en tilbakekalt nøkkel i live, en manglende drar tjenesten din ned sammen med motpartens.
Lommebokinnehaver
Domenet i en utsteders identifikator er verdt et blikk. Det er den ene delen av et credential du kan lese uten verktøy, og et navn som ikke stemmer med organisasjonen du ventet deg, er en grunn til å stoppe framfor å fortsette.
Relaterte begreper
Ofte stilte spørsmål
Trenger jeg spesiell programvare for å slå opp en did:web-identifikator?
Nei. Identifikatoren er en oppskrift på å bygge en URL, og henter du den adressen over HTTPS, får du dokumentet. Enhver HTTP-klient klarer det, og derfor er did:web som regel den første metoden et team får til å virke. Et generelt resolver-bibliotek er likevel verdt å bruke i produksjon, fordi det bruker kodingsreglene og kontrollene av dokumentet konsekvent i stedet for å overlate dem til hver enkelt kaller.
Er did:web mindre til å stole på fordi det ikke er noen blokkjede?
Den er til å stole på på en annen måte. En metode basert på en distribuert hovedbok fordeler oppføringen på mange parter, slik at ingen enkelt part kan skrive den om i stillhet. did:web legger det ansvaret på domeneeieren og på sertifikatutstederne bak deres TLS. For en organisasjon hvis navn og nettsted allerede er det kundene kjenner igjen, er det ofte det ærligste stedet for tilliten, så lenge alle forstår at domenet er det svake punktet.
Hva skjer med allerede utstedte credentials når nøklene byttes?
En verifikator henter dokumentet slik det er nå, så et credential signert med en nøkkel som siden er fjernet, verifiserer ikke lenger. Behold en utfaset nøkkel i dokumentet, merket slik at den kan verifisere, men ikke lenger signere, minst så lenge de credentials den har signert fortsatt er gyldige. Må en verifikator kunne vise hvilken nøkkel som gjaldt på en bestemt dato, er det der did:webvh gjør seg fortjent til den ekstra kompleksiteten.
Kilder
Denne siden er informativ og utgjør ikke juridisk rådgivning. For autoritativ veiledning, se W3C-spesifikasjonene direkte.