did:web uitgelegd
Elk digitaal credential is door iemand ondertekend, en een verifier moet kunnen opzoeken wie dat is en welke sleutels diegene vandaag gebruikt. did:web beantwoordt dat met de infrastructuur die vrijwel elke organisatie al heeft: haar eigen domeinnaam. De identifier vertelt u welk domein u moet bevragen, het antwoord is een gewoon bestand dat over HTTPS wordt geserveerd, en er hoeft niets anders te bestaan om het te laten werken.
Wat did:web precies is
Een DID is een permanente identifier die iedereen kan opzoeken om de publieke sleutels te vinden van degene die hem houdt. Een DID-methode is de regel voor die opzoekactie, en er zijn er tientallen. Sommige schrijven de registratie naar een blockchain, andere naar een speciaal daarvoor gebouwd netwerk, en elke methode dwingt een verifier te leren hoe dat specifieke systeem werkt.
did:web kiest de omgekeerde route. De opzoekactie is een HTTPS-verzoek aan het domein dat in de identifier staat, en de registratie is een JSON-bestand dat de domeineigenaar publiceert en bewerkt zoals elke andere pagina op zijn site. Er is geen netwerk om aan deel te nemen, geen ledger om naar te schrijven en geen kosten om te betalen.
Daarom duikt het in vrijwel elk project zo vroeg op. Een team dat een bestand op zijn webserver kan zetten, kan diezelfde middag credentials uitgeven en verifiëren, en de identifier die daaruit komt is een echte DID die elke conforme wallet of verifier accepteert, geen tijdelijke oplossing die later vervangen moet worden.
Hoe de identifier een URL wordt
De vertaling is mechanisch, en dat is precies de bedoeling. Een kaal domein leidt naar een bestand in de well-known map die sites al gebruiken voor machineleesbare metadata. Voegt u na het domein segmenten toe die door dubbele punten worden gescheiden, dan worden dat padsegmenten, zodat één organisatie een aparte identifier kan publiceren per afdeling, per omgeving of per uitgiftedienst zonder iets nieuws te registreren.
Twee details worden vaak over het hoofd gezien. Bij een poortnummer moet de dubbele punt percent-gecodeerd worden, omdat een gewone dubbele punt de onderdelen van de identifier al scheidt. En het bestand moet over HTTPS worden geserveerd met een certificaat dat valideert, want het transport is het enige dat tussen een verifier en een vervalst antwoord staat.
De identifier die iemand u geeft
did:web:example.com:issuer:euDe HTTPS-URL waar hij naartoe leidt, zonder opzoekdienst ertussen
https://example.com/issuer/eu/did.jsonHet DID document dat terugkomt, met de sleutels en endpoints
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Waarom organisaties hiervoor kiezen
De eerste reden is herkenbaarheid. Een verifier die een identifier ziet die naar een bedrijfsdomein wijst, kan op de eenvoudigst denkbare manier controleren dat de naam op het credential overeenkomt met de naam op de website. Er hoeft niemand eerst een registeropzoeking of een keten van certificaten te worden uitgelegd voordat dat landt.
De tweede is dat het niets kost om te draaien. Het document staat achter dezelfde hosting, dezelfde monitoring en hetzelfde wijzigingsproces als de rest van de site. Er is geen apart systeem om te financieren, beschikbaar te houden of aan een auditor uit te leggen, en een sleutel roteren is een deployment in plaats van een transactie.
De derde is overdraagbaarheid. Omdat elke wallet- en verifier-bibliotheek het ondersteunt, maakt did:web de meeste kans om te werken tegen een partner met wie u nog nooit hebt geïntegreerd, wat het de logische keuze maakt voor pilots, testomgevingen en de interoperabiliteitsevenementen waar Europese wallet-implementaties elkaar treffen.
Waar did:web ophoudt
Alles wat de methode u geeft, rust op het domein. Wie de registratie, de nameservers en het certificaat beheert, beheert de identifier, dus een verlopen verlenging, een gekaapt DNS-account of een onterecht uitgegeven certificaat is genoeg om in uw naam te spreken. Er ligt geen tweede handtekening onder om op terug te vallen.
Het heeft ook geen geheugen. Een verifier ziet het document zoals het er nu staat en kan niet achterhalen wat er vorige week stond, dus een vervangen sleutel is niet te onderscheiden van een geroteerde. did:webvh bestaat precies daarvoor: dezelfde webhosting, plus een ondertekend logboek van elke wijziging waaraan alleen kan worden toegevoegd, zodat een verifier de geschiedenis kan volgen van de eerste vermelding tot de huidige stand.
En het is geen identiteitscontrole. Een document publiceren onder een domein bewijst controle over dat domein en verder niets. Moet een verifier weten dat een rechtspersoon is wie hij zegt te zijn, dan komt die zekerheid van een trusted list, een gekwalificeerd certificaat of een daarvoor gebouwd trust framework, waarbij de DID-methode er alleen de sleutels onder draagt.
Wat dit voor u betekent
Uitgever
Behandel het document vanaf dag één als productie-infrastructuur. Breng het onder wijzigingsbeheer, bewaak dat de URL antwoordt en dat het certificaat geldig is, en houd een uitgefaseerde sleutel vermeld voor verificatie zolang er nog iets in gebruik is dat ermee is ondertekend.
Vertrouwende partij
Het document ophalen is niet hetzelfde als het vertrouwen. Bepaal apart welke domeinen u accepteert, weiger alles waarvan het certificaat niet valideert, en cache met zorg: een verouderde kopie houdt een ingetrokken sleutel in leven, een ontbrekende haalt uw dienst onderuit samen met de andere kant.
Wallethouder
Het domein in een identifier van een uitgever is een blik waard. Het is het enige deel van een credential dat u zonder gereedschap kunt lezen, en een naam die niet overeenkomt met de organisatie die u verwachtte, is een reden om te stoppen in plaats van door te gaan.
Gerelateerde termen
Veelgestelde vragen
Heb ik speciale software nodig om een did:web identifier te resolven?
Nee. De identifier is een recept om een URL op te bouwen, en die URL over HTTPS ophalen levert het document op. Elke HTTP-client kan dat, en daarom is did:web meestal de eerste methode die een team werkend krijgt. Een algemene resolver-bibliotheek blijft in productie toch aan te raden, omdat die de coderingsregels en de controles op het document consistent toepast in plaats van ze aan elke aanroeper over te laten.
Is did:web minder betrouwbaar omdat er geen blockchain aan te pas komt?
Het is anders betrouwbaar. Een methode op basis van een ledger verdeelt de registratie over veel partijen, zodat geen enkele partij die stilletjes kan herschrijven. did:web legt die verantwoordelijkheid bij de domeineigenaar en bij de certificaatautoriteiten achter zijn TLS. Voor een organisatie waarvan de naam en de website al zijn wat klanten herkennen, is dat vaak de eerlijkste plek voor dat vertrouwen, zolang iedereen begrijpt dat het domein de zwakke plek is.
Wat gebeurt er met al uitgegeven credentials als de sleutels wijzigen?
Een verifier haalt het document op zoals het er nu staat, dus een credential dat is ondertekend met een sleutel die inmiddels is verwijderd, verifieert niet meer. Houd een uitgefaseerde sleutel in het document, gemarkeerd zodat die nog wel kan verifiëren maar niet meer kan ondertekenen, minstens zolang de credentials die ermee zijn ondertekend geldig blijven. Moet een verifier kunnen aantonen welke sleutel op een bepaalde datum actueel was, dan is dat het punt waarop did:webvh zijn extra complexiteit waard is.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende richtlijnen rechtstreeks de W3C-specificaties.