DE102008013082A1

DE102008013082A1 - Verfahren und Anordnung zur Annahme einer digitalen Nutzer-Identität auf Grund transitiven Vertrauens zwischen Beteiligten

Info

Publication number: DE102008013082A1
Application number: DE102008013082A
Authority: DE
Inventors: Sourabh Fremont Satish; Brian San Carlos Hernacki
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 2007-03-28
Filing date: 2008-03-07
Publication date: 2008-11-20
Also published as: DE102008013079A1; DE102008013079B4

Abstract

Verfahren und Anordnung zur Annahme einer digitalen Identität eines Nutzers auf Grund eines transitiven Vertauens zwischen Beteiligten. Ein Aspekt der Erfindung betrifft die Verwaltung einer digitalen Identität eines Nutzers. Die digitale Identität, die ein selbstbehauptetes Attribut enthält, wird einem ersten Beteiligten bereitgestellt, der ein Akzeptanz-Token ausstellt. Das Akzeptanz-Token verweist auf die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten. Die digitale Identität und das Akzeptanz-Token werden einem zweiten Beteiligten bereitgestellt, um die Validierung des selbstbehaupteten Attributs durch den zweiten Beteiligten auf Grund des Akzeptanz-Tokens anzuordnen.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Ausführungsformen der Erfindung betreffen allgemein das digitale Identitätsmanagement. Insbesondere betrifft die Offenbarung ein Verfahren und eine Anordnung zur Annahme einer digitalen Nutzer-Identität auf Grund eines transitiven Vertrauens zwischen Beteiligten.
Beschreibung verwandter Technik
In einem Computernetz wie dem Internet versenden die Nutzer auf Anforderung einer bestimmte Anwendung bzw. eines bestimmten Dienstes typischerweise persönliche und vertrauliche Informationen. In einigen Fällen werden solche vertrauliche Informationen von einer abgesetzten Host-Instanz für den späteren Zugriff durch den Nutzer abgespeichert. Typischerweise authentisieren die Anwendungen die Nutzer, bevor sie die vertraulichen Informationen annehmen oder einen Zugriff auf sie zulassen. In einem bekannten Authentisierungsszenario werden ein Nutzername und ein Passwort über das Netz an eine Anwendung (bspw. eine Web-Seite im Internet) geschickt. Ein anderer – neuerer und sichererer – Authentisierungsmechanismus arbeitet mit einer digitalen Identität. Beim Übermitteln über ein Netz wird eine digitale Identität als Sicherungs-Bitfolge (auch als "Token" bezeichnet) wiedergegeben. Das Token weist ein oder mehrere Attribute ("claims") auf, die jeweils einen Teil der mit der digitalen Identität insgesamt übermittelten Information enthalten. Bspw. kann ein Token Attribute für einen Nutzernamen, ein Passwort, eine Kreditkartennummer und/oder vielfältige andersartige Informationen enthalten.
Einige Managementsysteme für digitale Identitäten sehen zwei Arten digitaler Identitäten vor: selbstbehauptete ("self-asserted") und verwaltete ("managed") Identitäten. Zur Unterscheidung zwischen diese beiden Identitätsarten ist es nützlich, drei klar getrennte Rollen zu definieren. Dabei ist ein Nutzer die Instanz, der die digitale Identität zugeordnet ist. Ein Identitätsanbieter ist eine Instanz, die einem Nutzer eine digitale Identität bereit stellt. Eine vertrauende (bzw. Vertrauens-)Instanz ist eine solche, die sich auf irgendeine Weise auf die digitale Identität verlässt. Bspw. kann die Vertrauensinstanz die digitale Identität benutzen, um den Nutzer zu authentisieren. Bei einer selbstbehaupteten Identität sind der Nutzer und der Identitätsanbieter identisch. Wird bspw. bei einem Online-Anbieter wie AMAZON.COM ein Konto eröffnet, erzeugt der Nutzer seine eigene Identität (bspw. einen Nutzernamen und ein Nutzer-Passwort). Eine verwaltete Identität ist eine stärkere Identitätsform, da die Informationen von dritter Seite gestützt bzw. gedeckt werden und daher als vertrauenswürdiger gelten. M. a. W.: die digitale Identität wird von einem Identitätsanbieter bereit gestellt, der sich vom Nutzer unterscheidet.
Bei einer selbstbehaupteten Identität muss eine Vertrauensinstanz zum Validieren des Nutzers und seiner selbstbehaupteten Attribute eigene Prozesse einsetzen; sie trägt folglich die Kosten der Validierung. Bei einer verwalteten Identität muss der Nutzer typischerweise direkte oder indirekte Gebühren zahlen, um vom Identitätsanbieter die Identität zu erhalten. Zusätzlich muss die Vertrauensinstanz den Identitätsanbieter sowie dessen Entscheidungsgrundsätze bzw. -strategien kennen, bevor er eine einem Nutzer erteilte verwaltete Identität akzeptiert. Wenn nicht der Nutzer, muss typischerweise die Vertrauensinstanz den Identitätsanbieter für die Benutzung der von ihm ausgegebenen Identitäten bezahlen. Folglich besteht Bedarf an einem Mechanismus der Identitätsverwaltung, der die aus der Erzeugung und der Benutzung von Identitäten bei Nutzern, Vertrauensinstanzen und Identitätsanbietern anfallenden Kosten verringert oder beseitigt.
Zusammenfassung der Erfindung
Es werden ein Verfahren und eine Anordnung zur Annahme einer digitalen Identität eines Nutzers auf Grund eines transitiven Vertrauens zwischen Beteiligten beschrieben. Ein Aspekt der Erfindung betrifft die Verwaltung der digitalen Identität eines Nutzers. Dabei wird einem ersten Beteiligten eine digitale Identität bereit gestellt, die ein selbstbehauptetes Attribut aufweist. Der erste Beteiligte gibt ein Akzeptanz-Token aus. Das Akzeptanz-Token verweist auf bzw. behauptet die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten. Die digitale Identität und das Akzeptanz-Token werden einem zweiten Beteiligten bereit gestellt, um die Validierung des selbstbehaupteten Attributs durch den zweiten Beteiligten auf Grund des Akzeptanz-Tokens anzufordern.
In einem anderen Beispiel stellt ein Computer einem ersten Beteiligten eine digitale Identität bereit, die ein selbstbehautpetes Attribut beinhaltet. Das selbstbehauptete Attribut wird vom ersten Beteiligten validiert, der das Akzeptanz-Token an den Computer schickt. Das Akzeptanz-Token deutet auf die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten hin. Die digitale Identität und das Akzeptanz-Token werden vom Computer einem zweiten Beteiligten bereit gestellt. Beim zweiten Beteiligten wird auf Grund des Akzeptanz-Tokens das selbstbehauptete Attribut validiert und ein transitives Vertrauen zwischen dem ersten und dem zweiten Beteiligten hergestellt.
Kurzbeschreibung der Zeichnungen
Zum besseren Verständnis der genannten Merkmale der vorliegenden, oben kurz zusammengefassten Erfindung wird diese an Hand von Ausführungsformen beschrieben, von denen einige in den beigefügten Zeichnungen dargestellt sind. Es sei jedoch darauf hingewiesen, dass die beigefüg ten Zeichnungen nur typische Ausführungsformen der vorliegenden Erfindung zeigen und daher nicht als den Umfang der Erfindung einschränkend aufzufassen sind; vielmehr lässt die Erfindung andere, gleich wirksame Ausführungsformen zu.
1 ist ein Blockschaltbild einer beispielhaften Ausführungsform eines vernetzten Computersystem nach einem oder mehr Aspekten der vorliegenden Erfindung.
2 zeigt als Flussdiagramm eine beispielhafte Ausführungsform eines Verfahrens zum Verwalten einer selbstbehaupteten digitalen Identität für einen Nutzer nach einem oder mehr Aspekten der Erfindung.
3 zeigt als Flussdiagramm eine andere beispielhafte Ausführungsform eines Verfahrens zum Verwalten einer selbstbehaupteten digitalen Identität für einen Nutzer nach einem oder mehr Aspekten der Erfindung.
Ausführliche Beschreibung
Die 1 zeigt als Blockschaltbild eine beispielhafte Ausführungsform eines vernetzten Computersystems 100 nach einem oder mehr Aspekten der Erfindung. Das System 100 weist ein Netz 102 auf, das mit einem Computer 104 verbunden ist. Der Computer 104 enthält beispielhaft einen Prozessor 108, einen Speicher 114, verschiedene unterstützende Schaltungen 110 und eine Eingabe-/Ausgabe-(E/A)-Schnittstelle 106. Der Prozessor 108 kann einen oder mehr Mikroprozessoren aufweisen, wie aus dem Stand der Technik bekannt. Die unterstützenden Schaltungen 110 für den Prozessor 108 sind u. a. ein herkömmlicher Cache, Stromversorgungen, Taktgeber, Datenregister, E/A-Schnittstellen u. dergl. Die E/A-Schnittstelle 106 kann direkt oder über den Prozessor 108 mit dem Speicher 114 verbunden sein. Die E/A-Schnittstelle 106 kann auch für Übertragungsverbindungen mit Ein- und/oder Ausgabe-Einrichtungen 111 bzw. 113 konfiguriert sein – bspw. Netzwerkkomponenten, verschiedene Speicher, eine Maus, eine Tastatur, eine Sichteinheit u. dergl. Desgl. kann die E/A-Schnittstelle 106 an das Netz 102 angeschlossen sein. Das Netz 102 weist ein Übertragungssystem auf, das Computersysteme über Drahtleitungen, Kabel, Lichtwellenleiter und/oder Funkstrecken sowie verschiedenartige bekannte Netzelemente wie Hubs, Switches, Router u. dergl. miteinander verbindet. Zur Informationsübertragung kann das Netz 102 mit verschiedenen bekannten Protokollen arbeiten. Bspw. kann es sich beim Netz 102 um einen Teil des Internets handeln.
Der Speicher 114 nimmt vom Prozessor ausführbare Befehle und/oder Daten auf, die vom Prozessor 108 ausgeführt und/oder benutzt werden können. Bei den vom Prozessor ausführbaren Befehlen kann es sich um Hardware, Firmware, Software u. dergl. jeweils einzeln oder in Kombination handeln. Die Module mit vom Prozessor ausführbaren, im Speicher 114 abgelegten Befehlen können u. a. einen Indentitätsmanager 116 enthalten. Der Computer 104 kann mit einem Betriebssystem 124 wie – unter anderen Plattformen – OS/2, Java Virtual Machine, Linux, Solaris, Unix, HPUX, AIX, Windows, Windows 95, Windows 98, Windows NT, Windows 2000, Windows ME, Windows XP, Windows Server programmiert sein. Mindestens ein Teil des Betriebssystems 124 kann sich im Speicher 114 befinden. Der Speicher 114 kann ein oder mehr der folgenden Speicherarten aufweisen: RAM, ROM, magnetoresistiven Schreib-/Lese-Speicher, optischen Schreib-/Lese-Speicher, Cache-Speicher, magnetischen Schreib-/Lese-Speicher u. dergl. sowie ein signalführendes Medium, wie unten beschrieben.
Der Identitätsmanager 116 ist konfiguriert, digitale Identitäten für einen oder mehr Nutzer des Computers 104 zu verwalten. Allgemein wird eine digitale Identität als Sicherungs-Token (Token) mit einem oder mehr Attributen dargestellt, die jeweils einen Teil der von der digitalen Identität mitgeteilten Gesamtinformation aufweisen. Eine digitale Identität kann so einfach wie eine Email-Adresse sein oder mehr Informationen aufweisen – bspw. einen Nutzernamen, ein Passwort, Kreditkartennummern, Sozialversicherungsnummer und/oder zahlreiche andere Informationsarten. Token können in zahlreichen be kannten Formaten vorliegen – bspw. als X.509-Zertifikate, Kerberos-Tickets u. dergl. Desgl. lassen sich Token unter Benutzung einer Standardsprache erzeugen – bspw. der Security Assertion Markup Language (SAML). Ein Beispiel eines Tokens ist eine Karte ("card") in MICROSOFT CARDSPACE; andere Beispiele sind Token nach dem OpenID-Protokoll, dem Lightweight Identity Protocol (LID), dem Secure Extensible Identity Protocol (SXIP) u. dergl.
In einer Ausführungsform verwaltet der Identitätsmanager 116 selbstbehauptete Identitäten 150, die jeweils ein oder mehr selbstbehauptete Attribute aufweisen. Bspw. kann ein Nutzer eine selbstbehauptete Identität mit einem Attribut für seine Email-Adresse festlegen. Nicht alle Geschäftsmodelle erfordern jedoch die Anwendung verwalteter Identitäten. Einige Vertrauensinstanzen wollen u. U. lediglich wissen, dass ein Nutzer eindeutig ist, was nur eine Nutzer-Email-Adresse od. dergl. erfordert. Für derartige Vertrauensinstanzen kann ein Nutzer sich mittels selbstbehaupteter Identitäten identifizieren, die die geforderten Identifikations-Zeichen aufweisen – bspw. eine Email-Adresse. Nach einem Aspekt der vorliegenden Erfindung weist eine selbstbehauptete Identität Informationen auf, die zeigen, dass andere Beteiligte die Identität akzeptiert (und daher validiert) haben. Betrachtet eine gegebene beteiligte Instanz diese anderen Beteiligten als vertrauenswürdig, kann sie sich entscheiden, die selbstbehauptete Identität nur auf Grund der Akzeptanz durch die anderen Beteiligten zu akzeptieren. Eine Gruppe von Vertrauensinstanzen kann also in sich ein "transitives Vertrauen" herstellen derart, dass ein selbstbehauptetes Attribut eines Nutzers, das eine der beteiligten Instanzen akzeptiert, auch von allen anderen Beteiligten der Gruppe akzeptiert wird. Ist also das Vertrauen einmal hergestellt, vermeiden die anderen Beteiligten die Kosten einer Validierung der selbstbehaupteten Identität.
Die 2 zeigt als Flussdiagramm eine beispielhafte Ausführungsform eines Verfahrens 200 zum Verwalten einer selbstbehaupteten digitalen Identität für einen Nutzer nach einem oder mehr Aspekten der Erfindung. Das Verfahren 200 weist ein vom Computer 104 ausgeführtes Verfahren 201, ein von einer Vertrauensinstanz 128 ausgeführtes Verfahren 202 sowie ein von einer Vertrauensinstanz 130 ausgeführtes Verfahren 203 auf. In der vorliegenden Ausführungsform stellt der Nutzer der Vertrauensinstanz 128 anfänglich eine selbstbehauptete Identität bereit, die ein oder mehr Attribuite derselben Validiert. Die Vertrauensinstanzen 128 und 130 haben zwischen sich ein transitives Vertrauen hergestellt. Gibt der Nutzer die selbstbehauptete Identität an die Vertrauensinstanz 130, betrachtet diese sie als gültig, und zwar auf Grund des Umstands, dass die Vertrauensinstanz 128 die Identität als gültig akzeptiert hat.
Insbesondere beginnt das Verfahren 201 mit dem Schritt 204, wo ein Nutzer des Computers 104 der Vertrauensinstanz 128 eine selbstbehauptete digitale Identität präsentiert, und zwar typischerweise ansprechend auf Anforderung durch die Vertrauensinstanz 128. Dabei fordert die Vertrauensinstanz 128 eine digitale Identität des Nutzers typischerweise in einem bestimmten Format und mit einem oder mehr bestimmten Attributen an. Bspw. kann der Nutzer bei der Vertrauensinstanz 128 ein Konto anlegen oder versuchen, auf ein angelegtes Konto zuzugreifen.
Das Verfahren 202 beginnt dann mit dem Schritt 206, wo die Vertrauensinstanz 128 die selbstbehauptete digitale Identität empfängt. Im Schritt 208 validiert die Vertrauensinstanz 128 mindestens ein Attribut der selbstbehaupteten Identität. Die Vertrauensinstanz 128 kann eine solche Validierung unter Benutzung eines beliebigen von verschiedenen aus dem Stand der Technik bekannter Mechanismen ausführen. Im Schritt 210 gibt die Vertrauensinstanz 128 ein Akzeptanz-Token an den Nutzer. Das Akzeptanz-Token weist Informationen auf, die gem. der Vertrauensinstanz 128 auf die Authentizität des bzw. der selbstbehaupteten Attribute hinweisen (d. h. das Akzeptanz-Token zeigt, dass die Vertrauensinstanz 128 das bzw. die Attribute validiert hat oder ihm/ihnen sonstwie als authentisch vertraut). In einer Ausführungsform beweist die Vertrauensinstanz 128 dieses Vertrauen unter Anwendung eines Systems mit asymmetrischer Verschlüsselung (PKI, "public key infrastructure"). Die Vertrauensinstanz 128 signiert die selbstbehaupteten Attribute oder eine digi tale Darstellung derselben (bspw. einen Hash-Wert der Attribute). Die digitale Signatur kann eine Verschlüsselung des/der Attribute (oder deren Darstellung) unter Verwendung eines asymmetrischen Verschlüsselungsalgorithmus und eines privaten Schussels aufweisen. Ein anderer Beteiligter kann verifizieren, dass die Vertrauensinstanz 128 die Attribute unter Verwendung eines öffentlichen Schlüssels letzterer digital signiert hat. Andere Beteiligte können eine derartige digitale Signatur als Beweis behandeln, dass die Vertrauensinstanz 128 den Attributen als authentisch vertraut.
In einer Ausführungsform weist das Akzeptanz-Token andere Arten von Attributen auf, die dem Zusammenhang zwischen dem Nutzer und der Vertrauensinstanz zugeordnet sind – bspw. Informationen zu dem Zeitraum, während dessen die Authentizität der selbstbehaupteten Attribute aufrecht erhalten wurde. Hat bspw. die Vertrauensinstanz 128 die Authentizität der Email-Adresse eines Nutzers verifiziert, kann sie angeben, wie lange die Email-Adresse Teil der Beziehung zum Nutzer war (bspw. dass die Email-Adresse X Monate/Jahre benutzt worden ist).
Wie wiederum das Verfahren 201 zeigt, wird im Schritt 212 das Akzeptanz-Token empfangen und im Schritt 214 als Attribut in die selbstbehauptete Identität aufgenommen. Stellt also der Nutzer die selbstbehauptete Identität einem Beteiligten bereit, kann das Akzeptanz-Token wahlweise – je nach Präferenz des Nutzers – präsentiert werden. Im Schritt 218 präsentiert der Nutzer die selbstbehauptete Identität und das Akzeptanz-Token der Vertrauensinstanz 130. Der Nutzer präsentiert die selbstbehauptete Identität typischerweise auf Anforderung der Vertrauensinstanz 130. Die Vertrauensinstanz 130 fordert eine digitale Identität des Nutzers typischerweise in einem bestimmten Format und mit einem oder mehr bestimmten Attributen an. Bspw. kann der Nutzer bei der Vertrauensinstanz 130 ein Konto anlegen oder versuchen, auf ein angelegtes Konto zuzugreifen.
Das Verfahren 203 beginnt dann mit dem Schritt 218, mit dem die Vertrauensinstanz 130 die selbstbehauptete Identität und das Akzeptanz-Token empfängt. Im Schritt 220 validiert die Vertrauensinstanz 130 die selbstbehaupteten Attribute auf Grund des Akzeptanz-Tokens. M. a. W.: Die Vertrauensinstanz 130 benutzt das Akzeptanz-Token als Beweis, dass die Vertrauensinstanz 128 die selbstbehaupteten Attribute als gültig akzeptiert hat. Betrachtet die Vertrauensinstanz 130 die Vertrauensinstanz 128 als vertrauenswürdig, kann erstere die selbstbehaupteten Attribute auf Grund nur des Akzeptanz-Tokens validieren. M. a. W.: betrachtet die Vertrauensinstanz 130 die Vertrauensinstanz 128 als vertrauenswürdig, sind die selbstbehaupteten Attribute zuverlässiger als andere, die nicht durch ein Akzeptanz-Token gestützt sind. Die Vertrauensinstanz 130 braucht daher nicht die Kosten zu übernehmen, die bei der Validierung selbstbehaupteter Attribute auftreten, da diese Attribute bereits von einem anderen und vertrauenswürdigen Beteiligten validiert worden sind.
Wie oben beschrieben, nimmt in einer Ausführungsform die Vertrauensinstanz 128 eine digitale Signatur in das Akzeptanz-Token auf. Beim Validieren im Schritt 220 kann die Vertrauensinstanz 130 sich den öffentlichen Schlüssel der Vertrauensinstanz 128 beschaffen, um die digitale Signatur im Akzeptanz-Token zu authentisieren. Die Vertrauensinstanz 130 kann also sicher sein, dass die Vertrauensinstanz 128 die selbstbehaupteten Attribute akzeptiert hat. In einer Ausführungsform kann die Vertrauensinstanz 130 den öffentlichen Schlüssel direkt von der Vertrauensinstanz 128 erhalten oder ihn einer Liste öffentlicher Schlüssel entnehmen. Alternativ kann die Vertrauensinstanz 130 sich den öffentlichen Schlüssel für die Vertrauensinstanz 128 vom Nutzer beschaffen. Im optionalen Schritt 217 stellt also der Nutzer der Vertrauensinstanz 130 einen öffentlichen Schlüssel für die Vertrauensinstanz 128 bereit. Auch kann der von der Vertrauensinstanz erhaltene öffentliche Schlüssel 130 Teil eines digitalen Zertifikats sein, den eine Zertifizierungsinstanz signiert hat. Die Vertrauensinstanz 130 weiß dann, dass der öffentliche Schlüssel echt ist.
Der Fachmann sieht ein, dass, obgleich oben eine einzige selbstbehauptete Identität beschrieben ist, das Verfahren 200 sich auch für mehrere selbstbehauptete Identitäten mit jeweils einem oder mehr selbstbehaupteten Attributen einsetzen lässt. Obgleich weiterhin nur zwei Vertrauensinstanzen erwähnt sind, kann die Gruppe der Beteiligten, die transitives Vertrauen erteilen, mehr als zwei Beteiligte aufweisen.
In einer Ausführungsform ist der Identitätsmanager 116 zum Verwalten von verwalteten Identitäten 152 konfiguriert. Jede verwaltete Identität weist ein oder mehr Attribute auf, die von einem Identitätsanbieter gedeckt sind. Bspw. kann eine verwaltete Identität die Email-Adresse eines Nutzers enthalten, die von einem Identitätsanbeiter validiert worden ist. Nach einem Aspekt der Erfindung gibt ein Identitätsanbieter eine verwaltete Identität aus, der eine vom Nutzer bereit gestellte selbstbehauptete Identität zu Grunde liegt, wobei die selbstbehaupete Identität Informationen enthält, die ausweisen, dass andere Beteiligte die Identität akzeptiert (und daher validiert) haben. Betrachtet der Identitätsanbieter diese anderen Beteiligten als vertrauenswürdig, kann er auf Grund ausschließlich der Akzeptanz durch die anderen Beteiligten die verwaltete Identität ausgeben.
Die 3 zeigt als Flussdiagramm eine andere beispielhafte Ausführungsform eines Verfahrens 300 zum Verwalten einer selbstbehaupteten digitalen Identität für einen Nutzer nach einem oder mehr Aspekten der Erfindung. Das Verfahren 300 weist ein vom Computer 104 ausgeführtes Verfahren 301, ein von der Vertrauensinstanz 128 ausgeführtes Verfahren 302 sowie ein von einem Identitätsanbieter 132 ausgeführtes Verfahren 303 auf. In der vorliegenden Ausführungsform teilt der Nutzer anfänglich der Vertrauensinstanz 128 eine selbstbehauptete Identität mit; letztere validiert eines oder mehr der Attribute in ihr. Die Vertrauensinstanz 128 und der Identitätsanbieter 132 haben zwischen sich ein transitives Vertrauen hergestellt. Der Identitätsanbieter 132 stellt zwei Arten verwalteter Identität aus: Die eine Art weist ein oder mehr Attri bute auf, die vom Identitätsanbieter 132 selbst validiert worden sind. Die andere Art einer verwalteten Identität weist ein oder mehr Attribute auf, die von einem oder mehr Beteiligten validiert worden sind, denen der Identitätsanbieter 132 vertraut (bspw. der Vertrauensinstanz 128). Die zweite Art der verwalteten Identität gibt eher an, dass andere Beteiligte, denen der Identitätsanbieter 132 vertraut, die Attribute validiert haben. Die Identität dieser anderen Beteiligten ist nicht in der verwalteten Identität enthalten. Der Nutzer kann diese verwaltete Identität anderen Vertrauensinstanzen bereit stellen, die ein Vertrauensverhältnis zum Identitätsanbieter 132 aufgebaut haben.
Insbesondere beginnt das Verfahren 301 mit dem Schritt 304, wo ein Nutzer des Computers 104 der Vertrauensinstanz 128 – typischerweise auf Anforderung – eine selbstbehauptete digitale Identität präsentiert. Die Vertrauensinstanz 128 fordert typischerweise eine digitale Identität des Nutzers in einem bestimmten Format und mit einem oder mehr bestimmten Attributen an. Bspw. kann der Nutzer bei der Vertrauensinstanz 128 ein Konto anlegen oder versuchen, auf ein bereits angelegtes Konto zuzugreifen.
Das Verfahren 302 beginnt mit dem Schritt 306, wo die Vertrauensinstanz 128 die selbstbehaupete digitale Identität empfängt. Im Schritt 308 validiert die Vertrauensinstanz 128 mindestens ein Attribut der selbstbehaupteten Identität. Die Vertrauensinstanz 128 kann dabei eine solche Validierung unter Benutzung verschiedener Mechanismen ausführen, die aus dem Stand der Technik bekannt sind. Im Schritt 310 stellt die Vertrauensinstanz 128 dem Nutzer ein Akzeptanz-Token bereit. Das Akzeptanz-Token enthält Informationen, die die Authenzität der selbstbehaupteten Attribute gem. der Vertrauensinstanz 128 behaupten (d. h. das Akzeptanz-Token zeigt, dass die Vertrauensinstanz 128 die Attribute validiert hat oder ihnen sonstwie als authentisch vertraut). In einer Ausführungsform beweist die Vertrauensinstanz 128 dieses Vertrauen unter Benutzung eines PKI-Systems, wie beschrieben. M. a. W.: das Akzeptanz-Token kann eine digitale Signatur der Vertrauensinstanz 128 enthalten. In einer Ausführungsform enthält das Akzeptanz-Token andere Arten von Attributen zu der Beziehung zwischen dem Nutzer und der Vertrauensinstanz 128 – bspw. Informationen zu dem Zeitraum, während dessen die Authentizität der selbstbehaupteten Attribute aufrecht erhalten worden ist.
Im Verfahren 301 wiederum wird im Schritt 312 das Akzeptanz-Token empfangen. und im Schritt 314 als Attribut in die selbstbehauptete Identität aufgenommen. In einer Ausführungsform ist das Akzeptanz-Token ein optionales Attribut. M. a. W.: Präsentiert der Nutzer die selbstbehauptete Identität einem Beteiligten, kann das Akzeptanz-Token wahlweise – je nach Präferenz des Nutzers – enthalten sein. Im Schritt 316 präsentiert der Nutzer dem Identitätsanbieter 132 die selbstbehauptete Identität und das Akzeptanz-Token. Der Nutzer kann dem Identitätsanbieter 132 die selbstbehauptete Identität anbieten, um eine verwaltete Identität zu erhalten.
Das Verfahren 303 beginnt im Schritt 318, wo der Identitätsanbieter 132 die selbstbehauptete Identität und das Akzeptanz-Token übernimmt. Im Schritt 320 validiert der Identitätsanbieter 132 die selbstbehaupteten Attribute auf Grund des Akzeptanz-Tokens. M. a. W.: Dem Identitätsanbieter 132 dient das Akzeptanz-Token als Beweis, dass die Vertrauensinstanz 128 die selbstbehaupteten Attribute als gültig akzeptiert hat. Betrachtet der Identitätsanbieter 132 die Vertrauensinstanz 128 als vertrauenswürdig, kann er die selbstbehaupteten Attribute ausschließlich auf Grund des Akzeptanz-Tokens validieren.
Wie oben beschrieben, nimmt in einer Ausführungsform die Vertrauensinstanz 128 in das Akzeptanz-Token eine digitale Signatur auf. Bei der Validierung im Schritt 320 kann der Identitätsanbieter 132 sich den öffentlichen Schlüssel direkt von der Vertrauensinstanz 128 beschaffen oder ihn einer Liste öffentlicher Schlüssel entnehmen. Alternativ kann der Identitätsanbieter 132 den öffentlichen Schlüssel für die Vertrauensinstanz 128 vom Nutzer übernehmen. M. a. W.: Im optionalen Schritt 317 stellt der Benutzer dem Identitätsanbieter 132 einen öffentlichen Schlüssel für die Vertrauensinstanz 128 bereit. Jedenfalls kann der durch den Identitätsanbieter 132 übernommene öffentliche Schlüssel Teil eines digitalen Zertifikats sein, das von einer Zertifizierungsinstanz signiert ist. Der Identitätsanbieter 132 weiß dann, dass der öffentliche Schlüssel echt ist.
Im Schritt 322 erzeugt der Identitätsanbieter 132 eine verwaltete Identität mit dem bzw. den selbstbehaupteten Attributen. Die verwaltete Identität enthält Informationen, die anzeigen, dass der Identitätsanbieter 132 die in ihr enthaltenen Attribute auf Grund eines transitiven Vertrauens zu einem oder mehr Vertrauensinstanzen validiert hat. Der Identitätsanbieter 132 signiert dann die verwaltete Identität digital, so dass andere Beteiligte verifizieren können, dass die verwaltete Identität vom Identitätsanbieter 132 stammt. Im Schritt 324 schickt der Identitätsanbieter die verwaltete Identität an den Nutzer. Im Schritt 326 des Verfahrens 301 empfängt der Nutzer die verwaltete Identität vom Identitätsanbieter 132, um sie im Schritt 328 einer oder mehr Vertrauensinstanzen bereit zu stellen.
Der Fachmann sieht ein, dass zwar oben eine einzige selbstbehauptete und die entsprechende verwaltete Identität beschrieben sind, das Verfahren 300 sich aber auch auf mehrere selbstbehauptete Identitäten mit jeweils einem oder mehr selbstbehaupteten Attributen und jeweils einer zugehörigen verwalteten Identität anwenden lässt.
Ein Aspekt der vorliegenden Erfindung ist als Programmprodukt für die Anwendung mit einem Computersystem implementiert. Ein oder mehr Programme des Programmprodukts definieren Funktionen von Ausführungsformen und können auf verschiedenen Aufzeichnungsträgern abgelegt sein – bspw. (i) permanent auf nicht beschreibbaren Aufzeichnungsträgern (bspw. Nur-Lese-Speichern in einem Computer wie eine mit einem zugehörigen Laufwerk lesbaren CD- oder DVD-ROM) gespeicherte Informationen; (ii) auf einem beschreibbaren Aufzeichnungsträger (bspw. einer Floppy-Disk in einem Diskettenlaufwerk, einer Festplatte oder einer beschreib- und lesbaren CD oder DVD) gespeicherte Informationen; (iii) Informationen, die mit einem Übertragungsme dium an einen Computer übermittelt werden, bspw. ein Computer- oder Telefonnetz einschl. Funkstrecken, ohne auf diese beschränkt zu sein. Letztere Ausführungsformen schließt explizit Informationen ein, die aus dem Internet oder anderen Netzen herabgeladen werden. Enthalten sie computerlesbare Befehle, die die Ausführung von Funktionen der Erfindung bestimmen, stellen derartige signalspeichernde Medien Ausführungsformen der Erfindung dar.
Während die vorgehende Beschreibung auf Ausführungsformen der vorliegenden Erfindung gerichtet ist, lassen diese sowie weitere Ausführungsformen der Erfindung sich erstellen, ohne deren Grundgedanken zu verlassen. Der Umfang der Erfindung ist ausschließlich von den folgenden Ansprüchen bestimmt.
ZEICHNUNGSBESCHRIFTUNGEN

1

102: Netzwerk
104: Computer
106: E/A-Schnittstelle
108: Prozessor
110: Hilfsschaltungen
111: Eingabe-Einrichtungen
113: Ausgabe-Einrichtungen
114: Speicher
116: Identitätsmanager
128: Vertrauensinstanz
130: Vertrauensinstanz
132: Identitätsanbieter
150: selbstbehauptete Identitäten
152: verwaltete Identitäten

2

201: Nutzer
202: Vertrauensinstanz
203: Vertrauensinstanz
204: selbstbehaputete Identität an schicken Vertrauensinstanz
206: selbstbehauptete Identität empfangen
208: Attribute (in selbstbehaupteter Identitäts) validieren
210: Akzeptanz-Token an Nutzer schicken
212: Akzeptanz-Token von Vertrauensinstanz annehmen
214: Akzeptanz-Tolken als Attribut in selbstbehauptete Identität aufnehmen
216: selbstbehauptete Identitäts und Akzeptanz-Token an andere Vertrauensinstanz schicken
218: selbstbehauptete Identitäts und Akzeptanz-Token vom Nutzer empfangen
220: Attribut(e) in selbstbehaupteter Identität auf Grund des Akzeptanz-Tokens und transitiven Vertrauens zwischen Vertrauensinstanzen validieren

3

301: Nutzer
302: Vertrauensinstanz
303: Identitätsanbieter
304: selbstbehauptete Identität an Vertrauensinstanz senden
306: selbstbehauptete Identität empfangen
308: Attribut(e) in selbstbehaupteter Identität validieren
310: Akzeptanz-Token an Nutze schicken
312: Akzeptanz-Token vom Vertrauensinstanz empfangen
314: Akzeptanz-Token als Attribut in selbstbehauptete Identität aufnehmen
316: selbstbehauptete Identität und Akzeptanz-Token an Identitätsanbieter schicken
318: selbstbehauptete Identitäts und Akzeptanz-Token vom Nutzer empfangen
320: Attribut(e) in selbstbehaupteter Identität auf Grund des Akzeptanz-Tokens und transitiven Vertrauens zwischen Vertrauensinstanzen validieren
322: verwaltete Identität mit selbsthaupteten Attributen generieren
324: verwaltete Identität an Nutzer schicken
326: verwaltete Identität vom Identitätsanbieter ampfangen
328: verwaltete Identität anderen Vertrauensinstanzen bereit stellen

Claims

Verfahren zum Verwalten einer digitalen Identität eines Nutzers, indem man: einem ersten Beteiligten die digitale Identität bereit stellt, die ein selbstbehauptetes Attribut enthält; vom ersten Beteiligten ein Akzeptanz-Token beschafft, das die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten behauptet; und die digitale Identität und das Akzeptanz-Token an einen zweiten Beteiligten weitergibt und auf Grund des Akzeptanz-Tokens die Validierung des selbstbehaupteten Attributs durch den zweiten Beteiligten anfordert.
Verfahren nach Anspruch 1, bei dem das Akzeptanz-Token eine Wiedergabe des selbstbehaupteten Attributs aufweist, die vom ersten Beteiligten unter Verwendung eines privaten Schlüssels desselben digital signiert ist.
Verfahren nach Anspruch 2, bei dem man weiterhin dem zweiten Beteiligten einen öffentlichen Schlüssel des ersten Beteiligten zur Verwendung beim Verifizieren des vom ersten Beteiligten digital signierten Akzeptanz-Tokens bereit stellt.
Verfahren nach Anspruch 3, bei dem der öffentliche Schlüssel als Teil eines digitalen Zertifikats bereit gestellt wird, das von einer Zertifizierungsinstanz digital signiert ist.
Verfahren nach Anspruch 1, bei dem man weiterhin die digitale Identität verstärkt, indem man das Akzeptanz-Token als optionales Attribut in sie aufnimmt.
Verfahren nach Anspruch 1, bei dem das Akzeptanz-Token Informationen hinsichtlich eines Zeitraums enthält, über den der erste Beteiligte die Authentizität des selbstbehaupteten Attributs aufrecht erhalten hat.
Verfahren nach Anspruch 1, bei dem der zweite Beteiligte ein Identitätsanbieter ist und man weiterhin: vom Identitätsanbieter eine verwaltete digitale Identität übernimmt, die ein Attribut entsprechend dem selbstbehaupteten Attribut enthält, wobei die verwaltete Identität die Authentizität des Attributs gemäß dem Identitätsanbieter behauptet.
Anordnung zum Verwalten einer digitalen Identität eines Nutzers mit: einer Einrichtung, mit der die digitale Identität einem ersten Beteiligten bereit stellbar ist, wobei die digitale Identität ein selbstbehauptetes Attribut beinhaltet; einer Einrichtung, mit der vom ersten Beteiligten ein Akzeptanz-Token beschaffbar ist, das die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten behauptet; und einer Einrichtung, mit der die digitale Identität und das Akzeptanz-Token einem zweiten Beteiligten bereit stellbar sind, um die Validierung des selbstbehaupteten Attributs durch den zweiten Beteiligten auf Grund des Akzeptanz-Tokens anzufordern.
Anordnung nach Anspruch 8, bei dem das Akzeptanz-Token eine Wiedergabe des selbstbehaupteten Attributs mit digitaler Signatur des ersten Beteiligten unter Verwendung eines privaten Schlüssels desselben aufweist.
Anordnung nach Anspruch 9 mit: einer Einrichtung, mit der dem zweiten Beteiligten ein öffentlicher Schlüssel des ersten Beteiligten mit digitaler Signatur desselben zur Verwendung beim Verifizieren des Akzeptanz-Tokens bereitstellbar ist.
Anordnung nach Anspruch 10, bei der der öffentliche Schlüssel als Teil eines digitalen Zertifikats bereit gestellt wird, das von einer Zertifizierungsinstanz digital signiert ist.
Anordnung nach Anspruch 8, bei der die digitale Identitäts durch Aufnahme des Akzeptanz-Tokens als optionales Attribut verstärkbar ist.
Anordnung nach Anspruch 8, bei der das Akzeptanz-Token Informationen hinsichtlich eines Zeitraums beinhaltet, über den der erste Beteiligte die Authentizität des selbstbehaupteten Attributs aufrecht erhalten hat.
Anordnung nach Anspruch 8, bei der der zweite Beteiligte ein Identitätsanbieter und weiterhin eine Einrichtung vorgesehen ist, mit der von dem Identitätsanbieter eine verwaltete digitale Identität einschl. eines dem selbstbehaupteten entsprechenden Attributs übernehmbar ist, wobei die verwaltete Identität die Authentizität des Attributs gemäß dem Identitätsanbieter behauptet.5
Verfahren zum Verwalten einer digitalen Identitäts eines Nutzers, bei dem man: einem ersten Beteiligten die digitale Identität aus bzw. mit einem Computer bereit stellt, wobei die digitale Identität ein selbstbehauptete Attribut beinhaltet; das selbstbehauptete Attribut beim ersten Beteiligten validiert; vom ersten Beteiligten ein Akzeptanz-Token an den Rechner schicken lässt, das die Authentizität des selbstbehaupteten Attributs gemäß dem ersten Beteiligten behauptet; die digitale Identität und das Akzeptanz-Token vom Computer an einen zweiten Beteiligten schickt; und beim zweiten Beteiligten das selbstbehauptete Attribut auf Grund des Akzeptanz-Tokens und eines zwischen dem ersten und dem zweiten Beteiligten hergestellten transitiven Vertrauens validiert.
Verfahren nach Anspruch 15, bei dem das Akzeptanz-Token eine Wiedergabe des selbstbehaupteten Attributs beinhaltet, das vom ersten Beteiligten unter Verwendung eines privaten Schlüssels desselben digital signiert ist.
Verfahren nach Anspruch 15, bei dem man die digitale Identität durch Aufnahme des Akzeptanz-Tokens als optionales Attribut verstärkt.
Verfahren nach Anspruch 15, bei dem das Akzeptanz-Tokens Informationen hinsichtlich eines Zeitraums beinhaltet, über den der erste Beteiligte die Authentizität des selbstbehaupteten Attributs aufrecht erhalten hat.
Verfahren nach Anspruch 1, bei dem der zweite Beteiligte ein Identitätsanbieter ist und vom Identitätsanbieter eine verwaltete digitale Identität an den Computer geschickt wird, die ein Attribut entsprechend dem selbstbehaupteten Attribut enthält, wobei die verwaltete Identität die Authentizität des Attributs gemäß dem Identitätsanbieter behauptet.