Inleiding

In de wereld van vandaag raken onze digitale en fysieke levens steeds meer verweven met apps, diensten en apparaten die we gebruiken. De toegenomen connectiviteit introduceert een risico op identiteitsdiefstal en datalekken. Deze inbreuken kunnen een verwoestende impact hebben op ons persoonlijke en professionele leven. Maar er is hoop. Diverse partijen, waaronder Microsoft, werken aan een nieuwe oplossing waarbij je als individu controle hebt over je eigen digitale identiteit. Het eerste deel van deze blog is meer technisch van aard en beschrijft de gebruikte cryptografie achter deze nieuwe oplossing. Het tweede deel van deze blog gaat in op de architectuur van de oplossing en het laatste deel bestaat uit een voorbeeld van deze nieuwe oplossing met Microsoft Entra Verified ID.

Veel content van deze blog heb ik te danken aan de altijd voortreffelijke uitleg van John Savill in zijn technische trainingen op YouTube. Dus vind je het prettig om een video uitleg over dit onderwerp te bekijken dan raad ik je zijn video Understanding and Using Verifiable Credentials ten zeerste aan.

Indeling

Self-Souvereign Identity

Cryptografie

Public Key Infrastructure (PKI) uitdagingen

x.509 Certificaten

Binding tussen Identifier en public key

De Self-Certifying Identifier Solution

DID Architectuur

DID methods en Verifiable data registries

Key method

Web method

ION method en Trust System

Verifiable Credentials en Verifiable Credentials Data Model

Trust relaties

Het complete plaatje

ION/Sidetree Long form DID

Self Issuing Open ID Connect Provider

Voorbeeld met Entra ID

Conclusie

Self-Souvereign Identity

De wereld van digitale identities kenmerkt zich door centraal opgeslagen identity informatie (claims) zoals bijvoorbeeld voornaam, achternaam, e-mail adres, land, en bijbehorende credentials (gebruikersnaam, wachtwoord). Deze informatie staat vaak bij partijen zoals bijvoorbeeld Microsoft, Google of Facebook, die Identity Provider (IdP) services aanbieden. Als gebruiker heb je geen controle over waar die identity informatie allemaal aangeboden wordt en moet je, om deze te kunnen gebruiken, bewijzen dat je bent die je zegt dat je bent (usernaam/wachtwoord, passkey). Op die manier heb je meerdere digitale credentials bij diverse partijen. Federated Identities lost dit probleem enigszins op door bijvoorbeeld bij Sonos je Google of Facebook account te gebruiken om in te loggen. Risico’s zoals data breaches, privacy schendingen, zoals bijvoorbeeld correlaties leggen tussen applicaties die mijn Facebook account gebruiken en het delen van data (oversharing) blijven bij centraal opgeslagen credentials met claims, bestaan.

In de fysieke wereld daarentegen worden identity informatie en credentials in de vorm van bijvoorbeeld een rijbewijs of paspoort uitgegeven door een algemeen vertrouwde instantie (overheid) en bewaar je deze in een portemonnee. Je bepaalt zelf met wie je deze informatie deelt. De ontvangende partij (relying party, verfier) kan de echtheid (authenticiteit) van de aangeboden credential met identity informatie nagaan door het controleren van bijvoorbeeld een watermerk of hologram op de aangeboden credential. De ontvanger heeft dus geen directe relatie met de uitgever (issuer) van de credential. Door het aanbieden van zo’n credential aan een organisatie (bedrijf waar je voor gaat werken, ziekenhuis, sportclub etc) krijg je vervolgens weer een nieuwe credential om toegang te krijgen tot de betreffende organisatie. In alle gevallen ben jij zelf de eigenaar van de credential en bepaal je zelf aan wie je deze toont.

In een ideale digitale wereld ben je zelf je eigen identity provider, of ben je als organisatie je eigen identity provider. Het kan zijn dat je een digitale identity voor jezelf, voor je huisdier of kind wilt of als organisatie bijvoorbeeld voor je organisatie of voor je gebouw. Je creëert je eigen digitale representatie van jezelf en hebt hier zelf de controle over. Dit wordt ook wel een “Self-Sovereign Identity” genoemd. Je creëert zelf je eigen digitale identity en bepaalt zelf welke identity informatie je met wie deelt.

Cryptografie

Sinds jaar en dag speelt cryptografie een belangrijke rol in de beveiliging van onze communicatie, zo ook in de digitale wereld. Met behulp van hashing en asymmetrische cryptografie kun je zelf je digitale identity informatie (claims) van een digitale handtekening voorzien. Je genereert een public/private key-paar, genereert een hash van je claim(s) en versleutelt deze hash met je private key. Dit is je digitale handtekening.

Je stuurt je claims, versleutelde hash en public key naar de ontvanger. De ontvanger genereert zelf ook een hash van de ontvangen claims, ontsleutelt de ontvangen versleutelde hash met de public key van de aanbieder en controleert of de gegenereerde hash gelijk is aan de ontstleutelde hash. Op deze manier weet de ontvanger of jij inderdaad bent die je beweert te zijn en of de versleutelde informatie tijdens transport niet is aangepast. Deze opzet kent echter twee problemen. Allereerst kan ik wel claims (bijvoorbeeld ik ben ouder dan 18 jaar) over mijzelf maken, maar dat bewijst helemaal niets. Net als in de fysieke wereld is zelf-attest niet echt bruikbaar. Hier kom ik later op terug. Daarnaast kent het gebruik van public/private keys een aantal uitdagingen.

Public Key Infrastructure (PKI) uitdagingen

Ook sinds jaar en dag kent PKI de uitdaging om asymmetrische cryptografie gemakkelijk en veilig te laten gebruiken door organisaties en “mensen”. Het probleem zit hem in de aard van hoe public and private keys werken.

Onderstaand figuur toont de “PKI Trust Angle”

De private key is het deel van het asymmetrische sleutelpaar die de controller onderhoudt en privé houdt zodat de controller dingen kan bewijzen op basis van de relatie met de public key. De public key daarentegen moet gedeeld worden met wie je een veilige relatie wilt onderhouden.

Het probleem hierbij is: “Hoe zorg je ervoor dat de validerende partij weet welke public key bij een specifieke controller hoort?” Ik kan als persoon of organisatie zelf public/private key-paren aanmaken maar hoe bewijs ik dat dat mijn public key is? Het probleem daarbij is o.a. dat controllers geen digitale entiteiten zijn. Het is geen string of bitreeks die je op een of andere manier kunt verifiëren. Controllers zijn dus personen of organisaties die digitaal geïdentificeerd moeten kunnen worden. Ze hebben een Digitale Identifier nodig.

De “PKI trust angle” kent dus 4 elementen:

De Digitale Identifier identificeert de Contoller, de fysieke persoon of organisatie die verantwoordelijk is voor de private key. Een ontvanger van de public key moet er op kunnen vertrouwen dat die public key bij die Controller hoort. Er is dus een betrouwbare koppeling nodig tussen de Controller en de public key. Hiervoor worden x.509 certificaten gebruikt.

Voor meer achtergrondinformatie over x.509 certificaten en hoe een PKI hier een gecentraliseerde oplossing voor biedt lees hieronder verder:  x.509  Certificaten en Binding tussen Identifier en public key.  Deze informatie is echter niet van belang voor het begrijpen van de nieuwe oplossing met Verifiable Credentials, dus je kunt ook direct doorgaan naar Self-Certifying Identifier Solution.

x.509 Certificaten

Een public key infrastructure (PKI) speelt momenteel een belangrijke rol voor het kunnen gebruiken van public/private keys. Essentieel voor een goed werkende PKI is dat ieder individu een globaal unieke naam (Identifier) binnen de PKI heeft. Wanneer ik bijvoorbeeld een beveiligde email naar iemand wil sturen heb ik zijn of haar public key (certificaat) nodig. Ik moet dus kunnen identificeren welk certificaat bij wie hoort.

Op het moment dat x.509 certificaten ontstonden (1988) waren de volgende digitale Identifiers beschikbaar:

Bron: IdentityBook.info special: https://www.youtube.com/watch?v=SHuRRaOBMz4

In x.509 certificaten (die de public key bevatten) wordt een URL of een X.500 distinguished name (DN) als Identifier gebruikt. Het ‘subject distinguished name’ veld in het certificaat bevat de naam van de Identifier waar het certificaat aan toegekend is en vormt daarmee de binding tussen de Identifier en de controller.

Voorbeeld van certificaat met DN:

De relatie tussen de X.500 Directory standaard en x.509 digitale certificaten is nooit echt goed van de grond gekomen.

X.500 is een serie van computernetwerk standaarden voor elektronische directory services. Directory services zijn ontwikkeld om X.400 e-mail uitwisseling en ‘name lookup’ te ondersteunen. Het primaire concept van X.500 is dat er één Directory Information Tree (DIT) bestaat, een hiërarchische organisatie van ‘entries’ die gedistribueerd zijn over een of meerdere servers. Elke entry heeft een unieke Distinguished Name (DN) welke gevormd wordt door z’n Relative Distinguished Name (RDN), een of meerdere attributen van de entry zelf, en de RDN van elk van de superieure entries tot aan de root van de DIT.

Een eindgebruiker die afhankelijk is van een aangeboden certificaat in een browser of e-mail heeft geen eenvoudige manier om een namaak certificaat te onderscheiden van een valide certificaat, zonder de mogelijkheid om de DN te valideren (welke ontworpen was om op te zoeken in een X.500 DIT).

Het certificaat is publiek en kan daarom op een willekeurige manier gedistribueerd worden. Wanneer een x.509 certificaat gebonden zou zijn aan een valide organisatie DN in een globale Directory, dan kan een eenvoudige check uitgevoerd worden over de authenticiteit van het certificaat door te vergelijken wat er in de browser gepresenteerd wordt en wat er in de Directory staat.

De oorspronkelijke gedachte was dat de ‘name space’ geassocieerd met X.500 zou beginnen met een nationale ‘naming authority’, vergelijkbaar met de telefonie (ISO/ITU) aanpak. Verschillende landen zouden hun eigen unieke X.500 services creëren. Zover is het echter nooit gekomen, al wordt in de commerciële wereld veel gebruik gemaakt van X.500. De eerste versie van Microsoft Exchange Server (4.0) was een op X.400 gebaseerd client-server e-mail systeem met ondersteuning voor X.500 directory services. Later werd dit Active Directory, gebouwd op de ‘schouders’ van X.500.

Weliswaar bindt een PKI een publieke sleutel aan een unieke naam, de vertaalslag van gewone naam naar unieke naam is nog steeds onbeveiligd, met alle gevolgen van dien. Bij het uitgeven van een certificaat wordt een Certificate Authority (CA) geacht te controleren of de publieke sleutel en de opgegeven naam inderdaad bij elkaar horen. Deze controle is niet altijd even goed, een hacker kreeg het voor elkaar om een certificaat voor zijn publieke sleutel te krijgen, met daarin Microsoft als ‘zijn’ naam.

In Nederland bestaat het OIN (Organisatie Identificatienummer) voor organisaties die digitaal berichten uitwisselen met de overheid. Dit kunnen publieke en private organisaties zijn. Voorwaarde is dat zij staan ingeschreven in het handelsregister. Daarnaast kunnen ook een aantal organisaties die niet in het handelsregister zijn opgenomen een OIN aanvragen. Dit zijn bijzondere organisaties met een publieke taak, colleges van advies en internationale organisaties met een rechtspersoonlijkheid.

Het OIN-nummer wordt als identificerend nummer gebruikt in PKI overheid certificaten (authenticatie), in de adressering en routering van berichten, en in autorisatietabellen. Het OIN wordt geregistreerd in het subject.serialNumber veld van het certificaat.

Logius is beheerder van de Centrale OIN Raadpleegvoorziening (COR) (inclusief het OIN-register) in opdracht van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties.

Een vertrouwensdienstverlener (TSP) geeft certificaten uit conform de eisen uit het programma van eisen van PKIoverheid. Daarmee zijn zij verantwoordelijk voor de betrouwbaarheid van de genoemde certificaten. De TSP’s doen met het oog op het uitgeven van een certificaat onderzoek naar de identiteit van de organisatie en de tekenbevoegdheid van de aanvragers van een certificaat. Tevens controleren zij de identiteit van de aanvrager op grond van een face to face controle. De TSP raadpleegt het OIN van de aanvrager via de COR en neemt dit nummer en naam op in het PKIoverheid certificaat.

Certificeringsinstanties zijn dus vertrouwde externe partijen die TLS/SSL-certificaten uitgeven na authenticatie van bepaalde gegevens van een website en de eigenaar ervan. Ze verifiëren het eigendom en de identiteit van het bedrijf of de persoon die eigenaar is van de URL. Hiervoor bestaan drie soorten SSL-certificaten: Domain Validated (DV), Organization Validated (OV) en Extended Validation (EV). Voor meer informatie over deze validatie type zie Wat is het verschil tussen DV, OV en EV SSL-certificaten? (digicert.com).

Binding tussen Identifier en public key

Naast een binding tussen de Identifier en de controller is er ook een binding nodig tussen de Identifier en de public key. Je moet kunnen bewijzen dat die public key bij “jou” hoort. De voor de hand liggende oplossing is gebruik te maken van cryptografie, een digitale handtekening. Maar de digitale handtekening van wie? Niet die van de controller want dan kan deze de public key aan elke willekeurige identifier binden. Dus wie vertrouw je daarvoor?

De PKI oplossing maakt gebruik van een vertrouwde derde partij die de binding tussen de Identifier en de public key signed met ‘haar’ private key. Dit is de rol van de Certificate Authority (CA).

Een x.509 certificaat bindt dus de Digitale Identifier aan een public key middels een digitale handtekening van de CA. Het certificaat bevat een Identifier (een hostname, organisatie of individu) en wordt door een CA van een digitale handtekening voorzien. Iemand in het bezit van een dergelijk certificaat kan de public key gebruiken om een veilige communicatie met een andere partij op te zetten of documenten valideren die digitaal ondertekend zijn met de corresponderende private key. De koppeling tussen de Identifier en de gebruikte public key wordt gevalideerd door de digitale handtekening van de CA te controleren met de public key van de CA.

Deze certificaten met de public key van publieke CA’s zijn in een certificate store opgeslagen en worden bijvoorbeeld door de browser gebruikt voor de validatie van een aangeboden certificaat bij een SSL/TLS (https) sessie.

Deze oplossing kent echter een aantal problemen, zie ook een artikel van dr. Jaap-Henk Hoepman, “PKI: vloek of zegen?”. https://www.cs.ru.nl/~jhh/publications/pki-answer.pdf

• Afhankelijkheid van mensen. De PKI-oplossing staat of valt met het vertrouwen in de CA die beheerd wordt door een organisatie.
• ‘Betrouwbare’ publieke Certificaten kosten vaak geld.
• Het is een gecentraliseerde oplossing wat een single point of failure met zich meebrengt.
• Identifiers (unieke namen binnen een PKI) kunnen veranderen. Dit vereist nieuwe of aangepaste certificaten en dus nieuwe public keys, waarbij herleidbaarheid naar de oude naam gewaarborgd moet worden. Ook key rotaties zorgen voor nieuwe of aangepaste certificaten.

De noodzaak voor unieke globale Identifier (ID) schemas zijn al vaak geadresseerd. Globaal unieke ID schema’s zijn afhankelijk van een autoriteit die een ‘root’ deel controleert en sub-delen delegeert naar een organisatie. Er is dus een centrale autoriteit waar het ID-systeem afhankelijk van is.

Deze centrale autoriteiten zullen alle mogelijke middelen inzetten om hun Identifiers ‘persistant’ en ‘resolvable’ te maken, maar wat als die centrale autoriteit stopt te bestaan? De enige manier om na te gaan of een specifieke Identifier valide is, is door de uitgevende partij te bevragen.

Deze factoren leiden ertoe dat er behoefte is aan een globaal unieke Identifier die zelf-soeverein is, een ID die niet afhankelijk is van een uitgevende partij. Een standaard zoals Universally Unique Identifier (UUIDs) [RFC4122], voldoet hieraan, maar is niet resolvable en niet cryptografisch verifieerbaar.

Een nieuw type Identifier moet dan ook aan een 4-tal basis principes voldoen:

1. Decentralized: Er moet geen centrale uitgevende partij bij betrokken zijn.
2. Persistent: De Identifier moet kunnen blijven bestaan zonder afhankelijkheid van de voorzetting van de werking van een onderliggende organisatie.
3. Cryptographically verifiable: Middels cryptografie moet controle over Identifier bewezen kunnen worden.
4. Resolvable: Het moet mogelijk zijn om metadata over de Identifier te vinden.

Dit nieuwe type Identifier wordt een Decentralized Identifier (DID) genoemd.

De Self-Certifying Identifier Solution

We zijn bekend met globaal unieke Identifiers in veel verschillende contexten. Denk aan telefoonnummers, adressen, email adressen, ID-nummers op paspoorten maar ook bijvoorbeeld serienummers van apparaten en RFIDs. URIs  (Uniform Resource Identifiers) worden gebruikt voor identificatie van resources op het web en URLs voor het lokaliseren van webpagina’s.

Je hebt zelf geen controle over de meeste van deze globaal unieke identifiers. Ze worden uitgegeven door externe partijen die de macht hebben om daar mee te doen wat ze willen, deze bijvoorbeeld in te trekken, lekken naar andere partijen of slecht beveiligd zijn waardoor ze door frauduleuze partijen gestolen worden (identiteitsdiefstal).

De Decentralized Identifiers (DIDs) zijn een nieuwe type globaal unique identifiers, ontworpen om individuen en organisaties hun eigen identifiers te laten generen gebruik makend van een systeem wat het individu of de organisatie vertrouwt.  Entiteiten kunnen hun eigen DIDs beheren door zich te authentiseren met bijvoorbeeld een private key.

Omdat de creatie en assertion (bewering) van DIDs door entiteiten zelf beheerd worden, kan iedere entiteit zoveel DIDs hebben als nodig is om hun scheiding van identities, personen, en interacties te onderhouden. Het gebruik van deze identifiers kunnen voor verschillende contexten gebruikt worden. Ze ondersteunen interacties met andere personen, instituten, of systemen die van entiteiten eisen zich te identificeren, of andere dingen te geven, met tegelijkertijd controle over hoeveel persoonlijke of privé data vrijgegeven moet worden, zonder afhankelijk te zijn van een centrale autoriteit om de continue bestaanszekerheid van de identifier te waarborgen.

Zoals aangegeven moet een DID cryptographically verifiable zijn. Een verifier moet kunnen nagaan dat de public key van een DID bij die DID hoort, zodat de eigenaar van de DID met de private key kan bewijzen dat hij inderdaad de controller is van de DID. De vraag is dus hoe bind je de DID aan de controller en hoe bind je de DID aan de public key?

Met de reguliere PKI-oplossing wordt dit, zoals eerder uitgelegd, opgelost met de CA. De nieuwe oplossing bestaat uit een zelf gecreëerde Decentralized Identifier (DID) die verbonden wordt met de public key d.m.v. cryptografie.

De DID wordt (wiskundig) gegenereerd door de public key d.m.v. een DID method. Wanneer de public key de DID genereert zijn deze mathematisch met elkaar verbonden. Een DID method moet (wiskundig) bewijzen dat ‘control’ over het private/public key paar ook ‘control’ over de DID impliceert.

Het enige wat hiermee nog niet opgelost is, is key rotation. Wanneer je je keys roteert krijg je een nieuwe identifier, terwijl deze juist persistant moet zijn! Key rotation speelt een belangrijke rol, zeker omdat het kraken van keys met toenemende computerkracht steeds minder tijd kost.

Voor de oplossing van dit probleem (mogelijk maken van key rotation) speelt een ‘DID document’ een belangrijke rol. Een DID document bevat informatie over een DID, bijvoorbeeld de DID zelf, de public key en services (service endpoints) die relevant zijn om te communiceren met de DID.

Een DID wordt gegeneerd door een controller (bijvoorbeeld ik zelf, of een organisatie). De DID controller genereert het orginele (genesis) public/private key paar en met de public key wordt de DID gegenereerd. Vervolgens creëert de controller het bijbehorende DID document, ondertekent dit met de private key en publiceert het DID document wat zowel de DID als de public key bevat.

Het DID document wordt gesigned met de eerste private key (1). Na een key rotatie wordt er een nieuw versie (update) van het DID document gepubliceerd met de nieuwe public key (2). Dit document wordt gesigned met private key (1). Bij de volgende key rotatie wordt het DID document met public key (3) gesigned door private key (2). Dit kan oneindig herhaald worden.

Public key 3 moet afkomstig zijn van diegene die private key 2 in bezig heeft. Public Key 2 moet op zijn beurt afkomstig zijn van diegene die private key 1 in bezit heeft, en Public Key 1 moet ook afkomstig zijn van diegene die private key 1 in bezit heeft.

Deze oplossing vormt een chain of trust tussen DID Document versies die terug herleidt naar de originele self-certifying identifier.

Het DID document fungeert dus als digitaal certificaat voor de nieuwe public key. DID documenten fungeren als gedecentraliseerde digitale certificaten zonder tussenkomst van een CA of een of andere derde partij!

Deze oplossing biedt ook een oplossing voor het beheren van een digitale identifier voor iets of iemand anders dan jezelf.

De controller creëert een key-paar en de DID, maar gebruikt dit om iemand anders te identificeren bijvoorbeeld een minderjarig kind. De controller onderhoudt het DID Document totdat het kind meerderjarig is en zelf een key-paar genereert. Het kind vraagt de ouder om ‘zijn/haar’ public key in het DID document te publiceren en de overdracht is voltooid.

DID Architectuur

Het World Wide Web Consortium (https://www.w3.org/TR/did-core/#introduction) schrijft geen expliciete technologie of cryptologie voor, voor de creatie, bestaanszekerheid, vindbaarheid en interpretatie van DIDs.

“For example, implementers can create Decentralized Identifiers based on identifiers registered in federated or centralized identity management systems. Indeed, almost all types of identifier systems can add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers. This also enables implementers to design specific types of DIDs to work with the computing infrastructure they trust, such as distributed ledgers, decentralized file systems, distributed databases, and peer-to-peer networks.”

Een DID is een eenvoudige tekst string (URI, uniform resource identifier) bestaande uit 3 delen:

1. De DID URI schema identifier (did)
2. De Identifier voor de DID method

De DID method specifieke identifier

Bron: Decentralized Identifiers (DIDs) v1.0 (w3.org)

De DID leidt (resolves to) naar een DID document. Een DID document bevat informatie geassocieerd met de DID, o.a. de manier(en) waarop een DID controller zich cryptografisch kan authenticeren om vervolgens een DID document aan te kunnen passen.

Een DID URL is een uitgebreide DID URI met andere standaard URI componenten, bestaande uit path, query en fragment, om bijvoorbeeld de public key in een DID document, of een resource buiten het DID document te kunnen lokaliseren.

Voorbeeld van een DID query URL; did:example:123456?versionId=1

Uniform resource names (URNs) zijn blijvende namen voor een resource die nooit veranderen ongeacht de locatie van de resource. Een DID is functioneel een URN die tevens een cryptografisch veilige, locatie-onafhankelijke, identificatie voor een digitale bron biedt.

Onderstaand figuur toon een schematisch overzicht van de belangrijkste componenten van een DID architectuur.

Bron: Decentralized Identifiers (DIDs) v1.0 (w3.org)

Een DID (URI) representeert dus jezelf, je hond, een bedrijf, etcetera. Onderstaand overzicht geeft schematisch de relatie weer  tussen DIDs, DID documents en DID subjects.

Bron: https://www.youtube.com/watch?v=SHuRRaOBMz4

Het DID document bevat datgene wat nodig is om met het subject te communiceren. Het DID document triggert een vorm van interactie d.m.v. een soort van protocol om bijvoorbeeld verifiable credentials (hierover verderop meer) uit te wisselen, connecties te maken, of ander type boodschappen uit te wisselen.

Het idee is dat informatie gekoppeld aan een DID op eenzelfde soort manier verkregen kan worden als de manier waarop een IP adres verkregen wordt die aan een domeinnaam gekoppeld zit (DNS).

Onderstaand overzicht geeft een vergelijking tussen DIDS en domein namen:

Bron: https://www.youtube.com/watch?v=SHuRRaOBMz4

DID methods en Verifiable data registries (Trust System)

Een DID method bestaat uit een DID method specificatie die de operaties specificeren waarmee DIDs en DID documents worden gecreëerd, resolved, geupdate, en gedeactiveerd.

DIDs worden niet gemaakt en onderhouden in een enkele database of netwerk zoals de meeste URIs. Er bestaan veel verschillende DID methods die allemaal dezelfde basis functionaliteit ondersteunen maar verschillen in hoe deze functionaliteit is geïmplementeerd.

Deze URL, https://www.w3.org/TR/did-spec-registries/#did-methods bevat een tabel van alle DID methods die momenteel in ontwikkeling zijn. Ik ga hieronder dieper in op enkele van deze methodes.

Key method

De meest rudimentaire vorm van een DID method is de “key” method (The did:key Method v0.7 (w3c-ccg.github.io)). Deze method heeft inmiddels de status van “unoffical draft”, omdat bij deze method key rotation niet mogelijk is.

De method naam is ‘key’, en een DID die deze methode gebruikt begint met de prefix ‘did:key’.
De rest van de DID bestaat uit een encoded public key, bijvoorbeeld:

did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Het creëren van de did:key waarde bestaat uit het creëren van een cryptografisch key paar, en vervolgens het encoden van de public key volgens een bepaald format. Ook het maken van het DID document bestaat dan uit het plaatsen van de public key in het DID document.

Voorbeeld:

{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1",
"https://w3id.org/security/suites/x25519-2020/v1"
],
"id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"verificationMethod": [{
"id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"type": "Ed25519VerificationKey2020",
"controller": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
}],
"authentication": [
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
],
"assertionMethod": [
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
],
"capabilityDelegation": [
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
],
"capabilityInvocation": [
"did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
],
"keyAgreement": [{
"id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6LSj72tK8brWgZja8NLRwPigth2T9QRiG1uH9oKZuKjdh9p",
"type": "X25519KeyAgreementKey2020",
"controller": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"publicKeyMultibase": "z6LSj72tK8brWgZja8NLRwPigth2T9QRiG1uH9oKZuKjdh9p"
}]
}

Probleem is dus dat dit alleen een “generatieve” method is, er bestaat geen manier om de keys te roteren (rotatie genereert een nieuwe DID) of de DID te deactiveren. Daarom wordt dit niet als een bruikbare method beschouwd.

Web method

Met de Web method wordt het DID document opgeslagen op een webserver van de issuer. Een webserver, gebruikmakend van DNS en PKI infrastructuur, wordt hier dus gebruikt als ‘verifiable data registry’ of in Microsoft terminologie ‘Trust System’ genaamd.

De method naam is ‘web’, en een DID die deze methode gebruikt begint met de prefix ‘did:web:’.

De DID method specifieke identifier is een full qualified domain name (fqdn) beveiligd met een TLS/SSL certificaat met optioneel een path naar het DID document.

Voorbeeld: did:web:mstack.nl

Het DID document, in JSON formaat (did.json), wordt opgeslagen op de webserver in het path ‘/.well-known’ wanneer de DID het hele domein (de organisatie) representeert of onder een specifiek path wanneer meerdere DIDs opgeslagen worden in het domein.

Voor het domein mstack.nl zal dan het DID document beschikbaar zijn door de volgende URL: https://mstack.nl/.well-known/did.json.

Voor een medewerker met als DID:
did:web:mstack.nl:medewerker:willy-jan zal het DID document beschikbaar zijn onder de URL: https://mstack.nl/medewerker/willy-jan/did.json

Zie voor meer informatie over de web method: https://w3c-ccg.github.io/did-method-web

ION method

ION staat voor Identity Overlay Network en is een implementatie van het SiteTree protocol gebaseerd op bitcoin blockchains en ontwikkeld door leden van de DIF. Het is een publiek decentralized identity management systeem niet gecontroleerd door een organisatie en in staat om duizenden transacties per seconde te verwerken.

In 2017 zijn leden van de Decentralized Identity Foundation (DIF) begonnen met een oplossing voor het ‘managen’ van DIDs met blockchains^(*) als registries. Het idee is om een eigenaar van een credential deze te laten registreren op een blockchain, zodat deze geverifieerd en gemonitord kunnen worden door de eigenaar zelf. Blockchains passen goed in deze behoefte, en verschillende projecten rondom decentralized identity hebben dit type technologie gebruikt voor het managen van een DID.

^(*) a technology of storage and transmission of information, transparent, secured and operating without a central review body (source: https://blockchainfrance.net/decouvrir-la-blockchain/c-est-quoi-la-blockchain/

Doel van de bitcoin blockchain was om een virtuele munt te maken zonder enige vorm van centrale regelgeving. Het systeem wordt gecontroleerd en beheert door de community leden op een volledig gedecentraliseerde manier. Elke transactie op een blockchain leidt tot een ‘inscriptie’ in een block, wordt opgeslagen in een registry en gedeeld met alle leden. Deze inscriptie wordt uitgevoerd door “minors” die de transactie in de blockchain controleren, registreren en beveiligen. Deze database bevat alle transacties in blocks, wat leidt tot een ketting van blocks die onveranderbaar en onschendbaar is vanwege de electronische handtekeningen, en herverdeeld is op het netwerk vanwege de gedecentraliseerdheid.

Blockchain kent echter een probleem wat bekend staat als “het blockchain trilemma”. Dit trilemma beschrijft de drie belangrijkste kenmerken van een blockchain, decentralisatie, schaalbaarheid en veiligheid, terwijl een blockchain eigenlijk maar aan twee kan voldoen. Zie Het blockchain trilemma uitgelegd | Bitvavo

Om een identity systeem op globale schaal te kunnen laten werken moet het schaalbaar zijn. Hiervoor zijn oplossingen bedacht en gebouwd “on top of” een bestaande blockchain, welke bestaan uit het samenvoegen van verschillende operaties in een enkele transactie. Deze oplossing verhoogt het aantal transacties wat per seconde kan worden geprocessed. Deze oplossingen worden aangeduid met ‘layer 2’.

Leden van de DIF hebben een ‘layer 2’ protocol ontwikkeld, SiteTree genaamd, voor het managen van decentralized identities. Dit protocol kan worden toegepast op verschillende soorten onderliggende blockchains.

SideTree is gebouwd met verschillende software componenten:

• REST API: een interface voor interactie met gebruikers
• SiteTree Core: Het logische deel van het systeem wat de verschillende operaties op de identifiers mogelijk maakt.
• Content Addressable Storage: Voor het opslaan van de identifiers met hun metadata. SideTree gebuikt het InterPlanetary File System (IPFS)^(**) protocol wat het mogelijk maakt om op een gedecentraliseerde manier data te distribueren en op te slaan.
• Blockchain Adapter: Voor het communiceren met de onderliggende blockchain waar de status van een transactie bijgehouden wordt.

^(**)InterPlanetary File System (IPFS)

IPFS is een modulaire reeks protocollen voor het organiseren en overbrengen van gegevens, vanaf de basis ontworpen met de principes van ‘Content Addressable Storage’ (CAS) en peer-to-peer-netwerken. Content-addressed storage of fixed-content storage, is een manier voor het bewaren van informatie zodat deze opgevraagd kan worden op basis van de inhoud en niet op basis van de naam of locatie.

Omdat IPFS open-source is, zijn er meerdere implementaties van IPFS. Hoewel IPFS meer dan één gebruiksscenario heeft, is het belangrijkste gebruiksscenario het publiceren van gegevens (bestanden, mappen, websites, enz.) op een gedecentraliseerde manier. Voor meer informatie zie ook: https://allesovercrypto.nl/blog/interplanetary-file-system-ipfs

Onderstaand figuur toont een schematisch overzicht van het CAS netwerk, het sidetree netwerk en een onderliggende blockchain.

Bron: DIF Sidetree Protocol (identity.foundation)

Door gebruik te maken van het blockchain-agnostische Sidetree-protocol, maakt ION het mogelijk om tienduizenden DID/DPKI (Decentralized Public Key Infrastructure )-operaties op een blockchain (in het geval van ION, Bitcoin) te verankeren met behulp van een enkele Bitcoin blockchain transactie. De transacties worden gecodeerd met een hash die ION-knooppunten gebruiken om de hash-geassocieerde DID-bewerkingsbatches via IPFS op te halen, op te slaan en te repliceren. De knooppunten verwerken deze bewerkingsbatches in overeenstemming met een specifieke reeks deterministische regels die hen in staat stellen onafhankelijk de juiste DPKI-status voor ID’s in het systeem te bereiken, zonder dat hiervoor een afzonderlijk consensusmechanisme, blockchain of sidechain nodig is. Knooppunten kunnen DID-statussen parallel ophalen, verwerken en samenstellen, waardoor de totale capaciteit van knooppunten tienduizenden bewerkingen per seconde kan uitvoeren.

Voor een DID gebaseerd op ION is de method naam ‘ion’ en is de prefix dus ‘did:ion:’. De DID method specifieke identifier bestaat uit een unieke reeks van een complexe serie karakters:

did:ion:EiD3DIbDgBCajj2zCkE48x74FKTV9_Dcu1u_imzZddDKfg

De DID is gekoppeld aan een JSON document (het DID document).

De eigenaar kan eigenschappen aan het DID document toevoegen door gebruik te maken van de REST API van een ION node.

Om een DID te genereren moet de gebruiker een eigen ION node of op het netwerk beschikbare ION node gebruiken. De node operator moet een wallet met Bitcoin hebben omdat de operatie een transactie vereist. Het managen van identifiers betekent het uitvoeren van meerder stappen via een REST API en is complex.

Elke identifier is gelinkt aan 3 paren van cryptografische sleutels.

• Update keys
• Recovery keys
• Signature keys

De uitgevoerde operaties gedurende het aanmaken worden opgeslagen in een file. Deze instructie file wordt gedistribueerd op IPFS, en de bijbehorende unieke identifier wordt opgeslagen in een Bitcoin transactie. Gelijktijdige operaties op meerdere identifiers worden gegroepeerd, en uitgevoerd als een enkele Bitcoin transactie. SideTree gebruikt ‘Merkel trees’ voor het structureren van de statussen van de veschillende identifiers, en zorgt voor het managen van een groot aantal operaties per transacties.

Alle andere nodes in het ION netwerk observeren Bitcoin transacties en extraheren degenen die overeenkomen met het ION protocol. Ze ontvangen de instructie file van IPFS m.b.v. de unieke identifier in de transactie. Vervolgens voeren zij de instructies uit zodat ze de laatste gecreëerde identifiers bevatten. Op deze manier worden nieuwe identifiers gedistribueerd door het netwerk. Deze synchronisatie kan wel enige tijd in beslag nemen.

Microsoft heeft in December 2023 de configuratieoptie voor ION als trust system verwijderd. Zie https://learn.microsoft.com/en-us/entra/verified-id/whats-new#december-2023 Het is mij onduidelijk wat de reden hiervan is en of dit tijdelijk of permanent is.

Met de DID standaard en verschillende methoden om deze te creëren en managen is een Self-Souvereign Identity realiteit geworden. Probleem is echter: wie vertrouwt deze eigen gecreëerde identities? Zelf attestatie gaat niet werken. Om dit op te lossen zijn Verifiable Credentials en het Verifiable Credentials Data Model bedacht.

Verifiable Credentials en Verifiable Credentials Data Model

Credentials maken deel uit van ons dagelijks leven. Een rijbewijs bewijst dat we in staat zijn een motorvoertuig te besturen. Een schooldiploma kan gebruikt worden om een niveau van opleiding te bewijzen en een paspoort stelt ons in staat te reizen tussen verschillende landen. Deze credentials bieden ons voordelen in de fysieke wereld maar bruikbaarheid in de digitale wereld blijft vooralsnog beperkt.

Tot voor kort was het moeilijk om opleidingskwalificaties, gezondheidsdata, financiële account details, en andere vormen van derde partijen geverifieerde, machine leesbare, informatie digitaal ‘uit te drukken’ op het web.

Het Verifiable Credentials Data Model (https://www.w3.org/TR/vc-data-model-2.0/) beidt een standaard voor het uitdrukken van credentials op het web, op een manier die cryptografisch veilig, privacy respectvol en machine verifieerbaar is.

Voorbeelden van credential informatie in de fysieke wereld:

• Informatie gerelateerd aan het subject van de credential (bijvoorbeeld een naam, foto, of identificatie nummer)
• Informatie gerelateerd aan een uitgevende instantie van de credential (bijvoorbeeld een gemeente, bedrijf, of ziekenhuis)
• Informatie gerelateerd aan het type credential (bijvoorbeeld, Nederlands paspoort, Amerikaans rijbewijs, of een ziekenhuis pas)
• Informatie gerelateerd een specifieke eigenschappen van het subject van de credential die beweert worden door de uitgevende partij van de credential (bijvoorbeeld nationaliteit, welke voertuigen je mag besturen, geboortedatum)
• Bewijs over hoe de credential verkregen is
• Beperkingen over de credential (bijvoorbeeld geldigheidsduur, gebruikersvoorwaarden)

Een Verifiable Credential kan dezelfde informatie representeren als een fysieke credential. De toevoeging van technieken zoals digitale handtekeningen maken Verifiable Credentials zelfs betrouwbaarder en fraudebestendiger dan de fysieke tegenhanger.

Het Verifiable Credentials data model kent de volgende rollen:

Zoals eerder beschreven (zie DID architectuur), wordt een subject gedefineerd door een decentrialized identifier (DID), oftewel een overdraagbare, URL gebaseerde, identifier, verankerd in een verifiable data repository (registry). Deze repository bestaat veelal uit een gedistribueerd systeem zoals een blockchain, soms aangeduid als Decentralized Public Key Infrastructure (DPKI), maar kan als alternatief echter ook afhankelijk zijn van een meer traditionele oplossing zoals de DNS infrastructuur.

Trust relaties

Net als in een centralized identity model spelen ook in een decentralized identity model vertrouwensrelaties een belangrijke rol. In een decentralized identity model ben je zelf de holder van de verifiable credential/claim. De issuer (uitgever van de credential/claim) vertrouwt de holder. Dit kan bijvoorbeeld doordat de holder zich identificeert bij de issuer dan wel digitaal dan wel fysiek.

De holder vertrouwt de verifier (ontvanger van de crendential/claim). De verifier heeft geen directe vertrouwensrelatie met de issuer. Om de verifier in staat te stellen de credential/claim te verifiëren schrijft de issuer informatie over de credential weg in de ‘verifiable data registry’. Deze registry bevat cryptografische informatie (public key in DID document) die de verifier kan lezen en daarmee na kan gaan of de aangeboden credential/claim inderdaad van de issuer komt en niet veranderd is.

De Issuer creëert een verifiable credential/claim voor een subject en moet bewijzen dat het van de issuer komt, en dat de verifiable credential/claim die de verifier van de holder ontvangt, niet veranderd is. De issuer heeft dus een zelf gegeneerde betrouwbare identifier nodig die de verifier naar de public key van de issuer loodst, zonder dat de verifier een directe vertrouwensrelatie met de issuer of een centrale autoriteit heeft. Hiervoor wordt de DID met bijbehorend DID method en DID document gebruikt!

Het complete plaatje

Alle bovenstaande beschreven theorie komt samen in het volgende overzicht over het gebruik van Verifiable Credentials.

1. De Issuer geeft Verifiable Credentials uit en heeft zijn eigen DID. De DID ‘resolved’ naar een DID-document in een Trust System, gebaseerd op bijvoorbeeld blockchain, ION, Web of een andere technologie. Het DID-document bevat de public key van de DID van de Issuer.
2. De Holder is diegene die een Verifiable Credential wil (bijvoorbeeld ik zelf), van een Issuer en deze vervolgens aan een Verfier kan geven om bepaalde ‘rechten’ te krijgen, bijvoorbeeld korting bij een Webshop omdat ik een werknemer ben van de alfa1 groep. Om een Verifiable Credential request naar de Issuer te kunnen sturen heeft de Holder een z.g.n. useragent nodig. Met Microsoft technologie is dat de authenticator app. Zodra ik vanuit de authenticator een Verifiable Credential-request start, genereert de authenticator een public/private key paar en slaat de private key op in een beveiligde enclave van je mobiel. Vervolgens creëert de authenticator een DID. Hiervoor gebruikt de authenticator de ION methode die gebaseerd is op het sidetree protocol. I.p.v. een short-form DID-URI gebruikt de authenticator de long form DID-URI (zie verderop long form DID-URI⁾ welke ook het (encoded) DID-document bevat. Dit DID-document wordt dus niet geankerd in het Trust System. Deze DID is een identifier voor mijzelf (mijn portemonee). Wat ik over mezelf roep is niet van belang. Het gaat erom wat anderen (de issuer) over mij zeggen. Ik heb nu een DID in mijn wallet die mij representeert als subject van een verifiable credential uitgegeven door een issuer.
3. De Issuer ontvangt een Verifiable Credential-request van de Controller. Ik moet wel ‘bewijzen’ wie ik ben. Het kan zijn dat ik al een Verifiable Credential heb van een andere partij die de Issuer vertrouwt, of ik moet eerst een authenticatie proces doorlopen voordat ik een dergelijk Verifiable Credential-request kan sturen. Afhankelijk van mijn type request kan het ook zijn dat ik zelfs fysiek naar een kantoor moet komen. Er is iets van een bootstrapping nodig om de initiële permissies te krijgen. Na de authenticatie maakt de Issuer een Verifiable Credential aan voor de DID van de Controller. De Verifiable Credential bevat informatie zoals de DID van de Issuer zelf, de DID van het subject (in dit voorbeeld is het subject de DID van de Controller zelf), en een aantal claims over het subject. De Issuer ‘signed’ de Verifiable Credential en stuurt het naar de Controller, die de Verifiable Credential in zijn portemonee bewaart. De Verifiable Credential wordt niet door de Issuer bewaard en ook niet in een ledger opgeslagen. De Controller is de enige die in het bezit is van de Verifiable Credential! De Verifiable Credential is gegenereerd door de issuer en het bewijs is verankerd in het Trust System.
4. Nu wil ik mijn Verifiable Credential gebruiken. Ik ga bijvoorbeeld naar een Website waar ik als medewerker van de Alfa1 groep met korting een laptop kan bestellen. Die Website stuurt mij een verifiable presentation-request via OIDC-SIOP (zie verderop Self Issuing Open ID Connect Provider.
5. De Controller creëert een Verifiable Presentation welke de Verifiable Credential bevat (een Verifiable Presentation kan ook meerdere Verifiable Credentials bevatten), ‘signed’ de Verifiable Presentation met zijn private key en stuurt deze samen met het DID document naar de verifier.
6. De verifier gebruikt een DID universal resolver voor het ophalen van de DID documenten van de Issuer en de Controller. Deze resolver gebruikt de DID-URI om de DID documenten te vinden. Voor de Issuer wordt deze uit het Trust Sytem gehaald en voor de Controller bevat de DID-URI ook het DID-Document.
   De verifier gebruikt nu de public keys uit de DID documenten om te verifiëren of de DID uit de Verifiable Credential (subject) overeenkomt met de DID van diegene die hem de Verifiable Credential stuurt (DID van de holder) en of de Verifiable Credential inderdaad van de Issuer komt die in de Verifiable Credential staat.

Eindresultaat: De Verfier en de Issuer hebben niet direct met elkaar gecommuniceerd. De Controller heeft complete control over de Verifiable Credential. Hij/zij bepaalt welke Verifiable Credential hij/zij deelt. In de toekomst wordt gedacht aan scenario’s zoals selective presentation, waarbij je bijvoorbeeld 1 claim uit alle aangeboden claims kunt selecteren om aan te bieden aan de verifier. Of zero knowlegde proof, bijvoorbeeld ik ben ouder dan 18 zonder je geboortedatum te delen.

ION/Sidetree Long form DID

Bij veel DID methodes kan het enige tijd duren (of helemaal niet gebeuren) voordat een gegenereerde DID daadwerkelijk verankerd is het onderliggende opslag systeem. Om dit te adresseren kent het Sidetree protocol een variant op de Sidetree gebaseerde DIDs die ‘self-certifying’en ‘self-resolving’ zijn en bekend zijn als Long-Form DID URI. Deze Long-Form DID URI variant maakt het mogelijk dat DIDs onmiddellijk ‘resolvable’ zijn nadat ze aangemaakt zijn door de DIDs initiële data (o.a. bijvoorbeeld de public key) direct toe te voegen aan de Long-Form DID URI.

De Sidetree Long-Form DID URI bestaat uit de ‘normale’ Short-Form DID URI met een extra, door dubbele punt (:) gescheiden segment aan het einde. Dit segment bevat de encoded JSON data van de DID create operatie (waaronder de public key).  Voor meer info zie: DIF Sidetree Protocol (identity.foundation), §9.1 Long-Form DID URIs.

Microsoft gebruikt de Sidetree Long-Form DID in de authenticator app. De resolver probeert eerst een nieuwe versie van de DID te vinden in de ledger en als de DID daar niet gevonden wordt gebruikt de resolver de versie die encoded zit in de long-form state.

Self Issuing Open ID Connect Provider

Open ID Connect (OIDC) is een veel gebruikt authenticatie en autorisatie protocol op het internet. OIDC maakt gebruikt van een centrale Identity Provider (bijvoorbeeld Entra ID) die een gebruiker authentiseert en het verkregen token naar een relying party (verifier) stuurt. Een typische OIDC login flow ziet er als volgt uit:

Bron: Where to begin with OIDC and SIOP | by Kaliya-IdentityWoman | Decentralized Identity Foundation | Medium)

OIDC-SIOP (Self Issuing Open ID Connect Provider) is een extensie van Open ID Connect om eindgebruikers te kunnen laten acteren als OpenID Providers (OPs). Door gebruik te maken van self issued OPs kunnen eindgebruikers zichzelf authentiseren en direct claims aan een relying party presenteren, veelal een webapplicatie, zonder afhankelijk te zijn van een externe Identity Provider. Dit maakt deze oplossing volledig zelf soeverein, omdat het niet afhankelijk is van een andere partij en strikt peer 2 peer communiceert, maar toch gebruik maakt van het OpenID Connect protocol.

Bron: Where to begin with OIDC and SIOP | by Kaliya-IdentityWoman | Decentralized Identity Foundation | Medium

OIDC-SIOP maakt het voor een verifier mogelijk om Verifiabele Credentials uit een ‘wallet’ van een individu te vragen in plaats van een token van een centrale Identity Provider (Microsoft, Google, Facebook, Github) . Op de website van de OIDC workgroup vind je de OIDC-SIOP specificatie.

Bron: OpenID for Verifiable Presentations – draft 20

(1) De verifier stuurt een autorisatie request naar de wallet. Het autorisatie request beschrijft de eisen (type credential, format credentials, welke claims) van de te presenteren credential. De wallet processed het request en bepaalt welke credentials beschikbaar zijn op basis van de gevraagde eisen uit het request. Ook authenticeert de wallet de gebruiker en vraagt de gebruiker om consent voor het versturen van de credential.

(2) De wallet maakt de verifiable presentation van de verifiable credential waarvoor de gebruiker consent heeft gegeven. Vervolgens stuurt de wallet een authorisatie response, bestaande uit de verifiable presentation(s), in het verifiable presentation token (VP token).

Voorbeeld met Entra ID

De Microsoft Entra Verified IS service is een Issuer en Verifier service in Azure en REST API voor verifiable credentials signed met de did:web method. Deze service maakt het mogelijk om claims, onder controle van de eigenaar, te creëren, presenteren en verifiëren.

Microsoft heeft diverse voorbeelden gepubliceerd voor het werken met verifiable credentials

Issuer service communication examples – Microsoft Entra Verified ID | Microsoft Learn

Met behulp van een quick setup ‘enable’ je de Entra Verified ID service binnen enkele minuten.

De ‘quick setup’ gebruikt een shared private key beheerd door Microsoft en is maximaal 6 maanden geldig. De DID van je organisatie (issuer) krijgt een naam did:web:verifiedid.entra.microsoft.com:tenantid:authority-id en gebruikt de did:web specificatie.

Zie ook Tutorial – Quick setup of your tenant for Microsoft Entra Verified ID (Preview) – Microsoft Entra Verified ID | Microsoft Learn

Via het Microsoft Entra ID Admin Center https://entra.microsoft.com, ga je in het menu naar Verified ID:

Na het starten van de Get Started button is je Microsoft ID tenant geconfigureerd als een Issuer voor verifiable credentials.

Eventueel kun je de opmaak van de creditcard naar eigen wens aanpassen:

Met de authenticator app, (menu verfiable credentials) kun je verifiable credential ophalen via de MyAccount website (myaccount.microsoft.com). Het bootstrap proces bestaat hier dus uit het inloggen op je tenant. Het type verifiable credential is “Verified Employee”. Hiermee krijg je een Verifiable Credential waarmee je kunt bewijzen dat je werknemer bent van de organisatie.

Open de authenticator app en ga naar Geverifieerde Ids en scan de QR image.

Je Verifiable Credential wordt nu opgeslagen in je authenticator, en op de achtergrond wordt er in je authenticator een DID (long form) aangemaakt en opgeslagen.

Vervolgens kun je je Verifiable Credential aanbieder bij een verifier. Microsoft heeft een voorbeeld website gemaakt van een fictieve webshop waar je korting krijgt op laptops wanneer je bewijst dat je werknemer bent van de issuer organisatie.

Test je Verifiable Credential bij een verifier: https://proseware.azurewebsites.net/ en selecteer ‘Access Discounts’

Selecteer ‘Verify my Employee Credential’

Scan met authenticator.app (Verifiable Credential menu) de QR code. De authenticator app vraag vervolgens om je Verifiable Credential te delen en wanneer je dit doet krijg je de korting op laptops te zien:

Wanneer je een foto van jezelf in je Entra ID tenant hebt kun je naar de volgende voorbeeld website https://aka.ms/vcempver gaan waar Microsoft Verifiable Credentials combineert met facecheck technologie. Zie https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck.

Conclusie

Inmiddels bieden diverse partijen Verifiable Credentials oplossingen aan gebaseerd op verschillende trust systems. Deze nieuwe vorm van credentials en digitale identifiers zal naar alle waarschijnlijkheid niet de bestaande oplossingen vervangen maar kan zeker een goede aanvulling zijn voor een veiligere en minder privacy frauduleuze digitale wereld. Wat dit precies allemaal gaat brengen is moeilijk te voorspellen maar het brengt de fysieke en digitale wereld zeker dichter bij elkaar!