Overzicht van de Microsoft Entra geverifieerde ID-architectuur
Het is belangrijk om uw oplossing voor controleerbare legitimatiebewijzen te plannen, zodat u, naast het uitgeven en/of valideren van referenties, een volledig overzicht hebt van de gevolgen die uw oplossing heeft voor de architectuur en uw bedrijf. Als u deze nog niet hebt bekeken, raden we u aan om Inleiding tot Microsoft Entra geverifieerde ID en de veelgestelde vragen door te nemen en de zelfstudie Aan de slag te doen.
In dit overzicht met betrekking tot de architectuur worden de mogelijkheden en onderdelen van de Microsoft Entra geverifieerde ID-service beschreven. Voor meer gedetailleerde informatie over uitgifte en validatie gaat u naar
Benaderingsmethoden voor identiteiten
Tegenwoordig gebruiken de meeste organisaties gecentraliseerde identiteitssystemen om werknemersreferenties te verstrekken. Ze passen ook verschillende methoden toe om klanten, partners, leveranciers en Relying Party's binnen de vertrouwensgrenzen van de organisatie te brengen. Deze methoden omvatten federatie, het maken en beheren van gastaccounts met systemen zoals Microsoft Entra B2B en het maken van expliciete vertrouwensrelaties met relying party's. De meeste zakelijke relaties hebben een digitaal onderdeel, dus het opzetten van een vorm van vertrouwen tussen organisaties vereist aanzienlijke inspanningen.
Gecentraliseerde identiteitssystemen
Gecentraliseerde methoden werken in veel gevallen nog steeds goed, bijvoorbeeld wanneer toepassingen, services en apparaten afhankelijk zijn van de vertrouwensmechanismen die worden gebruikt binnen een domein of vertrouwensgrens.
In gecentraliseerde identiteitssystemen bepaalt de id-provider (IDP) de levenscyclus en het gebruik van referenties.
Er zijn echter scenario's waarin het gebruik van een gedecentraliseerde architectuur met controleerbare legitimatiebewijzen van meerwaarde kan zijn doordat het een aanvulling vormt voor belangrijke scenario's, zoals
veilige onboarding van de identiteiten van werknemers en anderen, waaronder externe scenario's.
toegang tot resources binnen de vertrouwensgrens van de organisatie op basis van specifieke criteria.
toegang tot resources buiten de vertrouwensgrens, zoals toegang tot resources van partners, met een overdraagbare referentie die is uitgegeven door de organisatie.
Gedecentraliseerde identiteitssystemen
In gedecentraliseerde identiteitssystemen wordt het beheer van de levenscyclus en het gebruik van de referenties gedeeld tussen de verlener, de houder en de Relying Party die gebruikmaakt van de referentie.
Bekijk het scenario in het diagram waarin Proseware, een e-commercewebsite, zakelijke kortingen wil aanbieden aan Woodgrove-werknemers.
Terminologie voor controleerbare legitimatiebewijzen kan verwarrend zijn als u niet bekend bent met controleerbare legitimatiebewijzen. De volgende definities zijn afkomstig uit het terminologiegedeelte van Verifiable Credentials Data Model 1.0. Daarna relateren we elke definitie aan entiteiten in het voorgaande diagram.
"Een verlener is een rol die een entiteit kan uitvoeren door claims over een of meer onderwerpen te bevestigen, een verifieerbare referentie van deze claims te maken en de verifieerbare referentie naar een houder te verzenden."
- In het voorgaande diagram is Woodgrove de verlener van controleerbare legitimatiebewijzen voor de eigen werknemers.
"Een houder is een rol die een entiteit kan uitvoeren door een of meer verifieerbare referenties te bezitten en presentaties hiervan te genereren. Een houder is meestal, maar niet altijd, een onderwerp van de verifieerbare referenties die ze bewaren. Houders slaan hun referenties op in referentieopslagplaatsen."
- In het voorgaande diagram is Alice een Woodgrove-werknemer. Ze heeft een controleerbaar legitimatiebewijs verkregen van de Woodgrove-verlener en is de houder van die referentie.
"Een verificator is een rol die een entiteit uitvoert door een of meer verifieerbare referenties te ontvangen, optioneel in een verifieerbare presentatie voor verwerking. Andere specificaties kunnen verwijzen naar dit concept als relying party."
- In het voorgaande diagram is Proseware een controleur van referenties die zijn verleend door Woodgrove.
"Een referentie is een set van een of meer claims die zijn gemaakt door een verlener. Een controleerbaar legitimatiebewijs is een fraudebestendige referentie met auteurschap die cryptografisch kan worden geverifieerd. Controleerbare legitimatiebewijzen kunnen worden gebruikt om verifieerbare presentaties te maken, die ook cryptografisch kunnen worden geverifieerd. De claims in een referentie kunnen betrekking hebben op verschillende onderwerpen."
"Een gedecentraliseerde id is een draagbare URI-id, ook wel een DID genoemd, die is gekoppeld aan een entiteit. Deze id's worden vaak gebruikt in een verifieerbare referentie en zijn gekoppeld aan onderwerpen, verleners en verificatoren.
"Een gedecentraliseerd id-document, ook wel een DID-document genoemd, is een document dat toegankelijk is met behulp van een verifieerbaar gegevensregister en informatie bevat met betrekking tot een specifieke gedecentraliseerde id, zoals de bijbehorende opslagplaats en informatie over de openbare sleutel."
In het scenario hebben zowel de verlener als de verificator een DID- en een DID-document. Het DID-document bevat de openbare sleutel en de lijst met DNS-webdomeinen die zijn gekoppeld aan de DID (ook wel gekoppelde domeinen genoemd).
Woodgrove (verlener) ondertekent de controleerbare legitimatiebewijzen van de eigen werknemers met een eigen persoonlijke sleutel. Op dezelfde manier ondertekent Proseware (controleur) aanvragen om een controleerbaar legitimatiebewijs te overleggen met behulp van de sleutel, die ook is gekoppeld aan de DID.
Een vertrouwenssysteem is de basis voor het tot stand brengen van vertrouwen tussen gedecentraliseerde systemen. Het kan een gedistribueerd grootboek zijn of het kan iets gecentraliseerd zijn, zoals DID Web.
"Een gedistribueerd grootboek is een niet-gecentraliseerd systeem voor het vastleggen van gebeurtenissen. Deze systemen zorgen voor voldoende vertrouwen bij de deelnemers om te vertrouwen op de gegevens die anderen hebben vastgelegd om operationele beslissingen te nemen. Ze maken doorgaans gebruik van gedistribueerde databases waarbij verschillende knooppunten een consensusprotocol gebruiken om de volgorde van cryptografische ondertekende transacties te bevestigen. Het koppelen van digitaal ondertekende transacties in de loop van de tijd maakt vaak de geschiedenis van het grootboek onveranderbaar."
Gecentraliseerde en gedecentraliseerde identiteitsarchitecturen combineren
Wanneer u een oplossing voor controleerbare legitimatiebewijzen bekijkt, is het handig om te begrijpen hoe gedecentraliseerde identiteitsarchitecturen kunnen worden gecombineerd met gecentraliseerde identiteitsarchitecturen om een oplossing te bieden die risico's vermindert en aanzienlijke operationele voordelen biedt.
Het gebruikerstraject
In dit architectuuroverzicht wordt het traject gevolgd van een sollicitant en werknemer, die solliciteert op een functie bij een organisatie en deze accepteert. Vervolgens worden wijzigingen voor de werknemer en organisatie bekeken, waarbij controleerbare legitimatiebewijzen een aanvulling kunnen vormen voor gecentraliseerde processen.
Actoren in deze praktijkvoorbeelden
Alice, een persoon die solliciteert naar een functie bij Woodgrove, Inc en deze accepteert.
Woodgrove , Inc, een fictief bedrijf.
Adatum, de fictieve partner voor identiteitsverificatie van Woodgrove.
Proseware, de fictieve partnerorganisatie van Woodgrove.
Woodgrove maakt gebruik van zowel gecentraliseerde als gedecentraliseerde identiteitsarchitecturen.
Stappen in het gebruikerstraject
Alice solliciteert naar een functie bij Woodgrove, Inc, accepteert deze en doet de onboarding.
Toegang tot digitale resources binnen de vertrouwensgrens van Woodgrove.
Toegang tot digitale resources buiten de vertrouwensgrens van Woodgrove zonder de vertrouwensgrenzen van Woodgrove of partners uit te breiden.
Aangezien Woodgrove doorlopend bedrijfsactiviteiten uitvoert, moet het voortdurend identiteiten beheren. In de praktijkvoorbeelden in deze handleiding wordt beschreven hoe Alice gebruik kan maken van selfservicefuncties om de id's te verkrijgen en te beheren en hoe Woodgrove zakelijke relaties met uiteenlopende vertrouwensvereisten kan toevoegen, wijzigen en beëindigen.
Deze praktijkvoorbeelden laten zien hoe gecentraliseerde identiteiten en gedecentraliseerde identiteiten kunnen worden gecombineerd om een krachtigere en efficiëntere identiteit, vertrouwensstrategie en levenscyclus te bieden.
Gebruikerstraject: onboarden bij Woodgrove
Intentie: Alice wil graag bij Woodgrove, Inc. werken en bezoekt de Woodgrove-site met vacatures.
Activering: op de Woodgrove-site wordt de identiteit van Alice geverifieerd aan de hand van een QR-code of een dieptekoppeling die leidt naar de vertrouwde partner voor identiteitscontrole, Adatum.
Verzoek en upload: Adatum vraagt naar een bewijs van identiteit bij Alice. Alice neemt een selfie en een rijbewijsfoto en uploadt deze naar Adatum.
Uitgifte: wanneer Adatum de identiteit van Alice verifieert, verleent Adatum aan Alice een controleerbaar legitimatiebewijs dat haar identiteit bevestigt.
Presentatie: Alice (de houder en het subject van de referentie) heeft vervolgens toegang tot de Woodgrove-carrièreportal om de sollicitatieprocedure uit te voeren. Wanneer Alice het controleerbare legitimatiebewijs gebruikt om toegang te krijgen tot de portal, neemt Woodgrove de rollen van controleur en Relying Party op zich en vertrouwt het de verklaring van Adatum.
Het verstrekken van referenties in de aanvangfase
Alice accepteert de baan bij Woodgrove. Als onderdeel van het onboardingproces wordt een Microsoft Entra-account gemaakt dat Alice kan gebruiken binnen de grens van de Woodgrove-vertrouwensrelatie. De manager van Alice moet bedenken hoe Alice, die op afstand werkt, de aanmeldingsgegevens op een veilige manier kan ontvangen. In het verleden heeft de IT-afdeling deze referenties mogelijk aan haar manager verstrekt, die deze dan zou afdrukken en aan Alice zou overhandigen. Het afdrukken van de referenties werkt niet met externe werknemers.
Controleerbare legitimatiebewijzen kunnen van toegevoegde waarde zijn voor gecentraliseerde systemen doordat deze voor een verbetering van de referentiedistributie zorgen. In plaats van dat de manager referenties moet verstrekken, kan Alice de controleerbare legitimatiebewijzen gebruiken als bewijs van identiteit om de gebruikersnaam en referenties te ontvangen voor toegang tot gecentraliseerde systemen. Alice overlegt het bewijs van identiteit dat aan haar portemonnee is toegevoegd als onderdeel van de onboardingprocedure.
In het praktijkvoorbeeld voor de onboarding worden de vertrouwensrelatierollen gedistribueerd onder de verlener, de controleur en de houder.
De verlener is verantwoordelijk voor het valideren van de claims die deel uitmaken van het controleerbare legitimatiebewijs dat wordt uitgegeven. Adatum valideert de identiteit van Alice om het controleerbare legitimatiebewijs te verlenen. In dit geval worden controleerbare legitimatiebewijzen verleend zonder dat rekening wordt gehouden met een controleur of Relying Party.
De houder beschikt over het controleerbare legitimatiebewijs en geeft het controleerbare legitimatiebewijs op voor verificatie. Alleen Alice kan de controleerbare legitimatiebewijzen overleggen waarover ze beschikt.
De controleur accepteert de claims in het controleerbare legitimatiebewijs van verleners die deze vertrouwt en valideert het controleerbare legitimatiebewijs met behulp van de functionaliteit voor het gedecentraliseerde grootboek die wordt beschreven in het gegevensmodel voor controleerbare legitimatiebewijzen. Woodgrove vertrouwt de claims van Adatum met betrekking tot de identiteit van Alice.
Door gecentraliseerde en gedecentraliseerde identiteitsarchitecturen te combineren voor de onboarding, hoeft vertrouwelijke informatie over Alice, die nodig is voor identiteitsverificatie, zoals een BSN-nummer, niet te worden opgeslagen door Woodgrove, omdat deze erop vertrouwt dat het controleerbare legitimatiebewijs van Alice dat is verleend door de partner voor identiteitsverificatie (Adatum) haar identiteit bevestigt. Zo wordt vermeden dat werkzaamheden dubbel worden uitgevoerd en er een geautomatiseerde en voorspelbare werkwijze voor de eerste onboardingtaken wordt geïmplementeerd.
Gebruikerstraject: toegang tot resources binnen de vertrouwensgrens
Als werknemer werkt Alice binnen de vertrouwensgrens van Woodgrove. Woodgrove fungeert als de id-provider (IDP) en behoudt volledige controle over de identiteit en de configuratie van de apps die Alice gebruikt om te communiceren binnen de Woodgrove-vertrouwensgrens. Om resources in de vertrouwensgrens van Microsoft Entra ID te gebruiken, biedt Alice mogelijk meerdere vormen van identificatie om zich aan te melden bij de vertrouwensgrens van Woodgrove en toegang te krijgen tot de resources in de technologieomgeving van Woodgrove. Meerdere proofs is een typisch scenario dat goed wordt bediend met behulp van een gecentraliseerde identiteitsarchitectuur.
Woodgrove beheert de vertrouwensgrens en biedt Alice aan de hand van goede beveiligingsprocedures toegang op het niveau met de minste bevoegdheden, op basis van de taak die wordt uitgevoerd. Om een goede beveiliging te blijven waarborgen en mogelijk vanwege nalevingsredenen, moet Woodgrove ook de machtigingen van werknemers en de toegang tot resources kunnen volgen. Daarnaast moet het machtigingen kunnen intrekken wanneer het dienstverband wordt beëindigd.
Alice gebruikt alleen de referentie die Woodgrove beheert voor toegang tot Woodgrove-resources. Alice hoeft niet bij te houden wanneer de referentie wordt gebruikt, omdat Woodgrove de referentie beheert en die alleen wordt gebruikt met Woodgrove-resources. De identiteit is alleen geldig binnen de Woodgrove-vertrouwensgrens wanneer toegang tot Woodgrove-resources nodig is, zodat Alice zelf niet over de referentie hoeft te beschikken.
Controleerbare legitimatiebewijzen gebruiken binnen de vertrouwensgrens
Individuele werknemers hebben veranderende identiteitsbehoeften en controleerbare legitimatiebewijzen kunnen een aanvulling vormen op gecentraliseerde systemen om deze wijzigingen te beheren.
Als werkneemster van Woodgrove moet Alice mogelijk toegang krijgen tot resources waarbij ze aan specifieke vereisten moet voldoen. Wanneer Alice bijvoorbeeld de privacytraining voltooit, kan aan haar een controleerbaar legitimatiebewijs voor nieuwe werknemers worden verleend met die claim. Dat controleerbare legitimatiebewijs kan vervolgens worden gebruikt om toegang te verkrijgen tot afgeschermde resources.
Controleerbare legitimatiebewijzen kunnen worden gebruikt binnen de vertrouwensgrens voor accountherstel. Als de werknemer bijvoorbeeld zijn telefoon en computer heeft verloren, kan hij of zij weer toegang krijgen door een nieuwe VC te krijgen van de identiteitsverificatieservice, die wordt vertrouwd door Woodgrove en die VC vervolgens gebruikt om nieuwe referenties op te halen.
Gebruikerstraject: toegang tot externe resources
Woodgrove is met Proseware een productaankoopkorting overeengekomen. Alle Woodgrove-medewerkers komen in aanmerking voor de korting. Woodgrove wil Alice in staat stellen om toegang te krijgen tot de website van Proseware en korting te krijgen op producten die ze daar aanschaft. Als Woodgrove gebruikmaakt van een gecentraliseerde identiteitsarchitectuur, zijn er twee manieren om Alice de korting te bieden:
Alice zou persoonlijke gegevens kunnen opgeven om een account te maken bij Proseware, waarna Proseware zou moeten controleren of Alice bij Woodgrove werkt.
Woodgrove zou de vertrouwensgrens kunnen uitbreiden naar Proseware als een Relying Party en Alice zou dan de uitgebreide vertrouwensgrens kunnen gebruiken om de korting te krijgen.
Met gedecentraliseerde id's kan Woodgrove Alice voorzien van een controleerbaar legitimatiebewijs dat Alice kan gebruiken voor toegang tot de website van Proseware en andere externe resources.
Door Alice het controleerbare legitimatiebewijs te verstrekken, verklaart Woodgrove dat Alice een werknemer is. Woodgrove is een vertrouwde verlener van controleerbare legitimatiebewijzen in de validatieoplossing van Proseware. Met dit vertrouwen in de uitgifteprocedure van Woodgrove kan Proseware het controleerbare legitimatiebewijs elektronisch accepteren als bewijs dat Alice een Woodgrove-werknemer is en kan aan Alice de korting worden geboden. Als onderdeel van de validatie van het controleerbare legitimatiebewijs dat Alice overlegt, controleert Proseware de geldigheid van het controleerbare legitimatiebewijs met behulp van het vertrouwenssysteem. In deze oplossing:
Woodgrove stelt Alice in staat om aan Proseware een bewijs van dienstverband te verstrekken zonder dat Woodgrove de vertrouwensgrens hoeft uit te breiden.
Proseware hoeft de eigen vertrouwensgrens niet uit te breiden om te controleren of Alice een werkneemster van Woodgrove is. Proseware kan in plaats daarvan het controleerbare legitimatiebewijs gebruiken dat Woodgrove verstrekt. Omdat de vertrouwensgrens niet is uitgebreid, is het beheren van de vertrouwensrelatie eenvoudiger en kan Proseware de relatie eenvoudig beëindigen door de controleerbare legitimatiebewijzen niet meer te accepteren.
Alice hoeft geen persoonlijke gegevens, zoals een e-mailadres, op te geven aan Proseware. Alice bewaart het controleerbare legitimatiebewijs in een portemonnee-toepassing op een persoonlijk apparaat. De enige persoon die het controleerbare legitimatiebewijs kan gebruiken, is Alice en Alice moet het gebruik van de referentie starten. Elk gebruik van de VC wordt vastgelegd door de wallet applicatie, dus Alice heeft een record van wanneer en waar de VC wordt gebruikt.
Door gecentraliseerde en gedecentraliseerde identiteitsarchitecturen te combineren voor het werken binnen en buiten de grenzen van vertrouwensrelaties op Woodgrove, kunnen complexiteit en risico's worden verminderd en worden beperkte relaties gemakkelijker te beheren.
Wijzigingen in de loop van de tijd
Woodgrove voegt nieuwe zakelijke relaties toe en beëindigt huidige zakelijke relaties met andere organisaties en moet bepalen wanneer gecentraliseerde en gedecentraliseerde identiteitsarchitecturen worden gebruikt.
Door gecentraliseerde en gedecentraliseerde identiteitsarchitecturen te combineren, wordt de verantwoordelijkheid en inspanning die is gekoppeld aan identiteit en bewijs van identiteit verdeeld en wordt het risico verlaagd. De gebruiker loopt geen risico om hun persoonlijke gegevens zo vaak of aan zoveel onbekende verificatoren vrij te geven. Specifiek:
- In gecentraliseerde identiteitsarchitecturen verleent de id-provider referenties en voert deze de verificatie uit van die verleende referenties. De IDP verwerkt informatie over alle identiteiten. Ze worden opgeslagen in een map of worden opgehaald uit een map. IDP's kunnen eventueel beveiligingstokens van andere IDP-systemen accepteren, zoals sociale aanmeldingen of zakelijke partners. Als een Relying Party identiteiten wil gebruiken binnen de vertrouwensgrens van de id-provider, moet de Relying Party zo worden geconfigureerd dat deze de tokens accepteert die zijn uitgegeven door de id-provider.
De werking van gedecentraliseerde identiteitssystemen
In gedecentraliseerde identiteitsarchitecturen hebben de verlener, gebruiker en Relying Party (RP) elk een rol bij het tot stand brengen en garanderen van continue vertrouwde uitwisseling van elkaars referenties. De openbare sleutels van de DID's van de actoren kunnen worden omgezet via het vertrouwenssysteem, waardoor handtekeningvalidatie, en daardoor vertrouwen in elk artefact, waaronder een controleerbaar legitimatiebewijs, mogelijk wordt gemaakt. Relying Party's kunnen controleerbare legitimatiebewijzen gebruiken zonder vertrouwensrelaties met de verlener tot stand te brengen. In plaats daarvan verstrekt de verlener het subject een referentie die als bewijs wordt ingediend bij Relying Party's. Alle berichten tussen actoren worden ondertekend met de DID van de actor. DID's van verleners en controleurs moeten ook eigenaar zijn van de DNS-domeinen die de aanvragen hebben gegenereerd.
Bijvoorbeeld: wanneer houders van een controleerbaar legitimatiebewijs toegang moeten hebben tot een resource, moeten ze het controleerbare legitimatiebewijs indienen bij die Relying Party. Ze doen dit met behulp van een portemonnee-toepassing om de Relying Party-aanvraag voor het overleggen van een controleerbare legitimatiebewijs te lezen. Als onderdeel van het lezen van de aanvraag, gebruikt de wallet-toepassing de DID van de RP om de openbare sleutels van de RP te vinden met behulp van het vertrouwenssysteem, validerend dat de aanvraag om de VC te presenteren niet is gemanipuleerd. Om het eigendom van het domein te bewijzen, controleert de portemonnee ook of de DID wordt verwezen in een metagegevensdocument dat wordt gehost in het DNS-domein van de RP.
Stroom 1: uitgifte van een controleerbaar legitimatiebewijs
In deze stroom communiceert de referentiehouder met de verlener om een controleerbaar legitimatiebewijs aan te vragen, zoals wordt afgebeeld in het volgende diagram
De houder start de stroom via een browser of eigen toepassing om toegang te krijgen tot de webfront-end van de verlener. Daar stuurt de website van de uitgever de gebruiker aan om gegevens te verzamelen en verlenerspecifieke logica uit te voeren om te bepalen of de referentie kan worden uitgegeven en de inhoud ervan.
De webfront-endverlener roept de Microsoft Entra geverifieerde ID-service aan om een VC-uitgifteaanvraag te genereren.
De webfront-end geeft een koppeling naar de aanvraag weer als een QR-code of een apparaatspecifieke dieptekoppeling (afhankelijk van het apparaat).
De houder scant de QR-code of dieptekoppeling uit stap 3 met behulp van een portemonnee-toepassing, zoals Microsoft Authenticator
De portemonnee downloadt de aanvraag via de koppeling. De aanvraag omvat:
De DID van de verlener. De DID van de uitgever wordt door de wallet-app gebruikt om via het vertrouwenssysteem de openbare sleutels en gekoppelde domeinen te vinden.
URL met het manifest voor het controleerbare legitimatiebewijs waarin de contractvereisten voor het verlenen van het controleerbare legitimatiebewijs worden opgegeven. De contractvereiste kan id_token, zelf geteste kenmerken bevatten die moeten worden verstrekt of de presentatie van een andere VC.
Opmaak van het controleerbare legitimatiebewijs (URL van het logobestand, kleuren, enzovoort).
De portemonnee valideert de uitgifteaanvragen en verwerkt de contractvereisten:
Valideert dat het uitgifteaanvraagbericht is ondertekend door de sleutels van de verlener die zijn gevonden in het DID-document dat is opgelost via het vertrouwenssysteem. Het valideren van de handtekening zorgt ervoor dat er niet met het bericht is geknoeid.
Valideert of de verlener eigenaar is van het DNS-domein waarnaar wordt verwezen in het DID-document van de verlener.
Afhankelijk van de contractvereisten voor het controleerbare legitimatiebewijs, kan de portemonnee vereisen dat de houder aanvullende gegevens ophaalt. Bijvoorbeeld door te vragen om zelf uitgegeven kenmerken of door een OIDC-stroom navigeren om een id_token te verkrijgen.
Verzendt de artefacten die door het contract zijn vereist bij de Microsoft Entra geverifieerde ID-service. De Microsoft Entra geverifieerde ID service retourneert de VC, ondertekend met de DID-sleutel van de uitgever en de portemonnee slaat de VC veilig op.
Zie Uw Microsoft Entra geverifieerde ID-uitgifteoplossing plannen voor gedetailleerde informatie over het maken van een uitgifteoplossing en overwegingen met betrekking tot de architectuur.
Stroom 2: overleggen van het controleerbare legitimatiebewijs
In deze stroom communiceert een houder met een Relying Party (RP) om een controleerbaar legitimatiebewijs te overleggen als onderdeel van de autorisatievereisten.
De houder start de stroom via een browser of eigen toepassing om toegang te krijgen tot de webfront-end van de Relying Party.
De webfront-end roept de Microsoft Entra geverifieerde ID-service aan om een VC-presentatieaanvraag te genereren.
De webfront-end geeft een koppeling naar de aanvraag weer als een QR-code of een apparaatspecifieke dieptekoppeling (afhankelijk van het apparaat).
De houder scant de QR-code of dieptekoppeling uit stap 3 met behulp van een portemonnee-toepassing, zoals Microsoft Authenticator
De portemonnee downloadt de aanvraag via de koppeling. De aanvraag omvat:
een op standaarden gebaseerde aanvraag voor referenties van een schema of referentietype.
de DID van de RP, die door de portemonnee wordt opgezocht in het vertrouwenssysteem.
De portemonnee valideert de overleggingsaanvraag en vindt opgeslagen controleerbare legitimatiebewijzen die aan de aanvraag voldoen. Op basis van de vereiste controleerbare legitimatiebewijzen stuurt de portemonnee het subject aan om de controleerbare legitimatiebewijzen te selecteren en erin toe te stemmen om deze te gebruiken.
- De subject toestemming om de VC te delen met de RP
Vervolgens stuurt de portemonnee een nettolading van een presentatieantwoord naar de Microsoft Entra geverifieerde ID-service die door het onderwerp is ondertekend. Het bevat:
De controleerbare legitimatiebewijzen waarmee het subject heeft ingestemd.
Het onderwerp DEED.
De RP DEED als de 'doelgroep' van de nettolading.
De Microsoft Entra geverifieerde ID service valideert het antwoord dat door de portemonnee is verzonden. In sommige gevallen kan de VC-verlener de VC intrekken. Om ervoor te zorgen dat de VC nog steeds geldig is, moet de verificator controleren bij de VC-verlener. Dit is afhankelijk van hoe de verificator in stap 2 om de VC vroeg.
Bij validatie roept de Microsoft Entra geverifieerde ID-service de RP terug met het resultaat.
Zie Uw Microsoft Entra geverifieerde ID-verificatieoplossing plannen voor gedetailleerde informatie over het maken van een validatieoplossing en overwegingen met betrekking tot de architectuur.
Belangrijke punten
Gedecentraliseerde architecturen kunnen worden gebruikt om bestaande oplossingen te verbeteren en nieuwe functionaliteit te bieden.
Om de ambities van de Gedecentraliseerde Identity Foundation (DIF) en W3C Design te bereiken, moeten de volgende items worden overwogen bij het maken van een verifieerbare referentieoplossing:
Er zijn geen centrale punten van vertrouwensvorming tussen actoren in het systeem. Dat houdt in dat vertrouwensgrenzen niet worden uitgebreid via federatie, omdat actoren specifieke controleerbare legitimatiebewijzen vertrouwen.
- Het vertrouwenssysteem maakt het mogelijk om de gedecentraliseerde id (DID) van een actor te detecteren.
Met de oplossing kunnen controleurs controleerbare legitimatiebewijzen van elke verlener valideren.
De oplossing stelt de verlener niet in staat om de autorisatie van het subject of de controleur (Relying Party) te beheren.
De actoren werken op autonome wijze en zijn elk in staat om de taken voor hun rollen uit te voeren.
Verleners bedienen elke aanvraag voor een controleerbaar legitimatiebewijs en maken geen onderscheid tussen de aanvragen die worden bediend.
Subjecten zijn eigenaar van het controleerbare legitimatiebewijs wanneer dit eenmaal is verleend en kunnen hun controleerbare legitimatiebewijs aan elke controleur overleggen.
Controleurs kunnen elk controleerbaar legitimatiebewijs van een onderwerp of verlener valideren.
Volgende stappen
Meer informatie over de architectuur voor controleerbare legitimatiebewijzen