DID uitgelegd: wat een Decentralized Identifier is
Een Decentralized Identifier, vrijwel altijd geschreven als DID, is een naam voor een partij die niemand hoeft uit te geven en die niemand kan intrekken. Het is het antwoord op een vraag waar elke digitale credential vroeg of laat tegenaan loopt: de wallet bevat een ondertekende verklaring, dus wie ondertekende die, en hoe controleer je dat zonder een register aan te schrijven?
Deze pagina is de versie in gewone taal. Hij behandelt waar een DID uit bestaat, wat er gebeurt als je er een opzoekt, hoe de gangbare methoden verschillen en, net zo belangrijk, wat een DID op zichzelf niet vertelt.
Waar een DID uit bestaat
Een DID is één regel tekst in drie delen, gescheiden door dubbele punten. Het eerste deel verandert nooit. Het tweede noemt de methode en het derde is wat die methode nodig heeft om het juiste document te vinden.
Dat middelste deel is de enige echte keuze. Alles waar mensen het over hebben als ze discussiëren over DIDs, waar de data staat, wie die mag wijzigen, wat het kost om het draaiend te houden, wordt bepaald door de methode en door niets anders.
did:web:credenco.com
did
Schema
Altijd dezelfde drie letters. Het zegt niets meer dan: wat hierna komt is een Decentralized Identifier.
web
Methode
De regels voor het vinden en bijwerken van het document. Dit is de keuze met echte gevolgen, want die bepaalt wie de identifier bereikbaar moet houden.
credenco.com
Methodespecifieke identifier
Het deel dat alleen die methode kan lezen. Hier is het een domeinnaam, elders kan het een ledger-vermelding of de publieke sleutel zelf zijn.
Wat er gebeurt als je er een opzoekt
Op zichzelf doet een DID niets. De waarde ontstaat op het moment dat iemand hem resolvet: de tekenreeks omzet in het kleine document erachter, dat de publieke sleutels van het subject opsomt en waar het subject bereikbaar is.
1. Je hebt een identifier
Er komt een credential binnen met de naam van de partij die hem ondertekende. Tot nu toe is dat een tekenreeks en bewijst het niets.
2. Een resolver leest de methode
De naam van de methode vertelt de resolver waar hij heen moet: een bestand ophalen van een domein, een ledger lezen, of de sleutel uit de identifier zelf halen.
3. Er komt een document terug
Het somt de publieke sleutels op die het subject nu gebruikt, en de endpoints waar het bereikbaar is.
4. Je controleert de handtekening
Zonder account waar dan ook, zonder API-sleutel en zonder toestemming te vragen aan wie de methode beheert.
Waarom niet een domeinnaam of een certificaat
Het web heeft al manieren om te zeggen wie iemand is, dus de eerlijke vraag is wat een DID toevoegt. Een domeinnaam zegt waar je een verzoek naartoe stuurt, maar niets over welke sleutels bij de partij erachter horen. Een certificaat koppelt wel een sleutel aan een naam, en doet dat goed, maar alleen zolang een autoriteit dat blijft bevestigen en alleen voor de sleutel waarvoor het is afgegeven.
Een credential heeft de vervelende gewoonte beide te overleven. Een diploma is over twintig jaar nog steeds een diploma, lang nadat de ondertekensleutel is gewisseld en het certificaat dat hem dekte is verlopen. Omdat een DID de naam scheidt van de sleutels, kan de uitgever een sleutel vervangen zonder dat de identifier verandert en zonder alles opnieuw uit te geven wat hij ooit heeft ondertekend.
Sleutels wisselen, de naam niet
Een gecompromitteerde sleutel wisselen betekent een nieuw document publiceren op dezelfde identifier. Elke verwijzing naar de uitgever blijft geldig.
Controleren vraagt niemands toestemming
Een verifier resolvet de identifier en controleert de wiskunde. Er is geen account te openen bij de uitgever en geen limiet op de dienst van iemand anders.
De methoden die je echt tegenkomt
Er zijn ruim honderd methoden geregistreerd en bijna allemaal kun je gerust negeren. Drie dekken vrijwel alles waar een organisatie in het Europese ecosysteem mee te maken krijgt.
did:web
Het document is een bestand op een domein dat je al beheert. Niets nieuws om te draaien en de drempel is vrijwel nul, en daarom beginnen de meeste organisaties hier. Het addertje: wie het domein beheert, beheert de identifier, en er is geen vastlegging van wat het document gisteren zei.
Lees de definitiedid:webvh
Hetzelfde bestand op een domein, plus een log dat alleen wordt aangevuld met elke versie die het ooit heeft gehad. Een verifier kan zien dat de sleutel die hij vandaag vertrouwt daar is neergezet door de partij die de identifier gisteren had, en dat is precies het gat dat did:web openlaat.
Lees de definitiedid:key
De identifier is de publieke sleutel, gecodeerd. Er valt niets te hosten en niets op te halen, wat hem ideaal maakt voor kortlevende en wegwerpidentiteiten. Het betekent ook dat de sleutel nooit kan worden gewisseld, dus het is de verkeerde keuze voor iets wat lang mee moet.
De rest staat in het W3C-register van DID-methoden. Behandel een methode die daar niet in staat, of die maar door één product wordt ondersteund, als een afhankelijkheid van dat product.
Wat een DID je niet vertelt
Hier houden de meeste uitleggen over DIDs stilzwijgend op, en juist dit deel bepaalt of een walletprogramma werkt. Een DID bewijst continuïteit: de partij die deze credential ondertekende heeft dezelfde sleutel als de partij die die andere ondertekende. Het bewijst niets over wie die partij in de echte wereld is.
Iedereen kan in een paar seconden een DID aanmaken, ook iemand die zich voordoet als een universiteit. Vaststellen dat een identifier echt bij een geaccrediteerde instelling hoort is een aparte taak, uitgevoerd door een trusted list, een gekwalificeerd certificaat of een verklaring van een partij die de verifier al vertrouwt. Onder eIDAS 2.0 is dat precies waar de trusted lists en de registratie van vertrouwende partijen voor bedoeld zijn.
Lees die twee samen en het beeld is helder: de DID draagt de sleutels, het trust framework draagt de betekenis, en een verifier heeft ze allebei nodig voordat hij iets accepteert.
Wat dit voor u betekent
Uitgever
Eén identifier die elke sleutelwissel overleeft, zodat een credential die je jaren geleden ondertekende nog controleerbaar is en een gecompromitteerde sleutel operationeel werk is in plaats van een terugroepactie.
Verifier
Je kunt een handtekening controleren zonder account, contract of integratie per uitgever. Wat je nog wel nodig hebt, is een trusted list die zegt welke identifiers je mag accepteren.
Wallethouder
Niets te beheren. De identifiers zitten in je credentials en de wallet zoekt ze voor je op wanneer hij laat zien wie wat heeft uitgegeven.
Gerelateerde termen
Veelgestelde vragen
Heb je een blockchain nodig om DIDs te gebruiken?
Nee. Die associatie komt van de methoden die het eerst zijn gebouwd, niet van de standaard. De specificatie zegt niets over waar een document moet staan, en de methoden die in Europa dagelijks worden gebruikt, did:web en did:webvh, zijn allebei bestanden die via gewoon HTTPS worden geserveerd vanaf een domein dat de eigenaar al heeft.
Waarom niet gewoon een domeinnaam gebruiken?
Een domein zegt waar je iets kunt vinden, niet welke sleutels erbij horen, en een certificaat koppelt sleutels aan een naam zolang een autoriteit dat bevestigt. Een DID geeft je beide delen tegelijk en houdt de identifier stabiel terwijl de sleutels erachter wisselen, en dat is wat een drie jaar geleden ondertekende credential vandaag nog controleerbaar maakt.
Welke methode moeten wij kiezen?
Begin bij hoe lang de identifier moet standhouden en wie hem mag wijzigen. Voor een uitgever van wie de credentials langer meegaan dan de sleutels geeft did:webvh verifiers de historie die ze nodig hebben om een sleutelwissel te vertrouwen. Voor interne pilots en kortlevende identiteiten is did:web of did:key meestal genoeg, en later overstappen is een gewone migratie en geen verbouwing.
Bewijst een DID dat een organisatie is wie zij zegt te zijn?
Nee, en doen alsof van wel is de meest gemaakte fout. Een DID bewijst dat wie twee dingen ondertekende dezelfde privésleutel had. Of die sleutel van een geaccrediteerde universiteit is of van iemand die een overtuigend domein registreerde, is een aparte vraag, beantwoord door een trusted list, een gekwalificeerd certificaat of een verklaring van een partij die je al vertrouwt.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg de W3C-specificatie zelf voor de gezaghebbende formulering.