did:web förklarat
Varje digitalt credential är signerat av någon, och en verifierare måste kunna slå upp vem det är och vilka nycklar den parten använder i dag. did:web svarar på det med den infrastruktur nästan varje organisation redan har: sitt eget domännamn. Identifieraren talar om vilken domän du ska fråga, svaret är en vanlig fil som serveras över HTTPS, och inget annat behöver finnas för att det ska fungera.
Vad did:web faktiskt är
Ett DID är en permanent identifierare som vem som helst kan slå upp för att hitta de publika nycklarna hos den som innehar den. En DID-metod är regeln för den uppslagningen, och det finns dussintals av dem. Vissa skriver posten till en blockkedja, andra till ett särskilt byggt nätverk, och var och en tvingar en verifierare att lära sig hur just det systemet fungerar.
did:web går motsatt väg. Uppslagningen är en HTTPS-förfrågan till domänen som anges i identifieraren, och posten är en JSON-fil som domäninnehavaren publicerar och redigerar som vilken annan sida som helst på sin webbplats. Det finns inget nätverk att gå med i, ingen liggare att skriva till och ingen avgift att betala.
Det är därför den dyker upp så tidigt i nästan varje projekt. Ett team som kan lägga en fil på sin webbserver kan utfärda och verifiera credentials samma eftermiddag, och identifieraren de får är ett riktigt DID som varje standardenlig plånbok eller verifierare accepterar, inte en tillfällig lösning att byta ut senare.
Hur identifieraren blir en URL
Mappningen är mekanisk, och det är hela poängen. En ren domän leder till en fil i den well-known-katalog som webbplatser redan använder för maskinläsbara metadata. Lägger du till kolonseparerade segment efter domänen blir de i stället sökvägssegment, så att en organisation kan publicera en egen identifierare per avdelning, per miljö eller per utfärdandetjänst utan att registrera något nytt.
Två detaljer glöms lätt bort. Ett portnummer kräver att kolonet procentkodas, eftersom ett vanligt kolon redan skiljer identifierarens delar åt. Och filen måste serveras över HTTPS med ett certifikat som validerar, eftersom transporten är det enda som står mellan en verifierare och ett förfalskat svar.
Identifieraren som någon ger dig
did:web:example.com:issuer:euHTTPS-adressen den mappas till, utan någon uppslagstjänst emellan
https://example.com/issuer/eu/did.jsonDID document som kommer tillbaka, med nycklarna och slutpunkterna
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Varför organisationer väljer det
Det första skälet är igenkänning. En verifierare som ser en identifierare peka på ett företags domän kan kontrollera, på det enklaste sätt som finns, att namnet på credentialet stämmer med namnet på webbplatsen. Ingen behöver först få en registeruppslagning eller en certifikatkedja förklarad för sig för att det ska landa.
Det andra är att det inte kostar något att driva. Dokumentet ligger bakom samma drift, samma övervakning och samma ändringsprocess som resten av webbplatsen. Det finns inget separat system att finansiera, hålla tillgängligt eller förklara för en revisor, och att rotera en nyckel är en driftsättning i stället för en transaktion.
Det tredje är portabiliteten. Eftersom varje plånboks- och verifierarbibliotek stöder den är did:web den metod som mest sannolikt fungerar mot en partner du aldrig integrerat med tidigare, vilket gör den till det naturliga valet för piloter, testmiljöer och de interoperabilitetsevenemang där europeiska plånboksimplementationer möts.
Där did:web tar slut
Allt metoden ger dig vilar på domänen. Den som kontrollerar registreringen, namnservrarna och certifikatet kontrollerar identifieraren, så en utgången förnyelse, ett kapat DNS-konto eller ett felaktigt utfärdat certifikat räcker för att tala i ditt namn. Det finns ingen andra signatur under att falla tillbaka på.
Den har inte heller något minne. En verifierare ser dokumentet som det är just nu och har inget sätt att få veta vad det sa förra veckan, så en utbytt nyckel går inte att skilja från en roterad. did:webvh finns just för det: samma webbhotell, plus en signerad logg över varje ändring som bara kan byggas på, så att en verifierare kan följa historiken från första posten till nuvarande tillstånd.
Och det är ingen identitetskontroll. Att publicera ett dokument under en domän bevisar kontroll över den domänen och inget mer. När en verifierare måste veta att en juridisk person är den den utger sig för att vara kommer den säkerheten från en Trusted List, ett kvalificerat certifikat eller ett Trust Framework byggt för ändamålet, medan DID-metoden bara bär nycklarna under.
Vad detta betyder för dig
Utfärdare
Behandla dokumentet som produktionsinfrastruktur från dag ett. Sätt det under ändringskontroll, övervaka att adressen svarar och att certifikatet är giltigt, och låt en avvecklad nyckel stå kvar för verifiering så länge något den signerat fortfarande är i bruk.
Förlitande part
Att hämta dokumentet är inte samma sak som att lita på det. Besluta separat vilka domäner du accepterar, avvisa allt vars certifikat inte validerar, och cacha med omsorg: en föråldrad kopia håller en återkallad nyckel vid liv, en saknad drar ner din tjänst tillsammans med motpartens.
Plånboksinnehavare
Domänen i en utfärdares identifierare är värd en blick. Det är den enda del av ett credential du kan läsa utan verktyg, och ett namn som inte stämmer med organisationen du väntade dig är skäl att stanna i stället för att fortsätta.
Relaterade termer
Vanliga frågor
Behöver jag särskild programvara för att slå upp en did:web-identifierare?
Nej. Identifieraren är ett recept för att bygga en URL, och att hämta den adressen över HTTPS ger dokumentet. Vilken HTTP-klient som helst klarar det, och därför är did:web oftast den första metod ett team får igång. Ett allmänt resolverbibliotek är ändå värt att använda i produktion, eftersom det tillämpar kodningsreglerna och kontrollerna av dokumentet konsekvent i stället för att lämna dem till varje anropare.
Är did:web mindre pålitligt eftersom ingen blockkedja är inblandad?
Det är pålitligt på ett annat sätt. En metod som bygger på en distribuerad liggare sprider posten över många parter, så att ingen enskild kan skriva om den i tysthet. did:web lägger det ansvaret på domäninnehavaren och på certifikatutfärdarna bakom deras TLS. För en organisation vars namn och webbplats redan är det kunderna känner igen är det ofta det ärligaste stället för förtroendet att sitta, så länge alla förstår att domänen är den svaga punkten.
Vad händer med redan utfärdade credentials när nycklarna byts?
En verifierare hämtar dokumentet så som det ser ut nu, så ett credential som signerats med en nyckel som sedan tagits bort verifierar inte längre. Behåll en avvecklad nyckel i dokumentet, märkt så att den kan verifiera men inte längre signera, minst så länge de credentials den signerat fortfarande gäller. Om en verifierare måste kunna visa vilken nyckel som gällde ett visst datum är det där did:webvh förtjänar sin extra komplexitet.
Källor
Den här sidan är informativ och utgör inte juridisk rådgivning. För auktoritativ vägledning, se W3C:s specifikationer direkt.