Gegenstand der Erfindung ist das Management von digitalen Identitäten. Insbesondere betrifft die Erfindung die Bereitstellung eines Attributs einer verifizierten digitalen Identität in einem föderierten System mit mehreren verbundenen Identitätsgebern. Die Erfindung integriert Benutzer-Konten, die bei verschiedenen Identitätsgebern verwaltet werden und erlaubt abhän gigen Diensten eine einheitliche und transparente Nutzung von Attributen einer verifizierten digitalen Identität zur Authentisierung und Einrichtung eines Zugangs zu einer digitalen Dienstleistung.

Voraussetzung für die Nutzung der digitalen Identität und somit für den Zugang zu vielen digitalen Diensten ist der Nachweis, dass ein Nutzer der Eigentümer einer digitalen Identität ist. Dies geschieht durch Authentisie rung des Nutzers. Hierzu bietet der Nutzer einen oder mehrere Faktoren zur Identifikation an, die durch das System mit der digitalen Identität

werden. Alltägliche Beispiele für Faktoren zum Identitätsnachweis sind die Eingabe einer PIN oder eines Passwortes im Rahmen eines Login-Verfah- rens, aber auch die Präsentation von biometiischen Merkmalen.

Zur Realisierung von Login-Verfahren für mehrere Anwendungen sind so genannte Single Sign On-Lösungen bekannt. Diese basieren auf einer einma ligen Anmeldung, die anschließend für weitere Anwendungen bzw. Systeme gültig ist. OpenIDConnect ist ein Industriestandard, der die einfache Reali sierung von Login-Prozessen über verschiedene Dienste und Systeme er möglicht. Ein anderes Verfahren ist z.B. SAML.

Bekannt sind auch spezifische Authentisierungsserver-Lösungen wie Ker- beros. hn Kern basieren diese Lösungen auf einem Datenspeicher, der die Nutzerdaten und Attribute persistent vorhält und in der Regel zentralisiert verwaltet wird. Der Dienst, der die Daten des Nutzers speichert und die Identifikation und Verifikation des Nutzers beim Login durchführt, wird als Identitätsgeber oder Identity Provider bezeichnet.

Die Anzahl der Identitätsgeber ist erheblich und zunehmend. Neben explizit auf die Bereitstellung von Nutzeridentitäten spezialisierten Unternehmen sind dies auch die großen soziale Netzwerke. Daneben führen auch Finan zinstitute oder Online-Händler Benutzerkonten. Im Enterprise-Umfeld kann jedes Unternehmen die Identitäten seiner Angestellten verwalten. Im allge meinen verwaltet jeder Anbieter autonom die bei ihm eingerichteten Benut zerkonten und die mit den Konten verbundenen Nutzeridentitäten.

Ein Nutzer kann eine mit einem Konto verbundene Nutzeridentität nur für eine Autorisierung bzw. ein Login bei solchen Diensten nutzen, die eine Ver trauensbeziehung zu dem Anbieter haben, der das Konto verwaltet, und wenn der Dienst von dem Identitätsgeber unterstützt wird.

Möchte ein Nutzer eine Mehrzahl von Diensten und Konten nutzen, muss er typischerweise seine Identität bei jedem Dienst einzeln hinterlegen, um sich bei dem jeweiligen Dienst anzumelden.

Bekannt ist weiter das Konzept der Föderierten Identitäten. Ein erster Ansatz hierzu beruht auf dem Austausch von Nutzeridentitäten zwischen zusam mengeschlossenen Identitätsgebern. Die Benutzerkonten werden dabei zwi schen verschiedenen Identitätsgebern repliziert. Damit kann ein Nutzer ein Login bei jedem mit einem Identitätsgeber verbunden Dienst durchführen, der das betreffende Benutzer-Konto entweder selbst verwaltet oder impor tiert hat. Dieser Ansatz wird unter anderem von der Firma Verimi verfolgt. Ein anderer Ansatz besteht in der dynamischen Ermittlung und Verbindung mit dem Identitätsgeber, der ein benötigtes Benutzer-Konto verwaltet, beim Login-Prozess über eine Vermittlungsschicht. Der anfragende Dienst ver- traut allen Identitätsgebern, die vermittelbar sind. Nach der erfolgreichen Vermittlungsphase kommuniziert der Dienst entweder direkt mit dem Iden titätsgeber, um die Attribute des End-Nutzers abzufr agen und die Autorisie- rung durchzuführen, oder weiterhin über die Vermittlungs Schicht. Ein weiterer Ansatz besteht in der dezentralen Verwaltung von Nutzerkon ten auf einem Endgerät eines Nutzers oder in einem Netzwerk. Der anfra gende Dienst vertraut dem Endgerät oder dem Netz. Beispiele hierfür sind auf der Blockchain beruhende Ansätze. Aus der US 2019/ 0010109100 Al ist ein Verfahren zum Verwalten von Nut zeridentitäten bekannt, bei dem ein zentraler Management Server mit ver schiedenen Einrichtungen verbunden ist, auf denen Identitäten in unter schiedlichen Formen hinterlegt sind. Der Management Server greift auf die verbundenen Einrichtungen zu, um eine Identität zu errichten, abzusichern oder freizugeben. Die Lösung erlaubt es insbesondere, eine Identität mit ei nem vorgegebenen Grad an Vertrauenswürdigkeit bereitzustellen.

Aus der WO 2016/01010373 Al ist ein System bekannt, in dem ein Nutze rendgerät mit einem Authentisierungsserver über eine Zugangsinstanz mit einem Netzwerk verbunden ist. Das Nutzer endgerät ist mit mehreren Au- thentisierungseinrichtungen verbunden. Bei dem Authentisierungsserver sind verschiedene Authentisierungseinrichtungen registriert. Nach erfolgrei cher Authentisierung stellt der Authentisierungsserver ein kurzlebiges Zerti fikat bereit, mit dem das Nutzerendgerät von d er Zugangsinstanz ein Ticket abholen kann. Mit dem Ticket erhält das Nutzerendgerät Zugang in das Netzwerk und die darüber erreichbaren Dienste.

Aus der US 2017/0289134 Al ist ein auf einer verteilten Datenbank beruhen des Konsens-System zur Bereitstellung von Identitäten unter den Systemteil nehmern bekannt, wobei das System das Konzept der Einmalanmeldung bzw. Single Sign On (SSO) nutzt. Das System umfasst eine Identitätsgeber- Server, einen Nutzer-Computer sowie ein oder mehrere Server von Diens tanbietern. In einer Ausführungsvariante wird bei dem Identitätsgeber-Ser ver ein verifizierter Berechtigungsnachweis hinterlegt. Der Identitätsgeber- Server erzeugt dazu einen Identitäts-Token und stellt diesen einem Nutzer- Computer zur Verfügung. Mit dem Identitäts-Token kann der Nutzer-Com puter Zugang zu einem Server eines Dienstanbieters erlangen. Für die Ertei lung des Zugangs prüft der Server unter Zugriff auf die verteilte Datenbank den Zugangsstatus in Bezug auf einen anderen System teilnehmer. So wird verhindert, dass ein Zugang aufgrund eines ungültigen Berechtigungsnach weises erlangt wird. Der Erfindung liegt die Aufgabe zugrunde, ein Verfah ren anzugeben, das es erlaubt, für den Nachweis einer Identität bei der Nut zung eines digitalen Dienstes eine bereits verifizierte digitale Identität zu nutzen, die bei einem einer Föderation von Identitätsgebern zugehörigen Identitätsgeber hinterlegt ist.

Die Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen des Hauptanspruchs. Vorteilhafte Ausgestaltungen und zweckmäßige Weiterbil dungen ergeben sich aus den Merkmalen der abhängigen Ansprüche.

Das vor geschlagene Verfahren zeichnet sich durch einen zwischen die ab hängigen Diensten und die föderierten Identitätsgeber geschaltete Vermitt- lerdienst aus, der eine für alle Parteien transparente Vermittlung von Identi tätsanfragen implementiert. Transparenz bedeutet hier, dass ein abhängiger Dienst einen konkret benutzten Identitätsgeber nicht kennt und dem Identi tätsgeber seinerseits der abhängige Dienst oder dessen Nutzung durch einen Endnutzer nicht bekannt werden. Abhängiger Dienst und Identitätsgeber werden informationsmäßig entkoppelt. Bei der Bearbeitung von Identitäts anfragen bleiben der beteiligte abhängige Dienst und der beteiligte Identi tätsgeber einander gegenüber anonym. Durch die Transparenz wird beson ders eine missbräuchliche Auswertung und Analyse („Tracking") von ausge tauschten Daten verhindert.

Der Vermittler dienst ermöglicht es einem Endnutzer, für den Nachweis der Identität beim Zugang zu einem abhängigen digitalen Dienst nach seiner Wahl auf alle föderierten Identitätsgeber zurückzugreifen, die mit dem Ver mittlerdienst verbunden sind.

Das Verfahren erlaubt es abhängigen Diensten, für Login- und Registrie rungsprozesse für Benutzerkonten auf verifizierte digitale Identitäten zu rückzugreifen, die von verschiedenen Identitätsgebern verwaltet werden.

Abhängige Dienste müssen sich nur einmal in die Föderation integrieren, unabhängig von der Anzahl von Identitätsgebern, die in der Föderation zu sammengeschlossen sind. Ein abhängiger Dienst braucht dabei eine Vertrau ensbeziehung nur zu der Mittlereinheit, jedoch nicht zu den einzelnen Iden titätsgebers. Die Identitätsgeber muss der abhängige Dienst vielmehr weder kennen noch muss eine Vertrauensbeziehung bestehen. Gegenüber einem Identitätsgeber muss ein anfragender abhängiger Dienst insbesondere nicht offengelegen, auf welches Kundenkonto sich eine An frage bezieht.

In vorteilhafter Weise erhält die Mittlereinheit keine Einsicht und keinen Zu griff auf Attribute der Endnutzer uns kann nur auf Anfrage eines abhängi gen Dienstes aktiv werden. Indem Attribute in der die Mittlereinheit nur ver schlüsselt vorliegen ist sichergestellt, dass Attribute eines Endnutzers nicht von der Mittlereinheit verändert, eingesehen oder zwischengespeichert wer den können. Zudem kann die Mittlereinheit nicht ohne Auftrag durch einen abhängigen Dienst Attribute eines Endnutzers abfragen.

Die Mittlereinheit wird durch die eingebrachten technischen Maßnahmen auf eine Vermittlungs rolle fixiert und daran gehindert, selbst als Identitäts geber aufzutreten oder aktiv Attribute des Endnutzers abzurufen, um sie selbst für andere Zwecken zu verwerten.

Zweckmäßig werden durch eine Ende-zu-Ende Verschlüsselung Vertraulich keit und Integrität von Attributen sichergestellt.

In zweckmäßiger Ausgestaltung wird durch technische Maßnahmen sicher gestellt, dass die Mittlereinheit nicht ohne konkrete Anforderung eines ab hängigen Dienstes eine Anfrage an einen abhängigen Dienst stellen kann.

Das vor geschlagene Verfahren führt zu einer strikten Trennung der Rollen in einem föderativen Identitäts-Management-System. Damit eignet sich das Konzept insbesondere für Geschäftsanwendungen mit besonderen Anforde rungen an Vertraulichkeit wie z.B. im Finanzbereich. Durch die strikte Rol- lentrennung unterstützt das Konzept besonders den Schutz von persönli chen Daten und die geregelte Kooperation selbst in einem wettbewerbs-in- tensiven Umfeld.

Unter Bezugnahme auf die Zeichnung wird ein Ausführungsbeispiel der Er findung nachfolgend näher erläutert.

Es zeigen:

Fig. 1 die Struktur eines föderativen Identitäten-Management-Systems;

Fig. 2 den Ablauf der Bereitstellung eines Attributes einer verifizierten digi talen Identität für einen abhängigen Dienst in einem föderativen Iden- titäten-Management-Sy stem ;

Fig. 3 eine Folge von Bildschirminhalten, die im Rahmen einer Identitätsbe reitstellung einem Endnutzer an der Benutzer-Schnittstelle angezeigt werden;

Fig. 4 den schematischen Aufbau eines Tokens.

Fig. 1 zeigt schematisch eine auf die Hauptkomponenten reduzierte Ausge staltung eines föderativen Identitäten-Management-Systems 1. Komponen ten des dargestellten Systems sind ein Vermittler dienst 15, ein abhängiger Dienst 11, ein föderierter Identitätsgeber 21 sowie ein Nutzer- Agent 13.

Alle Komponenten 11, 13, 15, 21 sind über Datenverbindungen 24 zum Aus tausch von Daten jeweils mit den anderen Komponenten verbunden. Die Da tenverbindungen 24 können fest oder über die Fuftschnittstelle in Form ein oder mehrerer Netze ausgeführt sein. Die Datenverbindungen 24 sind durch technische Maßnahmen abgesichert, z.B. VPN oder TLS, sodass nur autori sierte Komponenten in Kommunikation treten können und die Daten gegen über Verfälschung und Ausspähung abgesichert sind.

Der Vermittlerdienst 15 setzt sich zusammen aus einer Mittlereinheit 16 und einer System-Zertifizierungsstelle 18.

Die System-Zertifizierungsstelle 18 ist als separate Einheit ausgeführt, die auf einer separaten Datenverarbeitungsanlage basiert. Aufgabe der System- Zertifizierungs stelle 18 ist die Abbildung der Vertrauens beziehungen der Komponenten durch die Ausstellung von Zertifikaten oder Token. Die Durchführung aller weiteren Aktivitäten des Vermittlerdienstes 15 gegen über dem Identitäten-Management-System 1 erfolgt durch die Mittlereinheit 16. hn Folgenden wird deshalb stellvertretend für den gesamten Vermittler dienst 15 nur die Mittlereinheit 16 angeführt, wenn diese eine Funktion durchführt.

Der Vermittlerdienst 15 verfügt über einen Speicherbereich 20, der insbeson dere zur Aufnahme von Token und Attributen 9 dient. Der Speicherbereich 20 ist in der Mittlereinheit 16 realisiert.

Der Nutzer- Agent 13 besitzt eine Endnutzer-Schnittstelle 14 zu einem End nutzer 10. Die Endnutzer-Schnittstelle 14 beinhaltet typischerweise eine An zeige und eine Tastatur. Andere und weitere Ein- und Ausgabemittel sind möglich. Insbesondere kann die End-Nutzerschnittstelle 14 Sensoren und bi ometrische Erfassungseinrichtungen für die Aufnahme von Authentisie- rungsfaktoren beinhalten. Abhängiger Dienst 11, Vermittler dienst 15 und föderierter Identitätsgeber 21 sind typischerweise in Form von Programmabläufen realisiert, die auf gängi gen Datenverarbeitungsanlagen ausgeführt werden. Die Datenverarbei tungsanlagen sind die Basis jeder Komponente.

Der Nutzer- Agent 13 kann zum Beispiel ein auf einem persönlichen Compu ter ausgeführter Browser sein oder das Bedienungsmenü eines öffentlich zu gänglichen Terminals.

Der Endnutzer 10 ist Eigner mindestens einer verifizierten digitalen Identität 2, die in einem Nutzerkonto 22 bei einem föderierten Identitätsgeber 21 hin terlegt ist. Die verifizierte digitale Identität 2 besteht z.B. aus persönlichen Daten und Angaben des Endnutzers 10 wie Name, Email- Adresse, Zustellan schrift oder Bankverbindung, deren Richtigkeit gegenüber einem Identitäts geber 21 bereits bestätigt wurde.

Die persönlichen Daten und Angaben sind Attribute 9 der digitalen Identität 2. Jedes Attribut 9 besteht aus einem Attributnamen 4 und einem Attribut wert 3.

Die Attribute 9 sind nicht auf für den Geschäftsverkehr typische Angaben wie die angeführten beschränkt. Attribute 9 können vielmehr jegliche Anga ben sein, die einem Endnutzer 10 zugeordnet sind wie beispielsweise per sönliche Bilder oder Audiodateien.

Für eine bessere Übersichtlichkeit zeigt das in Fig. 1 dargestellte System je weils einen föderierten Identitätsgeber 21, einen abhängigen Dienst 11 und einen Nutzer- Agenten 13; reale Systeme weisen in der Regel jeweils eine Mehrzahl von zusammengeschlossenen föderierten Identitätsgebern, abhän gigen Diensten und Nutzer- Agenten auf. Die Menge der verbundenen föde rierten Identitätsgeber 21 bildet zusammen die Föderation. Im weiteren wer den die föderierten Identitätsgeber einfach als Identitätsgeber 21 bezeichnet.

Bei dem Betreiber des abhängigen Dienstes 11 kann es sich beispielsweise um eine Bank, eine Behörde oder um einen Internethändler handeln. Der ab hängige Dienst 11 besteht typischerweise in der Bereitstellung einer digitalen Leistung, Dienstleistung oder Funktion im Zusammenhang mit einer digita len Ressource, für die der Zugriff auf einen bestimmten Endnutzer oder ei ner definierten Gruppe von bestimmten Endnutzern beschränkt ist. Eine di gitale Dienstleistung oder Funktion im Zusammenhang mit einer digitalen Ressource kann beispielsweise die Eröffnung oder Führung eines Bankkon tos, die Durchführung eines Kaufgeschäftes bei einem Online-Händler oder die Vornahme einer Verwaltungshandlung wie z.B. die Nutzung einer Aus weiskarte gegenüber einer Prüfungs stelle sein. Im weiteren wird die von dem abhängigen Dienst erbrachte Leistung, Dienstleistung oder Funktion kurz als digitale Dienstleistung 12 bezeichnet.

Der abhängige Dienst 11 ist zugangsgeschützt. Für die Nutzung der digita len Dienstleistung 12 ist eine Authentisierung des Endnutzers 10 erforder lich, die seine Berechtigung nachweist. Dies geschieht typischerweise in ei nem Login-Vorgang durch Vorlage von Authentisierungsdaten in Form ei ner verifizierten digitalen Identität 2 bzw. von einzelnen Attributen 9 einer verifizierten digitalen Identität 2. Für die Bereitstellung der Authentisie rungsdaten nutzt der abhängige Dienst 11 das föderative Identitäten-Ma- nagement-System 1. Bei dem abhängigen Dienst 11 ist eine Identifikation IDM der Mittlereinheit 16 hinterlegt, die diese bei der Registrierung angibt. Bei dem abhängigen Dienst 11 ist weiter ein Zertifikat ZTM der Mittlereinheit 16 mit einem öf fentlichen Schlüssel OKM der Mittlereinheit 16 hinterlegt.

Der Identitätsgeber 21 verwaltet ein oder mehrere Nutzerkonten 22 eines o- der mehrerer Endnutzer 10 und nimmt die Identifikation und Verifikation von Endnutzern 10 vor. Zweckmäßig kann der Identitätsgeber 21 auf einem dem OpenIDConnect de-fakto Standard entsprechenden ID Provider basie ren.

Der Identitätsgeber 21 verfügt über einen von einer nicht gezeigten allge mein zugänglichen Zertifizierungs stelle ausgegebenen privaten Schlüssel PPA zur Ausgabe und Signierung von Token. Der korrespondierende öffent liche Schlüssel OKI wird über ein Zertifikat an die Mittlereinheit 16 übertra gen.

Der Vermittlerdienst 15 stellt sich gegenüber der Föderation der Identitätsge ber 21 wie ein - einzelner - abhängiger Dienst 11 dar. Zu den verbundenen abhängigen Diensten 11 hin weist der Vermittlerdienst 15 eine übliche Schnittstelle auf. In einer zweckmäßigen Ausgestaltung stellt der Vermittler dienst 15 eine standard-konforme OpenIDConnect-Schnittstelle zur Verfü gung und zeigt deren Verhalten.

In der Mittlereinheit 16 ist für jeden Identitätsgeber 21 ein öffentlicher Schlüssel OKI hinterlegt, mit dem ein Token eines Identitätsgebers 21 verifi ziert werden kann. Die Schlüssel OKI werden per Zertifikat an die Mitt lereinheit 16 übergeben. Die Mittlereinheit 16 verfügt weiter über einen privaten Schlüssel PKV zur Signierung von Token. Der korrespondierende öffentliche Schlüssel OKV wird in Zertifikaten, die von einer nicht gezeigten allgemein zugänglichen Zertifizierungs stelle stammen, an die abhängigen Dienste 11 übertragen.

Für die Bereitstellung einer Identität kommunizieren die Komponenten des Identitäten-Management-Systems 1 über gesicherte Kommunikationskanäle, die die Vertraulichkeit der Daten auf dem Transportweg sicherstellen und die Authentizität der kommunizierenden Komponenten gewährleisten. Die gesicherten Kommunikationskanäle werden über die zwischen den Kompo nenten bestehenden Datenverbindungen 24 eingerichtet. Gesicherte Kommu nikationskanäle können beispielsweise in Form von TLS-Verbindungen aus gebildet sein. Die Sicherung erfolgt beispielsweise durch Mutual TLS Au- thentication.

Zwischen dem abhängigen Dienst 11 und der Mittlereinheit 16 sowie zwi schen der Mittlereinheit 16 und dem Identitätsgeber 21 besteht jeweils ein gesicherter Datenkanal zu Übertragung von Token 5, 6, 7, 8. Zwischen dem abhängigen Dienst 11 und dem Identitätsgeber 21 besteht durch die Mitt lereinheit 16 hindurch ein gesicherter Attributeübertragungskanal 19, über die die gesicherte Übertragung von Attributen 9 einer verifizierten digitalen Identität 2 möglich ist.

Die Sicherheit des Identitäten-Management-Systems 1 wird besonders mit Token und Zertifikaten erreicht.

Token 5, 6, 7, 8 werden durch die Mittlereinheit 16 und die Identitätsgeber 21 erzeugt. Unter einem Token wird ein strukturiertes verschlüsseltes Datum verstanden, das es ermöglicht, IdenÜtäts- und SicherheitsinformaÜonen über verschiedene Sicherheits bereiche hinweg gemeinsam zu nutzen. Ein

Token wird durch die Mittlereinheit 16 oder die Idenhtätsgeber 21 ausgege ben und von einer vertrauenswürdigen Komponente konsumiert, die sich auf seinen Inhalt verlässt, um ein Subjekt eines Tokens für einen sicherheits relevante Zweck zu identifizieren.

Fig. 4 veranschaulicht die Struktur eines Tokens. Sie umfasst ein Kopfteil, ei nen Nutzlast-Teil sowie einen Signatur-Teil. Der Kopfteil enthält eine ein deutige Kennung TKV, TKF des jeweiligen Token. Der Nutzlast-Teil enthält zum Beispiel den Namen eines abhängigen Dienstes 11. Der Signatur-Teil enthält eine mit dem geheimen Schlüssel des Herausgebers erstellte Signatur über den Inhalt des Kopfteils und des Nutzlast-Teils.

Ein Token ist mittels eines privaten Schüssels signiert und kann nicht verän dert werden. Seine Gültigkeit kann jederzeit durch einen korrespondieren den öffentlichen Schlüssel bzw. ein Zertißkat überprüft werden. Es hat wei terhin eine vorgegebene Lebensdauer. Nach deren Ablauf wird ein Token nicht mehr als gültig angesehen. Jedes Token hat ferner eine eindeuhge Ken nung TKV, TKF. Das Token hat einen Herausgeber; dies ist die Komponente, die das Token erzeugt und signiert hat. Der Herausgeber hat als einziger Zu griff auf den privaten Signier-Schlüssel.

Struktur und Verwendung von Token sind bekannt. Im Rahmen dieser Be schreibung wird von Token in Gestalt von JSON Web Token (JWT) ausge gangen. Andere Darstellungsform der Token sind aber ebenso möglich.

Zertifikate sind signierte Datenstrukturen. Wie bei Token ist die Integrität von Zerhhkaten durch eine Signatur geschützt. Damit können Zertihkate nach der Erzeugung nicht mehr verändert werden, bzw. die Veränderung kann leicht mit einem öffentlichen Schlüssel festgestellt werden. Zertifikate können nur von einer besonderen Komponente, z.B. der System-Zertifizie rungsinstanz 18, ausgestellt werden, der von allen Komponenten vertraut wird. Nur die besondere Komponente hat Zugriff auf den privaten Schlüssel, der zur Signierung verwendet wird. Zertifikate beziehen sich auf ein Subjekt hn hier beschriebenen Verfahrens ist das Subjekt die Kennung TKV, TKF ei nes Tokens. Zertifikate haben ferner eine Lebensdauer. Diese ist an die Le bensdauer des Tokens gebunden, dessen Kennung als Subjekt bezeichnet ist. Zertifikate binden einen öffentlichen Schlüssel an ein Subjekt.

Wie Token können Zertifikate unterschiedliche Darstellungsformen aufwei sen. Für die Funktionsfähigkeit der beschriebene Lösung ist die konkrete Darstellungsform nicht relevant.

In einer Ausgestaltungsvariante können Zertifikate auch durch Token ersetzt werden. In diesem Fall erzeugt die System-Zertifizierungsinstanz 18 für au torisierte abhängige Dienste 11 ein Token mit entsprechenden Tokenattribu ten, sodass die Zertifikationsfunktion abgebildet werden kann.

In der Mittlereinheit 16 ist für jeden in die Föderation eingebundenen Identi tätsgeber 21 mindestens ein Zertifikat ZIF hinterlegt. Die Zertifikate ZIF wer den zweckmäßig angelegt, wenn ein neuer Identitätsgeber 21 in die Födera tion integriert wird.

Anhand des Ablaufdiagramms in Fig.2 wird nachfolgend der Ablauf der Be reitstellung einer verifizierten digitalen Identität 2 für einen abhängigen Dienst 11 in einem Identitäten-Management-System 1 erläutert. Für diese Beschreibung wird ein Endnutzer 10 angenommen, der bereits ein erstes Nutzerkonto 22 bei einem Identitätsgeber 21 eingerichtet hat. In dem Nutzerkonto 22 ist bei dem Identitätsgeber 21 eine verifizierte digitale Identi tät 2 des Endnutzers 10 mit mindestens einem Attribut 9 hinterlegt, deren Richtigkeit gegenüber dem Identitätsgeber 21 bereits bestätigt wurde. Attri bute 9 können zum Beispiel Name, Email-Adresse, Zustellanschrift oder Bankverbindung sein oder auch persönliche Bilder oder Audiodateien für die konkrete Daten oder Angabe hinterlegt wurden.

Das Nutzerkonto 22 bei dem Identitätsgeber 21 ist zugangsgeschützt. Um Zugang zu erhalten ist im Rahmen eines Login-Verfahrens eine Authentisie- rung erforderlich, zum Beispiel durch Präsentation eines Passwortes.

Der Endnutzer 10 möchte auf eine geschützte digitale Dienstleistung 12 zu greifen, die von einem abhängigen Dienst 11 bereitgestellt wird, bei dem der Endnutzer 10 noch kein Zugangskonto hat bzw. gegenüber dem er sich nicht authentisiert hat. Um die digitale Dienstleistung 12 bzw. den abhängigen Dienst 11 nutzen zu können, möchte der Endnutzer 10 eine bereits hinter legte verifizierte Identität 2 nutzen. Diese soll dem abhängigen Dienst 11 be reitgestellt werden.

Die Durchführung der Identitätsbereitstellung setzt einen sicheren Kommu nikationskanal zwischen dem abhängigen Dienst 11 und dem Identitätsgeber 21 voraus. Ein solcher sicherer Kommunikationskanal kann mit einem übli chen Verfahren zum Einrichten eines sicheren Übertragungskanals einge richtet werden. Beispielsweise kann ein Schlüsselaustausch durch ein„Key- Wrapping" Verfahren vorgesehen sein, in dem ein geheimer Schlüssel in ei nem Kryptogramm übertragen wird. Der Vorgang der Bereitstellung einer verifizierten digitalen Identität 2 wird ausgelöst, wenn ein Endnutzer 10 eine bei einem abhängigen Dienst 11 ange botene digitale Dienstleistung 12 nutzen möchte, die im Rahmen eines Lo- gin-Vorgangs die Durchführung einer Authentisierung erfordert. Nachfol gend werden die Schritte des Vorgangs erläutert.

Schritt 100: Der Endnutzer 10 wählt über die Endnutzer-Schnittstelle 14 ei nen gewünschten abhängigen Dienst 11 aus. Der Endnutzer 10 klickt dazu zum Beispiel auf ein auf einer Auswahlseite des abhängigen Dienstes 11 dar gestelltes Schaltfeld, mit dem die Internet-Adresse des abhängigen Dienstes ausgewählt wird.

Schritt 102: Der Nutzer- Agent 13, z.B. ein Web-Browser, eröffnet eine Verbin dung zu der öffentlichen Schnittstelle des ausgewählten abhängigen Diens tes 11 und schickt eine Anfrage an diesen. Die Anfrage kann beispielsweise die Form einer Login-Anfrage an die Internetadresse des abhängigen Diens tes sein

Schritt 104: Der abhängige Dienst 11 prüft die Anfrage. Stellt er fest, dass die Anfrage auf eine geschützte digitale Dienstleistung 12 gerichtet ist, die eine Authentisierung erfordert, und liegen entsprechende Authentisierungsdaten nicht vor, startet er einen Login-Vorgang. hn angenommenen Szenario stellt der abhängige Dienst 11 fest, dass die durch die Anfrage adressierte digitale Dienstleistung 12 geschützt ist und keine Authentisierungsdaten vorliegen. Der abhängige Dienst 11 startet des halb einen Login-Vorgang. Schritt 106: Der abhängige Dienst 11 erzeugt eine Auswahlseite (Website) mit einem Schaltfeld, über das die Herstellung einer Verbindung zu der Mitt lereinheit 16 ausgelöst wird. Zweckmäßig enthält die Auswahlseite Angaben zu dem abhängigen Dienst 11. Sie kann weitere Angaben enthalten, zum Bei spiel Namen der für den Login-Vorgang benötigten Attribute. Die Auswahl seite schickt der abhängige Dienst 11 an den Nutzer- Agenten 13.

Schritt 108: Die Auswahlseite wird dem Endnutzer 10 über die Endnutzer- Schnittstelle 14 angezeigt.

Fig. 3a zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung des abhängigen Dienstes („Abhängi ger Dienst"), eine Bezeichnung des ausgeführten Verfahrens Schrittes („Sign- In Prozess") sowie zwei Schaltfelder, von denen eines („Sign-In mit lokalem Konto") sich auf ein lokales Konto bei dem abhängigen Dienst richtet und das andere („Sign-In mit ID-Föderation") die Bereitstellung einer digitalen Identität über einen Identitätsgeber auslöst.

Der Endnutzer 10 betätigt das auf den Identitätsgeber zeigende Schaltfeld. Der Nutzer- Agent 13 stellt daraufhin eine Verbindung zu der Mittlereinheit 16 her.

In einer alternativen Ausführung veranlasst die Auswahlseite den Nutzer- Agenten 13 über eine direkte Weiterverweisung (Redirection) ohne Betäti gung des Schaltfeldes unmittelbar zur Herstellung einer Verbindung mit der Mittlereinheit 16. Schritt 110: Über die hergestellte Verbindung schickt der Nutzer-Agent 13 eine Autorisierungsanfrage an die Mittlereinheit 16. Die Autorisierungsan- frage enthält zweckmäßig Angaben zu dem gewählten abhängigen Dienst 11. Sie kann weiterhin Namen von bestimmten Attributen enthalten, die dem abhängigen Dienst 11 vorgelegt werden sollen. Sie kann darüber hinaus wei tere Angaben enthalten, die den vom Endnutzer 10 beabsichtigten Zugriff auf den abhängigen Dienst 11 charakterisieren. Die Autorisierungsanfrage kann beispielsweise in Form eines GET-Kommandos erfolgen, mit dem die Übermittlung einer Auswahlseite zur Auswahl eines Identitätsgebers ange fordert wird.

Schritt 112: Auf die Autorisierungsanfrage hin erzeugt die Mittlereinheit 16 eine Auswahlseite, in der alle in der Föderation zusammengeschlossenen Identitätsgeber 21 aufgeführt sind.

Die äußere Form der Auswahlseite und die Darstellung der Identitätsgeber sind frei gestaltbar. Denkbar ist zum Beispiel eine Auswahlseite mit Finks, Buttons, Icons oder ähnlichen Steuerelementen.

Fig. 3b zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung der Mittlereinheit („ID-Mana gement Broker") sowie vier Schaltfelder, von denen drei zu verschiedenen Identitäts gebern führen („ Authentifikation mit ID-A",„ Authentifikation mit ID-B",

„ Authentifikation mit ID-C") und eines zurück zu dem abhängigen Dienst („Zurück zum abhängigen Dienst").

Vorgesehen sein kann, dass die Auswahlseite personalisiert wird, indem eine Vorselektion von angebotenen Identitätsgebern erfolgt. Als Kriterien können zum Beispiel mit der Autorisierungsanfrage übersandte Angaben zu dem gewählten abhängigen Dienst 11, Attributnamen 4 oder Angaben zu weiteren bekannten Eigenschaften des beabsichtigten Zugriffs verwendet werden.

In einer weiteren Ausgestaltung kann vorgesehen sein, dass der Endnutzer 10 aufgefordert wird, seinen Namen oder ein anderes persönliches Datum zu übermitteln, um eine personalisierte Auswahlseite zu erzeugen. Ferner kön nen auch andere Faktoren wie z.B. der Ort zur Gestaltung der Auswahlseite verwendet werden.

Schritt 114: Die Auswahlseite schickt die Mittlereinheit 16 an den Nutzer- Agenten 13. Über die Endnutzer-Schnittstelle 14 wird die Auswahlseite dem Endnutzer 10 angezeigt.

Schritt 200: Der Endnutzer 10 selektiert in der angezeigten Auswahlseite ei nen Identitätsgeber 21, der die für den anstehenden Login-Vorgang benötig ten Attribute 9 bereitstellen kann. Es wird angenommen, dass dem Endnut zer 10 bekannt ist, welcher Identitätsgeber 21 geeignet ist. Gegebenenfalls kann der Endnutzer 10 die Namen 4 der benötigten Attribute von dem ab hängigen Dienst 11 abfragen. Ist die Auswahlseite personalisiert, werden zweckmäßig nur solche Identitätsgeber 21 zur Auswahl angeboten, die die benötigten Attribute 9 bereitstellen können.

Schritt 202: Nachdem der Endnutzer 10 einen Identitätsgeber 21 ausgewählt hat, schickt der Nutzer- Agent 13 eine Anfrage an den gewählten Identitäts geber 21. Schritt 204: Auf die Anfrage erzeugt der Identitätsgeber 21 eine Auswahl seite für die Identifikation und Verifikation des Endnutzers 10 und schickt diese an den Nutzer- Agenten 13, wo sie über die Endnutzer-Schnittstelle 14 dem Endnutzer 10 angezeigt wird.

Fig. 3c zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung des Identitätsgebers („ID-Pro vieler"), eine Bezeichnung des ausgeführten Verfahrensschrittes („Identifikation & Verifikation"), interaktive Felder („Nutzer Name",„Password",„OTP") zur Eingabe von Authentisierungsdaten sowie ein Schaltfeld zur Prüfung von eingegebenen Daten („Starte Authentifizierung"). Die Eingabe von Authenti sierungsdaten kann auch, wie in Fig. 3c dargestellt, mittels eines Hilfsgerä tes, etwa eines Handys, erfolgen. Als Authentisierungsdaten kommen auch biometrische Daten, zum Beispiel ein Fingerabdruck, in Betracht.

Schritt 300: Der Endnutzer 10 authentifiziert sich in an sich bekannter Weise durch Präsentation eines oder mehrerer Authentisierungsfaktoren, die den Endnutzer 10 eindeutig identifizieren. Beispielsweise präsentiert er über ent sprechende Eingabemittel seinen Namen und/ oder ein Password und/ oder, ein biometrisches Merkmal wie einen Fingerabdruck oder ein Irismuster.

Schritt 302: Der Nutzer- Agent 13 leitet die Eingaben an den Identitätsgeber 21. Der Identitätsgeber 21 prüft die präsentierten Authentisierungsfaktoren. Bei erfolgreicher Prüfung ist der Endnutzer 10 identifiziert und es steht fest, dass der Endnutzer 10 zu einem bei dem Identitätsgeber 21 bestehenden Nutzerkonto 22 gehört. Der Identitätsgeber 21 erzeugt dann einen Aktions code CAK, der eine eindeutige Identifikation der erfolgten Authentifikation ermöglicht. Der Aktionsode CAK dient im weiteren Verfahren dazu, von einem Identi tätsgeber 21 ein zweites Datum 7 in Form eines FI-Zugangstokens zu erhal ten, mit dem der Identitätsgeber 21 die Berechtigung eines Datenaustausche zwischen dem Vermittlerdienst 15 und dem Identitätsgeber 21 überprüft.

Die Nutzung muss innerhalb einer kurzen Zeitspanne ab Ausgabe des Akti onscodes CAK erfolgen.

Schritt 304: Der Identitätsgeber schickt den Aktionscode CAK als Antwort an den Nutzer-Agenten 13. Die Antwort beinhaltet eine Weiterverweisung.

Schritt 306: Der Nutzer- Agent 13 leitet die Antwort des Identitätsgebers 21 mit dem Aktionscode CAK in einer Anfrage an die Mittlereinheit 16 weiter. Die Mittlereinheit 16 erhält die Anfrage und den Aktionscode CAK als Para meter.

Schritt 308: Die Mittlereinheit 16 kontaktiert den Identitätsgeber 21 mit dem Aktionscode CAK als Parameter.

Schritt 310: Der Identitätsgeber 21 prüft den erhaltenen Aktionscode CAK auf Übereinstimmung mit dem in Schritt 302 ursprünglich versandeten Akti onscode CAK.

Ist das der Fall, d.h. handelt es sich um dieselbe laufende Authentifikation, erzeugt der Identitätsgeber 21 einen FI-Zugangstoken 7. Weiter erzeugt der Identitätsgeber einen FI- Auffrischungstoken 8. Weiterhin erzeugt der Identi tätsgeber 21 eine Sitzungsidentifikation IDS.

Der FI-Zugangstoken 7 dient im weiteren Verlauf des Verfahrens dazu, ei nen sicheren Attributeübertragungskanal 19 aufzubauen, über den für den Zugriff auf eine geschützte digitale Dienstleistung 12 benötigte Attribute 3 übertragen werden.

Mit dem FI- Auffrischungstoken 8 kann automatisiert ein neues FI- Zugangstoken 7 generiert werden, wenn das alte abgelaufen ist.

Schritt 312: FI-Zugangstoken 7, FI- Auffrischungstoken 8 und Sitzungsidenti fikation IDS übergibt der Identitätsgeber 21 an die Mittlereinheit 16. Zweck mäßig übermittelt der Identitätsgeber 21 zudem eine Liste mit den Attribut namen 4, die zu dem Nutzerkonto 22 zur Verfügung stehen.

Die Liste der Attributnamen 4 der zur Verfügung stehenden Attribute 9 spei chert die Mittlereinheit 16 in ihrem Speicherbereich 20. Zweckmäßig legt sie eine Tabelle 23 an, in die im Verlauf des weiteren Verfahrens weitere Ein träge hinzugefügt werden.

Schritt 314: Die Mittlereinheit 16 verifiziert den FI-Zugangstoken 7 und den FI- Auffrischungstoken 8 mithilfe des hinterlegten Zertifikats ZIF des Identi tätsgebers. Ist die Prüfung der Token 7, 8 erfolgreich, gilt der Endnutzer 10 für die Mittlereinheit 16 als verifiziert.

Die Mittlereinheit 16 speichert den FI-Zugangstoken 7 und den FI- Auffrischungstoken 8 in ihrem Speicherbereich 20. In einfacher Weise nutzt die Mittlereinheit 16 dazu die Tabelle 23 und fügt die Token 7, 8 hinzu. Die Token 7, 8 werden nicht an den Endnutzer 10, den Nutzer- Agenten 13 oder an den abhängigen Dienst 11 übergeben.

Schritt 316: Die Mittlereinheit 16 erzeugt eine Auswahlseite mit einer Liste mit den Attributnamen 4 der zur Verfügung stehenden Attribute 9 und schickt diese an den Nutzer- Agenten 13, wo sie dem Endnutzer 10 über die Endnutzer-Schnittstelle 14 angezeigt wird.

Fig. 3d zeigt beispielhaft einen Bildschirminhalt einer Auswahlseite mit einer angezeigten Liste von Attributnamen. Sie enthält eine Bezeichnung des Ver mittlerdienstes („ID-Mana gern ent Broker"), eine Bezeichnung des Verfah rensschritte („Zustimmung zur Weitergabe an abhängigen Dienst"), den Na men eines gesonderten Attributs in Form eines Endnutzernamens („John- Doe"), eine zweispaltige Tabelle mit den Namen jeweils weiteren Attribute („profile", email",„address", phone") und Zustimmungsbox sowie ein Schaltfeld („Zustimmung") zur Zustimmung zu einer Attributeauswahl.

Schritt 400: Der Endnutzer 10 selektiert die Namen 4 der Attribute, für die eine Weitergabe der Attribute 3 an den abhängigen Dienst 11 erlaubt werden soll. Durch Betätigung eines entsprechenden Schaltfeldes in der Auswahl seite werden die ausgewählten Attribute 9 zur Weitergabe freigegeben.

Grundsätzlich kann der Endnutzer 10 auch alle Attribute 9 bzw. die gesamte digitale Identität 2 auswählen.

Schritt 402: Der Nutzer- Agent 13 sendet die Attributnamen 4 der zur Weiter gabe an den abhängigen Dienst 11 freigegebenen Attribute 9 an die Mitt lereinheit 16.

Schritt 404: Die Mittlereinheit 16 speichert die für den gewählten abhängigen Dienst 11 freigegebenen Attributnamen 4 in ihrem Speicherbereich 20.

Zweckmäßig fügt sie die Einträge in die Tabelle 23 ein.

Soll später erneut eine Autorisierung für denselben abhängigen Dienst 11 er folgen, kann die Mittlereinheit 16 auf die im Speicherbereich 20 abgelegte Freigabe zurückgreifen. Eine erneute Freigabe durch den Endnutzer 10 durch Ausführung des Schrittes 400 ist dann nicht erforderlich.

Schritt 406: Die Mittlereinheit 16 erzeugt einen Sitzungscode CSM. Der Sit zungscode CSM dient im weiteren Verlauf des Verfahrens dazu, von der Mittlereinheit 16 ein erstes Datum in Form eines V-Zugangstokens 5 zu er halten. Mit diesem überprüft der Vermittlerdienst 15 die Berechtigung eines Datenaustauschs zwischen dem Vermittlerdienst 15 und dem abhängigem Dienst 11.

Die Mittlereinheit 16 erzeugt weiter eine Weiterverweisungsantwort mit dem Sitzungscode CSM und einer Status-Information. Den Sitzungscode CSM speichert die Mittlereinheit 16 zweckmäßig in ihrem Speicherbereich 20; zweckmäßig wird er in die Tabelle 23 eingefügt.

Schritt 408: Der Nutzer- Agent 13 leitet die Weiterverweisungsantwort an den abhängigen Dienst 11 weiter. Als Parameter werden der Sitzungscode CSM sowie die Status-Information übertragen.

Schritt 410: Der abhängige Dienst 11 sendet eine Token-Anfrage an die Mitt lereinheit 16. Als Parameter wird der Sitzungscode CSM übergeben.

Schritt 412: Die Mittlereinheit 16 identifiziert über den Sitzungscode CSM die Sitzung und erzeugt mit dem Signier-Schlüssel der Mittlereinheit einen V- Zugangs-Token 5 mit einer Kennung TKV sowie einen V-Auffrischungs-To- ken 6. Der Kennung TKV des V-Zugangstokens 5 wird dabei durch eine Hash- Funktion aus der Kennung TKF des FI-Zugangstokens 7 des Identitätsge bers gebildet. Auf diese Weise wird eine technische Verknüpfung zwischen dem FI-Zugangstoken 7 und dem V-Zugangstoken 5 hergestellt. Ausgehend von einem FI-Zugangstoken 7 kann eine bestehende Verknüpfung überprüft werden.

Der V-Zugangs-Token 5 und der V-Auffrischungs-Token 6 werden an den abhängigen Dienst 11 ausgegeben. Der V-Zugangs-Token 5 dient im weite ren Verlauf des Verfahrens zum Aufbau eines sicheren Attributeübertgungs- kanals 19, über den für den Zugriff auf eine geschützte digitale Dienstleis tung 12 benötigte Attribute 3 übertragen werden. Der V-Zugangs-Token 5 und der V-Auffrischungs-Token 6 werden nicht an den Endnutzer 10 oder den Nutzer-Agenten 13 übergeben.

Mit dem V-Auffrischungs-Token 6 kann der abhängige Dienst 11 einen neuen V-Zugangs-Token 5 beantragen.

Weiter erzeugt die Mittlereinheit 16 einen Eintrag in ihren internen Speicher bereich 20, welche die Attributnamen 4 enthält, die der Endnutzer 10 freige geben hat. Der Eintrag bezeichnet die laufende Bereitstellungssitzung und enthält weiterhin die FI-Zugangstoken 7, 8 sowie die durch die Mittlereinheit 16 erzeugten V-Zugangstoken 5, 6. In einfacher Weise können alle Einträge in der Tabelle 23 zusammengefasst sein. Zweckmäßig sind in der Tabelle 23 weitere Daten hinterlegt, die im Rahmen der Bereitstellung der Attribute be nötigt werden. Die Tabelle 23 kann beispielsweise wie folgt aussehen:

Die Mittlereinheit 16 erzeugt weiterhin eine eindeutige Kontokennung KID und speichert sie in ihrem Speicherbereich 20. Die Kontokennung KID kenn zeichnet den Endnutzer 10 bzw. das Nutzerkonto 22 eindeutig in der gesam- ten Föderation. Die Kontokennung KID wird einmalig für jedes Nutzerkonto 22 erzeugt und ist unveränderlich.

Die Kontokennung KID basiert zweckmäßig auf einer verschleierten Ver knüpfung eines Nutzerkontos 22 und eines Identitätsgebers 21. Die Ver- schleierung erfolgt so, dass keine Rückschlüsse auf den Identitätsgeber 21 möglich sind. Beispielsweise kann eine Hash-Funktion angewendet werden, mit der ein Hashwert über eine gegenüber dem Identitätsgeber 21 genutzte OpenldConnect Identifikation der Mittlereinheit 16 gebildet wird. In einer anderen Ausführung wird ein Hashwert über eine von der Mittlereinheit 16 durch Konfiguration im Rahmen des Registrierungsprozesses zur Aufnahme eines Identitätsgebers 21 in die Föderation festgelegte Konstante in den Stammdaten der Mittlereinheit 16 für den Identitätsgeber 21 gebildet. Schritt 414: V-Zugangstoken 5 und V- Auffrischungstoken 6 schickt die Mitt lereinheit 16 an den abhängigen Dienst 11.

Schritt 416: Der abhängige Dienst 11 verifiziert die erhaltenen V-Token 5, 6 mithilfe des öffentlichen Schlüssels OKM aus dem vorab hinterlegten Zertifi kat ZTM der Mittlereinheit.

Schritt 498: Für die Übertragung von Attributen 3 von dem Identitätsgeber 21 an den abhängigen Dienst 11 über die Endnutzerinformationsschnittstelle wird ein Attributeübertragungskanal 19 eingerichtet.

Dazu wird zwischen dem abhängigen Dienst 11 und der System-Zertifizie rungsinstanz 18 eine gesicherte Verbindung mit wechselseitiger Authentifi- zierung auf gebaut, zum Beispiel eine TLS B2B Verbindung.

Der abhängige Dienst 11 erzeugt ein Schlüsselpaar mit einem öffentlichen Schlüssel OKA und einem privaten Schlüssel PKA. Der abhängige Dienst 11 erzeugt weiter eine Sitzungsidentifikation SZI. In einfacher Weise kann als Sitzungs Identifikation SZI die Kennung TKV des V-Zugangstokens 5 dienen. Der öffentliche Schlüssel OKA und die Sitzungsidentifikation SZI werden über die gesicherte Verbindung in einer Zertifikatsanfrage an die System- Zertifizierungsinstanz 18 gesendet.

Der private Schlüssel PKA verbleibt bei dem abhängigen Dienst 11. Die Zer tifikatsanfrage kann als CSR (Certificate Signing Request)-Kommando erfol gen, das als Parameter den öffentlichen Schlüssel OKA sowie die Sitzungsi dentifikation SZI aus dem V-Zugangstoken 5 enthält mit dem ein Sitzungs zertifikat angefordert wird. Schritt 500: Auf die Zertifikatsanfrage hin erzeugt die System-Zertifizie rungsinstanz 18 für die Sitzungsidentifikation SZI ein Sitzungszertifikat ZSZ.

Das Sitzungszertifikat ZSZ ist nur kurze Zeit gültig; seine Laufzeit entspricht mindestens der Lebensdauer des V-Zugangstokens 5. Das Sitzungszertifikat ZSZ enthält die Kennung TKV des V-Zugangstokens 5 und einen öffentli chen Schlüssel für die Sitzungsidentifikation SZI. Das Sitzungszertifikat ZSZ dient zudem als Nachweis, dass der abhängige Dienst 11 berechtigt ist, An fragen an die Mittlereinheit 16 zu stellen.

Schritt 502: Das Sitzungszertifikat ZSZ schickt die System-Zertifizierungs instanz 18 an den abhängigen Dienst 11.

Schritt 504: Der abhängige Dienst 11 initiiert den Aufbau eines sicheren At tributeübertragungskanals 19 über einen Aufruf an die Mittlereinheit 16.

Dies kann über einen eigenen Endpunkt erfolgen oder parametergesteuert über die Schnittstelle für einen Attributeübertragungskanal 19. Die Initiie rung kann beispielsweise mithilfe eines POST-Kommandos erfolgen, das als Parameter das V-Zugangstoken sowie das Sitzungszertifikat ZSZ übergibt..

Schritt 506: Die Mittlereinheit 16 prüft, ob der V-Zugangstoken 5 gültig und nicht abgelaufen ist. Ist das der Fall, ermittelt die Mittlereinheit 16 mithilfe des Verzeichnisses 20 das zu dem V-Zugangstoken 5 korrespondierende FI- Zugangstoken 7 des Identitätsgebers.

Den ermittelten FI-Zugangstoken 7 übersendet die Mittlereinheit 16 zusam men mit dem Sitzungs _Z ertifikat ZSZ an den Identitätsgeber 21. Schritt 508: Der Identitätsgeber 21 prüft, ob das von der Mittlereinheit 16 er haltene FI-Zugangstoken 7 gültig und nicht abgelaufen ist.

Weiter überprüft der Identitätsgeber 21 das Sitzungszertifikat ZSZ. Das Sit zungszertifikat ZSZ wird als gültig akzeptiert, wenn es ein CA-IDP Zertifikat ist und von der System-Zertifizierungsinstanz 18 signiert wurde, es nicht ab gelaufen ist und die im Subjekt des Sitzungszertifikats ZSZ enthaltene Ken nung TKV des V-Zugangstokens 5 dem damit verknüpften FI- Zugangstoken Token 7 entspricht. Für diese Prüfung rechnet der Identitäts geber 21 den Hash über die Token-Kennung ZKF des eigenen FI- Zugangstokens 7 nach. Die Bereitstellung der Signatur durch das Zertifikat ZSZ kann auch über eine Zertifikatskette erfolgen.

Schritt 510: Ist das Sitzungszertifikat ZSZ gültig, erzeugt der Identitätsgeber 21 einen zufälligen symmetrischen Sitzungsschlüssel KSY mit ausreichender Länge. Zweckmäßig werden mehrere Schlüssel zur Sicherung jeweils der In tegrität, der Vertraulichkeit und der Sequenz der Nachrichten erzeugt. Die Generierung der Schlüssel erfolgt zweckmäßig durch eine Schlüsselableitung aus einem zufälligen gemeinsamen Startwert.

Mit dem Sitzungsschlüssel KSY richtet der Identitätsgeber 21 auf seiner Seite den sicheren Attributeübertragungskanal 19 zu dem abhängigen Dienst 11 ein.

Schritt 512: Der Sitzungsschlüssel KSY wird mit dem öffentlichen Schlüssel OKA aus dem Sitzungszertifikat ZSZ zu einem Kryptogramm verschlüsselt und an die Mittlereinheit 16 übergeben. Da der private Schlüssel PKA beim abhängigen Dienst 11 verbleibt, hat die Mittlereinheit 16 keinen Zugriff auf den Sitzungsschlüssel KSY. Schritt 514: Die Mittlereinheit 16 gibt das Kryptogramm mit dem verschlüs selten Sitzungsschlüssel KSY an den abhängigen Dienst 11 weiter. Schritt 516: Der abhängige Dienst 11 entschlüsselt mit seinem privaten Schlüssel PKA das Kryptogramm und ermittelt so den Sitzungsschlüssel KSY. Mit diesen richtet der abhängige Dienst 11 den sicheren Attributeüber tragungskanals 19 auf seiner Seite ein. Der abhängige Dienst 11 verwendet die gleiche Schlüsselableitung wie der Identitätsgeber 21. Der Attributeüber- tragungskanal 19 ist damit hergestellt.

Nach Errichtung des Attributeübertragungskanals 19 erfolgt die Bereitstel lung der verifizierten digitalen Identität 2 bzw. von Attributen 9 vom Identi tätsgeber 21 an den abhängigen Dienst 11. Dabei überprüft die Mittlereinheit 16 die Berechtigung des Datenaustausche zwischen Mittlereinheit 16 und ab hängigem Dienst 11 aufgrund des V-Zugangstokens 5 und der Identitätsge ber 21 die Berechtigung des Datenaustausche zwischen Mittlereinheit 16 und Identitätsgeber 21 aufgrund des FI-Zugangstokens 7. Schritt 600: Der abhängige Dienst 11 ruft die Attribute 9 des Endnutzers von der Mittlereinheit 16 ab. Zur Authentisierung enthält der Aufruf den V-Zu- gangstoken 5. Der Aufruf kann zum Beispiel die Form eines GET- Kommandos besitzen. Schritt 602: Die Mittlereinheit 16 prüft den von dem abhängigen Dienst 11 er haltenen V-Zugangstoken 5. Im Gutfall ermittelt die Mittlereinheit 16 den FI- Zugangstoken 7, der zu dem von der Mittlereinheit erzeugten V-Zugangsto ken 5 aus der Anfrage gehört. Die Zuordnung kann direkt durch den V-Zu gangstoken 5 oder über die Sitzungsidentifikation SZI geschehen. Kann der V-Zugangstoken 5 nicht akzeptiert werden, gibt die Mittlereinheit 16 eine Fehlermeldung an den abhängigen Dienst 11 zurück.

Schritt 604: Die Mittlereinheit 16 schickt eine Anfrage an den Identitätsgeber 21. Die Anfrage enthält den FI-Zugangstoken 7 sowie die Attributnamen 3 der benötigten Attribute 9.

Schritt 606: Der Identitätsgeber 21 prüft den FI-Zugangstoken 7 darauf, ob er gültig ist und eine gültige Signatur aufweist. Ist das der Fall, erzeugt der Identitätsgeber 21 eine Antwort mit den angeforderten Attributen 9 des End nutzers, die für die Föderation sichtbar sein sollen, und den Attributnamen 4. Die Attributwerte 3 werden mit dem Sitzungsschlüssel KSY verschlüsselt. Die Attributnamen 4 der Attribute 9 werden unverschlüsselt in die Antwort aufgenommen.

Schritt 608: Die Antwort mit den verschlüsselten Attributen 9 sendet der Identitätsgeber 21 an die Mittlereinheit 16. Die Datenübertragung zwischen Mittlereinheit 16 und Identitätsgeber 21 erfolgt über den sicheren Attribute übertragungskanal 19.

Schritt 610: Die Mittlereinheit 16 prüft anhand der Attributnamen 4, ob die in der Antwort enthaltenen verschlüsselten Attribute 9 zur Weitergabe an den abhängigen Dienst 11 durch den Endnutzer 10 freigegeben wurden. Ist das der Fall erzeugt die Mittlereinheit 16 eine Liste mit den freigegebenen ver schlüsselten Attributen 3.

Schritt 612: Die Liste gibt die Mittlereinheit 16 als Antwort zurück an den ab hängigen Dienst 11. Schritt 614: Der abhängige Dienst 11 entschlüsselt aus der Antwort die ver schlüsselten Attributwerte 3 mit dem vom Identitätsgeber 21 übermittelten Sitzungsschlüssel KSY.

Schritt 616: Basierend auf den danach vorliegenden Attributen 9 des Endnut zers führt der abhängige Dienst 11 die Autorisierung durch und entscheidet, ob die Nutzung des angefragten abhängigen Dienstes 11 für die gewünschte digitale Dienstleistung 12 gewährt wird. Das Ergebnis wird dem Endnutzer 10 auf der Endnutzer-Schnittstelle 14 angezeigt. Beispielsweise wird dem Endnutzer 10 ein Nutzerkonto mit den übermittelten Attributen 9 angezeigt.

Fig. 3e zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Ergeb nisseite. Der Bildschirmeinhalt enthält eine Bezeichnung des abhängigen Dienstes („Abhängiger Dienst"), eine Bezeichnung des Verfahrensschrittes („Nutzer Konto"), einen Endnutzernamen ("John Doe") sowie eine zweispal tige Tabelle mit der Bezeichnung von Attributen („Id",„email",„email-sta- tus",„phone") und zugehörigen Werten („John-Doe",„John, Doe@....de", verified",„+1098922222"). hn Rahmen der grundlegenden Idee, mittels eines Vermittlerdienstes eine transparente Möglichkeit zur Bereitstellung einer verifizierten digitalen Identität in einem System mit einer Mehrzahl von abhängigen Diensten und einer Mehrzahl von Identitätsgebern gestattet das beschrieben Verfahren eine Vielzahl von Ausgestaltungsmöglichkeiten, die hier nicht im Einzelnen erläutert sind. Insbesondere ist es grundsätzlich möglich, die in den Figuren gezeigten und vorstehend beschriebenen Ausführungsbeispiele ganz oder in Teilen zu kombinieren. Einzelne Elemente können auch weggelassen oder zusammengefasst werden, z.B. einzelne der Verfahrensschrite. Auch kön nen Elemente durch vergleichbare andere Elemente ersetzt oder ergänzt werden. Beispielsweise ist zur gesicherten Übertragung von Attributen 9 die Einrich tung eines sichereren Übertragungskanals durch einfachen Schlüsselaus tausch beschrieben. Andere Verfahren kommen jedoch ebenfalls in Betracht. Dies gilt insbesondere auch für das konkrete Verfahren zur Schlüssel _V erein barung und zur Ableitung der Sitzungsschlüssel. Einzelne Funktionen kön- nen auch anderen Komponenten zugeordnet sein. Beispielsweise können einzelne von der Mitlereinheit ausgeführten Funktionen auch ganz oder teilweise in der System-Zertifizierungsinstanz realisiert sein.

Datenstrukturbezeichnungen

IDM Identifikation der Mittlereinheit

ZTM Zertifikat der Mittlereinheit

OKM Öffentlicher Schlüssel der Mittlereinheit

CSM Sitzungscode der Mittlereinheit

PPA Privater Schlüssel einer allgemeinen Zer ti fi i er ungs stelle OKI Öffentlicher Schlüssel des Identitätsgebers

PKV Privater Schlüssel des Vermittler dienstes

KSY Symmetrischer Sitzungsschlüssel des Identitätsgebers ZIF Zertifikat des Identitätsgebers

TOK Kennung Token

CAK Aktionscode

IDS Sitzungsidentifikation

TKV Kennung TKV des V-Zugangstokens

TKF Kennung TKF des FI-Zugangstokens

KID Kontokennung KID

OKA Öffentlicher Schlüssel erzeugt vom abhängigen Dienst PKA Privater Schlüssel erzeugt vom abhängigen Dienst ZSZ Sitzungszertifikat ZSZ der Zertifikatsinstanz

SZI Sitzungsidentifikation SZI

Bezugszeichenliste

1. Identitäten-Management-Sy stem

2. Digitale Identität

3. Attributwerte

4. Attributnamen

5. V-Zugangstoken 6. V-Auffrischungstoken

7. FI-Zugangstoken

8. FI-Auffrischungstoken

9. Attribute

10. Endnutzer

11. Abhängiger Dienst

12. Digitale Dienstleistung

13. Nutzer-Agent

14. Endnutzer-Schnittstelle

15. Vermittler dienst

16. Mittlereinheit

18. System-Zertifizierungsinstanz

19. Attributübertragungskanal

20. Speicherbereich

21. Föderierter Identitätsgeber (ID Provider)

22. Nutzerkonto

23. Tabelle

24. Datenverbindungen