Azure Active Directory Verifiable Credentials: Blockchain-Identity-as-a-Service

Dezentrale Identitäten sind ein relativ neues, aber stark wachsendes Thema. Microsoft hat mit Azure Active Directory Verifiable Credentials eine eigene Implementierung vorgelegt und erste Anwendungsfälle in Aussicht gestellt: 

  • Schnelles Remote-Onboarding 
  • Zugriff auf hochsichere Apps 
  • Self-Service-Kontowiederherstellung 

Um sich dem Thema zu nähern, ist es notwendig, die Begriffe „Decentralized Identifiers“ und „Verifiable Credentials“ zu betrachten. 

Decentralized Identifiers

Decentralized Identifiers (DIDs) sind global eindeutige Kennzeichen, die auf dezentralisierten Systemen basieren (wie z.B. Blockchains) und dadurch vor Manipulationen geschützt sind. DIDs können für Personen vergeben werden, aber ebenso für andere Entitäten (wie Unternehmen oder IoT-Geräte etc.). Der öffentliche Schlüssel einer DID liegt im dezentralen System, der private Schlüssel beim Inhaber der DID, der damit nachweisen kann, dass ihm die DID gehört. Man kann beliebig viele DIDs haben und ist bei der Erstellung und Verwaltung nicht von einer zentralen Autorität abhängig.  

Standardisiert wurden DIDs vom World Wide Web Consortium (W3C) in Version 1.0 im August 2021 (https://www.w3.org/TR/did-core/). DIDs beginnen mit „did“, darauf folgt die DID-Methode (von der es durch unterschiedliche Implementierungsprojekte über einhundert verschiedene gibt), danach kommt der methodenspezifische Identifier. 

Verifiable Credentials

Wenn an DIDs Informationen gebunden werden, dann entstehen Verifiable Credentials (VCs). Prinzipiell kann jeder jedem ein VC mit beliebigem Inhalt ausstellen. Das bedeutet, dass im dezentralen System hinterlegt wird, zu welcher bestimmten DID welche bestimmte Information gehört. Will sich nun jemand mit seinem VC gegenüber einem Dritten ausweisen, dann überprüft dieser Dritte im dezentralen System, ob die mit dem VC verbundene Behauptung korrekt ist. Unabhängig davon muss der Dritte aber für sich entscheiden, ob der Aussteller vertrauenswürdig ist. 

Use Cases

Die möglichen Anwendungsfälle für DIDs und VCs sind enorm vielfältig. Sie reichen vom digitalen Personalausweis, über Impfzertifikate bis hin zu lebenslangen Nachweisen für Ausbildungszeugnisse. Es kann aber auch schlicht der Nachweis sein, dass man im Besitz einer bestimmten Email-Adresse ist oder eine gewisse (selbst attestierte) Kleidergröße hat. Die Flexibilität des Systems ohne zentrale Autorität, kombiniert mit vom Anwender selbst erstellten und verwalteten DIDs, ermöglichen die sogenannte „Self-Sovereign Identity (SSI)“: Der Anwender gibt lediglich diejenigen Informationen über sich selbst frei, die für den konkreten Anwendungsfall notwendig sind. Dadurch erreicht man maximalen Schutz der Privatsphäre beim Benutzen von Online-Diensten, bei ärztlichen Rezepten oder beim Abschluss eines Mietvertrages. Diese Beispiele aus dem privaten Bereich lassen sich problemlos auf andere Bereiche übertragen. So kann etwa ein Dienstleistungsunternehmen die Einhaltung bestimmter Standards per VC nachweisen und vermeidet damit das wiederholte Ausfüllen langer Fragenkataloge vor Beginn der Leistungserbringung bei jedem einzelnen Neukunden. 

Architektur

Azure Active Directory Verifiable Credentials

Die von Microsoft verwendete DID-Methode nennt sich Identity Overlay Network (ION), die letztlich auf der Bitcoin Blockchain und dem InterPlanetary File System (IPFS), einem verteilten Peer-to-Peer-Dateisystem, basiert. Auf der Bitcoin Blockchain werden Transaktionen gespeichert, die einen Wert für OP_RETURN enthalten. Diese Werte sind Hashes von und damit eindeutige Verweise auf Dateien im IPFS. 

ION Nodes suchen in der Blockchain nach den Hashes und laden sich dann von IPFS die zugehörigen Dateien. Beim Betrieb eines eigenen ION Nodes bindet man sich für die Bitcoin-Transaktionen ein eigenes Bitcoin Wallet ein. Nutzt man „ION-as-a-Service“, sprich Azure Active Directory Verifiable Credentials, dann nimmt einem Microsoft den Betrieb des ION Nodes ab. Man betreibt dann selbst lediglich simple Issuer- und/oder Verifier-Instanzen, den Rest übernimmt Azure. 

Proof of Concept

Um Azure Active Directory Verifiable Credentials zu verproben, ist lediglich eine Azure AD P2-Lizenz notwendig. Der Service wird derzeit als Public Preview angeboten, es gibt also noch keine dedizierten Lizenzmodelle mit SLAs. 

Im Wesentlichen lädt man sich die auf Node.js basierenden Issuer- und Verifier-Instanzen von GitHub und folgt zur Basiskonfiguration der Anleitung von Microsoft.  

Showcase

Identitätsnachweis kombiniert mit AAD-Authentifizierung

In der beruflichen Praxis eines IT-Dienstleistungsunternehmens kommt es insbesondere im Bankenumfeld zur Situation, dass sich die einzelnen Mitarbeitenden des Dienstleisters im Rahmen des Onboarding-Prozesses mit ihrem Personalausweis gegenüber dem Kunden ausweisen müssen. VCs können diesen Prozess vereinfachen: Für den Zugriff auf eine beliebige Anwendung des Kunden wird die Kombination von zwei Identitäten verlangt – eine Identität, die auf einem Personalausweis basiert und eine andere Identität, die auf einem Azure-AD-Konto beruht. 

In diesem Showcase bin ich Mitarbeiter des IT-Dienstleisters. In meinem Wallet (Microsoft Authenticator App) habe ich bereits ein Verifiable Credential. Das habe ich mir von einem Videoident-Anbieter besorgt, der mich anhand meines Ausweises identifiziert hat.  

Dieses VC der fiktiven „Videoident GmbH“ ist im Showcase von mir selbst ausgestellt. Es gibt aber bereits Anbieter, die mit Microsoft kooperieren, um genau das möglich zu machen. 

Um Zugang zu einer bestimmten Anwendung des Kunden zu bekommen, besorge ich mir ein weiteres VC. Dafür scanne ich einen QR-Code. 

Danach muss ich nachweisen, dass ich bereits das Videoident VC habe und ich muss mich zusätzlich am Azure AD anmelden, um die Berechtigung auf die Anwendung nachzuweisen. 

Jetzt besitze ich zwei VCs. Das App-VC kombiniert meine Personalausweis-Identität mit meiner Azure AD-Berechtigung. 

Nun gehe ich zur Anwendung des Kunden, scanne einen weiteren QR-Code und kann dann die Anwendung nutzen. 

Vorteile

  • Der Mitarbeiter hat sich mit seinem Personalausweis ausgewiesen und erfüllt damit die Anforderung des Kunden. 
  • Das Videoident-VC kann der Mitarbeiter mehrfach, also auch in weiteren Szenarien, verwenden. 
  • Auch die Authentifizierung gegenüber Azure AD muss nicht bei jedem Aufruf der Anwendung durchgeführt werden. Innerhalb einer vorgegebenen Zeitspanne kann der Mitarbeiter das App-VC (im Showcase das zweite VC) wiederverwenden. 
  • Der Mitarbeiter hat nur diejenigen Daten über sich preisgegeben, die im konkreten Fall notwendig waren. Er musste dem Kunden gegenüber nicht seinen Ausweis mitsamt persönlichen Daten, wie z.B. dem Geburtsort, präsentieren.

 Melden Sie sich gerne bei uns, um weiter in das Thema einzusteigen! 

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Blog-Post teilen

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Neueste Beiträge

Das könnte Sie auch interessieren