DE212021000334U1

DE212021000334U1 - Blockchain-Nachweis zur Identifizierung

Info

Publication number: DE212021000334U1
Application number: DE212021000334.6U
Authority: DE
Original assignee: DRFIRST COM Inc
Current assignee: DRFIRST COM Inc
Priority date: 2020-03-11
Filing date: 2021-03-11
Publication date: 2022-12-13
Anticipated expiration: 2031-03-12
Also published as: GB202214900D0; US11128469B1; US11621851B2; US20230246843A1; US10979230B1; US20220006638A1; GB2608564A; WO2021184046A1; CA3171228A1; CN113392411A; US20210288812A1; AU2021234387A1; CA3171228C

Abstract

System, umfassend:
zumindest einen Prozessor;
einen Identitätsgraphen, der Identitätsblöcke speichert, wobei die Identitätsblöcke Genesis-Blöcke bzw. Entstehungsblöcke enthalten; und
einen Speicher, der Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen,
Operationen durchzuführen, die beinhalten:
Empfangen von Genesis-Daten bzw. Entstehungsdaten und eines Signaturschlüssels nach einem erfolgreichen Identitätsnachweisprozess für eine Person, wobei die Genesis-Daten eine physische Eigenschaft der Person erfassen und der Signaturschlüssel durch die Person bereitgestellt wird,
Generieren eines ersten Hash-Ergebnisses unter Verwendung der Genesis-Daten als Eingabe,
Generieren eines Genesis-Blocks bzw. Entstehungsblocks in dem Identitätsgraphen, wobei der Genesis-Block die Genesis-Daten als Inhalt aufweist, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird,
Generieren eines zweiten Hash-Ergebnisses unter Verwendung von Nutzlastdaten und dem ersten Hash-Ergebnis als Eingabe,
Generieren eines Identitätsblocks in dem Identitätsgraphen, wobei der Identitätsblock einen Inhalt aufweist, der die Nutzlastdaten und das erste Hash-Ergebnis enthält, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird,
Generieren eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Sucheigenschaft für die Person, aber nicht den Signaturschlüssel enthält, und
Verwenden des Identitätsgraphen beim Antworten auf Verifizierungs- bzw. Prüfanfragen.

Description

VERWANDTE ANMELDUNGEN
Die Anmeldung beansprucht die Priorität der US-Anmeldung Nr. 17/247,110 , eingereicht am 30. November 2020, die eine nicht-vorläufige (non-provisional) Anmeldung der vorläufigen US-Anmeldung Nr. 62/988,271 , eingereicht am 11. März 2020, ist und deren Priorität beansprucht. Diese Anmeldung beansprucht auch die Priorität der US-Anmeldung Nr. 17/249,592 , eingereicht am 5. März 2021, die eine nicht vorläufige (non-provisional) Anmeldung der vorläufigen US-Anmeldung Nr. 62/988,271 ist und deren Priorität beansprucht. Die Offenbarungen dieser früher eingereichten Anmeldungen sind hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen.
TECHNISCHES GEBIET
Die vorliegende Lehre bezieht sich auf Verfahren, Systeme und Programmierung zur Identitätsverifizierung bzw. -prüfung unter Verwendung von Knoten in einem Graphen. Insbesondere betrifft die vorliegende Lehre eine verkettbare Knotenstruktur, die es jeder vertrauenswürdigen Entität ermöglicht, als sicherer Identitätsnachweisanbieter ohne Ausgabe von Hardware- oder Software-Token zu dienen.
HINTERGRUND
Blockchain ist eine Technologie, die sicherstellt, dass einmal generierte Daten nicht einfach ohne Detektion modifiziert werden können. Genauer gesagt ist eine Blockchain eine Reihe von Datenblöcken oder Knoten, die kryptografisch verknüpft sind, wobei jeder Block einen kryptografischen Hash des vorherigen Blocks, d. h. Vorgängerblocks, enthält. Diese kryptografisch verknüpften Blöcke werden als Kette (Chain) bezeichnet. Ausgehend von einem Block in der Kette generiert ein Computersystem zum Identifizieren eines Vorgängerblocks einen Hash der Blöcke (Blockinhalt) in der Blockchain, bis ein Block mit gehashtem Inhalt identifiziert wird, der mit dem in dem Startblock gespeicherten Hash übereinstimmt. Die Suche endet, wenn ein Genesis-Block bzw. Entstehungsblock gefunden wird. Ein Genesis-Block enthält kein Hash-Ergebnis in seinem Inhalt. Wenn kein mit dem Hash übereinstimmender Block gefunden wird, dann wird die Kette unterbrochen, was darauf hinweist, dass Daten modifiziert wurden. Somit ist die Blockchain resistent gegen Datenmodifikation. Aufgrund dieser Eigenschaft kann Blockchain für Sicherheitszwecke wie digitale Währungen und Audit-Aufzeichnungen verwendet werden.
Alle Blöcke in einer Blockchain sind in einem umfassenden Graphen oder einer verbesserten Merkle-Baumstruktur strukturiert/organisiert. Wenn Blöcke hinzugefügt werden, wächst der Ledger der Kette (z. B. in einem Graphen/Merkle-Baum). Einige Ledger werden in einer öffentlichen Cloud gespeichert. Andere Ledger werden lokal gespeichert und sind für die Öffentlichkeit nicht zugänglich. Herkömmlicherweise werden Blockchains im Laufe der Zeit entweder tief, mit vielen Knoten in der Kette, oder breit, wobei der Genesis- oder Wurzelblock einen sehr hohen Verzweigungsgrad aufweist.
ZUSAMMENFASSUNG
Implementierungen stellen ein sicheres, flexibles und verteiltes System zum Verifizieren bzw. Prüfen der Identität einer Entität bereit, ohne sich darauf zu verlassen, dass Dritte Hardware- oder Software-Token ausgeben. Implementierungen generieren nach einem erfolgreichen Identitätsnachweisprozess durch eine autorisierte Organisation eine Kette für die Entität. Die Kette ist kurz und enthält nur eine Handvoll Blöcke für jede Entität. Die Entität kann eine Person oder ein Objekt sein und ist Gegenstand des Identitätsnachweisprozesses. Jede Kette hat einen Entstehungs- bzw. Genesis-Block auf, der als Teil seines Inhalts Daten enthält, die ein physisches Attribut der Entität beschreiben, beispielsweise ein zwei- oder dreidimensionales Bild der Entität, einen biometrischen Marker, ein Bild von Immobilien bzw. Grundstücken etc. Zumindest ein Block in der Kette enthält Inhalt, der sich auf die Dokumente bezieht, die beim erfolgreichen Identitätsnachweis verwendet werden. Andere Blöcke können andere Informationen und/oder Aktionen enthalten, die bei der autorisierten Organisation für die Entität durchgeführt werden.
Die Entität selbst oder der Eigentümer der Entität (falls die Entität ein Objekt ist) stellt nach erfolgreichem Identitätsnachweis einen Signaturschlüssel bereit. Der Signaturschlüssel wird beim Generieren der Kette verwendet, z. B. indem er in die Eingabe aufgenommen wird, die einer Hash-Funktion bereitgestellt wird, die die kryptografischen Hashes generiert, die die Kette verknüpfen, und/oder indem der Schlüssel bereitgestellt wird, der den Blockinhalt verschlüsselt, bevor ein Block gespeichert wird. In jedem Fall ist der Signaturschlüssel erforderlich, um eine Kette zu verifizieren. Der Signaturschlüssel kann von dem Verwalter bzw. Verwahrer bzw. Wächter bzw. Keeper der Entität (z. B. der Person oder einem Eigentümer des Objekts) bereitgestellt werden. Der Signaturschlüssel kann alles sein, was vom Verwalter der Entität ausgewählt wird. Nicht einschränkende Beispiele umfassen eine Textzeichenfolge, wie einen Lieblingsausdruck oder eine Lieblingszeile, den Namen eines ersten Haustiers, einen Lieblingsliedtext, ein Lieblingszitat, eine Kombination aus Namen, Geburtsdaten, Adressen etc. oder ein Bild. Der Signaturschlüssel kann von der Entität bereitgestellt werden, z. B. Daten, die an einer bestimmten Speicheradresse gespeichert sind, ein Bild eines bestimmten Abschnitts des Objekts, ein Ort für das Objekt (z. B. ein aktueller Ort oder ein Ursprungsort) etc. Die autorisierte Organisation kann einen Dienst anbieten, um eine Entität zu verifizieren. Um eine Entität zu verifizieren, benötigt die autorisierte Organisation eine Eigenschaft (z. B. Name), die verwendet wird, um den letzten Block für die Kette der Entität zu finden, und einen Abfrageschlüssel. Der Abfrageschlüssel entspricht dem Signaturschlüssel. Anders ausgedrückt hat der Abfrageschlüssel die gleiche Funktion wie der Signaturschlüssel, wird aber eher als Teil einer Verifizierung einer Kette als einer Generierung einer Kette bereitgestellt. Wenn eine Kette unter Verwendung des Abfrageschlüssels und der Eigenschaft geortet wird, ist die Überprüfung erfolgreich. Bei einigen Implementierungen kann die Abfrageantwort Daten aus dem Genesis-Block oder einem anderen Block in der Kette zusätzlich zu einem Hinweis auf die erfolgreiche Verifizierung enthalten.
Ohne offenbarte Implementierungen erfordert eine sichere Identitätsverifizierung herkömmlicherweise ein Drittunternehmen. Herkömmlicherweise gibt beispielsweise, nachdem ein Krankenhaus die Identität eines Arztes gemäß den entsprechenden Vorschriften und Gesetzen verifiziert hat, das Krankenhaus einen Hardware-Token an den Arzt aus, so dass der Arzt den Token verwenden kann, um auf sichere Krankenhaus-Computersysteme zuzugreifen. Solche Token werden von Drittunternehmen verwaltet. Anstatt ein Drittunternehmen einbeziehen zu müssen und den Verlust eines Tokens zu riskieren, kann das Krankenhaus offengelegte Implementierungen anstelle des Hardware-Tokens verwenden. Bevor der Arzt Zugriff auf Computersysteme erhält, kann er beispielsweise aufgefordert werden, einen Abfrageschlüssel und ein Suchfeld, wie z. B. einen Namen, als Abfrageparameter bereitzustellen. Offenbarte Implementierungen können die bereitgestellten Abfrageparameter verwenden, um zu bestimmen, ob eine Kette in dem Graph existiert oder nicht; wenn keine Kette identifiziert werden kann, ist die Verifizierung nicht erfolgreich. Bei einigen Implementierungen kann weitere Sicherheit hinzugefügt werden, indem die Daten des Genesis-Blocks (z. B. die Beschreibung eines physikalischen Merkmals) oder Daten eines anderen Blocks mit Daten verglichen werden, die vom Arzt beim Login erhalten werden. So kann beispielsweise der Arzt zu einem Fingerabdruck oder Gesichtsscan aufgefordert werden und dieser kann mit den Daten verglichen werden, die aus einer erfolgreich identifizierten Kette erhalten werden. Wenn die Daten nicht übereinstimmen, kann die Verifizierungsanfrage fehlschlagen, selbst wenn eine Kette erfolgreich identifiziert wurde. Bei einigen Implementierungen kann diese zusätzliche Überprüfung durch den anfordernden Prozess durchgeführt werden. Mit anderen Worten kann eine erfolgreiche Verifizierung die Genesis-Blockdaten zurück an den anfordernden Prozess liefern und der anfordernde Prozess kann die Daten verwenden, um die zweite Verifizierung durchzuführen.
Als ein weiteres Beispiel können eine ferngesteuerte Vorrichtung oder ferngesteuerte Vorrichtungen, wie etwa eine Drohne oder ein Drohnennetzwerk, mit Anweisungen konfiguriert werden. Um zu vermeiden, auf Anweisungen zu reagieren, die von einem nicht autorisierten Benutzer gesendet wurden, kann die Drohne so konfiguriert sein, dass sie die Identität einer Entität verifiziert, die die Anweisungen bereitstellt, bevor sie die Anweisung annimmt. Mit anderen Worten kann die Drohne als Verifizierungsdienst fungieren, eine oder mehrere Identitäts-Blockchains speichern und die Verifizierung einer Kette verlangen, bevor sie auf Anweisungen reagiert. Als weiteres Beispiel kann eine Organisation Daten von einem Netzwerk verbundener Vorrichtungen empfangen. Die Vorrichtungen können der Organisation Daten (z. B. Sensormesswerte, Bilder etc.) bereitstellen. Bei einem solchen Aufbau kann die Organisation eine oder mehrere Identitäts-Blockchains für das Netzwerk speichern, z. B. einen Entstehungsblock bzw. Genesis-Block für das Netzwerk und mehrere Ketten, die von dem Netzwerk abzweigen, und zwar eine für jede Vorrichtung in dem Netzwerk. Unter Verwendung offenbarter Techniken kann eine Vorrichtung einen Signaturschlüssel mit den Daten bereitstellen, und bevor das empfangende System die Daten akzeptiert, kann das empfangende System die Vorrichtung gegen eine Blockchain unter Verwendung eines mit den Daten bereitgestellten Signaturschlüssels verifizieren.
Figurenliste
Die hierin beschriebenen Verfahren, Systeme und/oder Programmierungen werden im Hinblick auf exemplarische Implementierungen weiter beschrieben. Diese exemplarischen Implementierungen werden detailliert mit Bezug auf die Zeichnungen beschrieben. Diese Implementierungen sind nicht einschränkende Beispiele, in denen gleiche Bezugszeichen ähnliche Strukturen in den verschiedenen Ansichten der Zeichnungen darstellen, und wobei:

1 eine High-Level-Darstellung einer Systemkonfiguration gemäß einer Implementierung beschreibt;
2 ein Blockdiagramm exemplarischer Elemente beschreibt, die bei einem Blockchain-Identifikationsnachweis verwendet werden, gemäß einer Implementierung;
3 ein Flussdiagramm eines exemplarischen Prozesses zum Generieren einer Kette für eine Entität veranschaulicht, die bei einem Blockchain-Identifikationsnachweis verwendet wird, gemäß einer Implementierung;
4 ein Flussdiagramm eines exemplarischen Prozesses zum Verwenden einer Kette als Identifizierungsnachweis gemäß einer Implementierung; und
5 ein Flussdiagramm eines exemplarischen Prozesses zum Hinzufügen von Blöcken zu einer Kette gemäß einer Implementierung.

DETAILLIERTE BESCHREIBUNG
In der folgenden detaillierten Beschreibung werden zahlreiche spezifische Details beispielhaft dargelegt, um ein gründliches Verständnis der relevanten Lehren zu ermöglichen. Für den Fachmann sollte es jedoch offensichtlich sein, dass die vorliegenden Lehren ohne solche Details in die Praxis umgesetzt werden können. In anderen Fällen wurden wohlbekannte Verfahren, Prozeduren, Systeme, Komponenten und/oder Schaltungen auf einer relativ hohen Ebene ohne Details beschrieben, um zu vermeiden, dass Aspekte der vorliegenden Lehren unnötig verschleiert werden.
Implementierungen stellen einen Rahmen bereit, der es autorisierten Organisationen ermöglicht, einen Blockchain-Identifikationsnachweis zu führen und bereitzustellen. Insbesondere kann eine autorisierte Organisation nach einem erfolgreichen Identitätsnachweisprozess eine Kette generieren und dann eine Schnittstelle bereitstellen, z. B. eine Anwendungsprogrammierschnittstelle (API), die es anderen ermöglicht, eine Verifizierungsabfrage für eine Entität zu senden und eine Abfrageantwort zu erhalten. Die Antwort gibt an, dass die angebliche Entität entweder verifiziert wurde oder nicht. Die Antwort kann auch Informationen enthalten, die einem Block oder Blöcken in einer verifizierten Kette entnommen werden, anhand derer der Anforderer eine zusätzliche Verifizierung durchführen kann.
Wie in 1 gezeigt, kann eine vernetzte Umgebung 100 eine Anzahl von Rechenvorrichtungen enthalten, die über ein Netzwerk 160 oder eine Reihe von Netzwerken 160 miteinander in Datenkommunikation stehen. Das Netzwerk 160 kann das Internet, ein Local Area Network (LAN), ein Wide Area Network (WAN), ein Mobilfunknetz (z. B. 5G-Mobilfunk), ein Intranet etc. oder eine Kombination davon umfassen. Beispielsweise kann ein Client 170 mit einem oder mehreren Nachweis-Hosts 110 über ein LAN, ein Mobilfunknetz, ein Intranet oder das Internet kommunizieren. Der Nachweis-Host 110a kann mit dem Nachweis-Host 110b und/oder 110n über eine beliebige Kombination aus Internet, Intranet, WAN, LAN, Mobilfunknetz, einer drahtgebundenen Verbindung, einer drahtlosen Verbindung etc. kommunizieren, Bei einigen Implementierungen stellt das Netzwerk 160 mehr als ein Netzwerk dar, z. B. das Internet und ein WAN oder das Internet und ein Wl-Fl- oder Mobilfunknetz.
Die Rechenvorrichtungen in der Umgebung 100 können Host-Computer enthalten, wie Nachweis-Hosts 110a, 110b und 110n. Die Computervorrichtungen können auch Client-Vorrichtungen enthalten, wie den Client 170. Der Client 170 stellt eine Benutzerschnittstelle, beispielsweise über einen Browser, eine mobile Anwendung oder eine andere Schnittstelle bereit, damit ein menschlicher Benutzer auf eine Abfragefunktionalität, z. B. über eine Abfrage API 125 eines Nachweis-Hosts 110 über das Netzwerk 160 zugreifen kann. Der Client 170 kann auch auf verschiedene andere Anwendungen zugreifen, einschließlich Anwendungen 112, die von dem Nachweis-Host 110a bereitgestellt werden, und ähnliche Anwendungen, die von anderen Nachweis-Hosts bereitgestellt werden, andere Cloud-basierte Anwendungen etc.
Der Nachweis-Host 110a : (z. B. auch 110b, 110n etc.) kann ein webbasiertes System für eine autorisierte Organisation sein, wie eine Finanzorganisation, eine Regierungsbehörde oder -abteilung, eine Finanzinstitution, eine Bildungsinstitution, eine mit dem Gesundheitswesen verbundene Organisation, eine Lizenzierungsorganisation, ein Versorgungsunternehmen, ein Unternehmen etc. Der Nachweis-Host 110a kann von seinen Benutzern (z. B. Mitarbeitern oder Kunden) verlangen, dass sie sich mit Anmeldeinformationen (typischerweise einem Benutzernamen und einem Passwort oder dergleichen) anmelden, bevor sie auf Anwendungen 112 und/oder Nachweisanwendung 120 des Nachweis-Hosts 110a zugreifen. Der Nachweis-Host 110a kann eine Rechenvorrichtung beinhalten, wie etwa einen Computer, einen Server oder eine Anzahl kommunikativ verbundener, verteilter Server, einen Mainframe etc., die einen oder mehrere Prozessoren 102 aufweist (z. B. einen in einem Substrat gebildeten Prozessor), die konfiguriert sind, Anweisungen auszuführen, die in einem Speicher 104 gespeichert sind, wie Hauptspeicher, RAM, Flash, Cache oder Disk bzw. Platte. Die Anweisungen können in einer Laufzeitumgebung, Funktionsmodulen und/oder Engines, z. B. Anwendungen 112, NachweisAnwendung 120, gespeichert werden und können Funktionalität bereitstellen, um das Funktionieren und den Betrieb der autorisierten Organisation (vertrauenswürdige Entität) zu unterstützen. Bei einigen Implementierungen kann der Nachweis-Host 110a eine Vorrichtung sein, z. B. eine ferngesteuerte Vorrichtung, die eine Verifizierung durchführt, bevor sie Anweisungen akzeptiert und darauf reagiert, z. B. Daten 114 aktualisiert und/oder eine Anwendung 112 ausführt.
Wie hierin verwendet, ist eine autorisierte Organisation jede Organisation, z. B. ein Unternehmen, eine Behörde, eine Gruppe, eine Berufsorganisation etc. oder eine ferngesteuerte Vorrichtung, die einen Identitätsnachweisprozess durchführt. Eine autorisierte Organisation kann auch als vertrauenswürdige Entität bezeichnet werden. Eine autorisierte Organisation führt einen Identitätsnachweisprozess als Teil zumindest eines Dienstes oder einer Aufgabe durch. Wie hierin verwendet, ist ein Identitätsnachweisprozess ein Prozess, der mit dem Zweck durchgeführt wird, etwas über eine Entität zu verifizieren. Ein Identitätsnachweisprozess stützt sich typischerweise auf spezifische Dokumente, um den Identitätsnachweisprozess abzuschließen. Nicht einschränkende Beispiele eines Identitätsnachweisprozesses beinhalten den Prozess zum Erhalten einer Lizenz, einer Anwaltszulassung, eines Reisepasses etc., einen Prozess zum Einstellen eines neuen Mitarbeiters, einen Prozess zum Verifizieren eines Land- oder Fahrzeugtitels, einen Prozess zum Einrichten einer Abrechnung, einen Prozess zum Einrichten eines verbundenen Netzwerks von Vorrichtungen oder zum Einrichten einer ferngesteuerten Vorrichtung etc. Somit kann ein erfolgreicher Identitätsnachweisprozess zumindest ein unterstützendes Dokument umfassen, z. B. eine Geburtsurkunde, einen Titel, eine Lizenz, eine Sozialversicherungskarte, ein aktuelles Poststück, einen Standort, eine Vorrichtungskennung, ein Bild eines spezifischen Abschnitts einer Vorrichtung etc. Das Ergebnis eines Identitätsnachweisprozesses kann eine Verifizierung einer Identität einer Person oder eine Verifizierung dessen sein, dass ein Objekt das ist, was es zu sein scheint, eine Verifizierung, dass ein Objekt einer Person gehört, eine Verifizierung, dass ein Objekt Teil des Netzwerks ist etc. Ein Identitätsnachweisprozess kann streng (z. B. Erlangung eines Reisepasses oder Anwaltszulassung) oder locker (z. B. Einrichtung der Stromversorgung eines Hauses) sein. Somit kann jede autorisierte Organisation durch ihren jeweiligen Identitätsnachweisprozess ein unterschiedliches Maß an Gewissheit über die Identität der Entität repräsentieren. Die Entität kann eine Person, ein Tier, ein physisches Objekt oder ein digitales Objekt sein (z. B. ein verbundenes Netzwerk von Vorrichtungen, wie etwa ein Drohnennetzwerk, ein Internet-der-Dinge-Netzwerk etc.).
Bei einigen Implementierungen können eine oder mehrere Anwendungen 112 einem Benutzer des Nachweis-Hosts 110a ermöglichen, den Identitätsnachweisprozess abzuschließen oder zu dokumentieren. Bei solchen Implementierungen kann die Anwendung die Nachweisanwendung 120 nach erfolgreichem Abschluss eines Identitätsnachweisprozesses für eine Entität aufrufen oder starten. Bei einigen Implementierungen kann der Benutzer (ein Vertreter der autorisierten Organisation, die dem Nachweis-Host 110a zugeordnet ist) die Nachweisanwendung 120 nach einem erfolgreichen Abschluss des Identitätsnachweisprozesses für die Entität direkt aufrufen oder starten.
Die Nachweisanwendung 120 generiert eine Identitätskette für die Entität in dem verkettbaren Identitätsgraphen 131. Die Identitätskette enthält einen Entstehungsblock bzw. Genesis-Block (oder Entstehungsknoten bzw. Genesis-Knoten) für die Entität. Der Genesis-Block ist ein erster Block in der Kette und weist keinen Zeiger auf einen anderen Block auf. Bei einigen Implementierungen weist der Genesis-Block Inhalt auf, der eine physische Eigenschaft der Entität erfasst. Als nicht einschränkende Beispiele kann der Inhalt des Genesis-Blocks ein zweidimensionales Bild der Entität (oder eines Teils der Entität), ein dreidimensionales Bild der Entität, biometrische Daten (Fingerabdrücke, Netzhautscans, DNA-Sequenzen), einen Stimmabdruck, ein Bild eines Titels, Daten von einem bestimmten Speicherort einer Vorrichtung, einen ursprünglichen oder zugewiesenen Standort einer Vorrichtung etc. beinhalten. Eine Identitätskette ist eine kurze Blockchain, z. B. mit nur wenigen (3, 5, 10) Blöcken in der Kette für eine Entität. Die Blöcke werden in einem verkettbaren Identitätsgraphen 131 gespeichert. Der verkettbare Identitätsgraph 131 kann einen Genesis-Block für Entitäten aufweisen, für die die autorisierte Organisation einen erfolgreichen Identitätsnachweisprozess abgeschlossen hat. Jede Entität weist einen entsprechenden Genesis-Block in dem verkettbaren Identitätsgraphen 131 auf. Der Genesis-Block kann auch als Wurzel der Identitätskette bezeichnet werden. Jede Kette in dem verkettbaren Identitätsgraphen 131 ist in einem Genesis-Block verwurzelt. Bei einigen Implementierungen kann eine Entität mehr als eine Kette aufweisen, die in ihrem Genesisblock verwurzelt ist. Beispielsweise kann eine Person, die ihren Namen ändert und dies der autorisierten Organisation nachweist, zwei Ketten aufweisen, die auf demselben Genesis-Block verwurzelt sind. Als weiteres Beispiel kann eine entfernte Vorrichtung zwei oder mehr Ketten aufweisen, die in ihrem Genesis-Block verwurzelt sind, eine für jeden eindeutigen Benutzer, der berechtigt ist, die entfernte Vorrichtung zu betreiben. Als ein weiteres Beispiel kann ein Netzwerk von entfernten Vorrichtungen eine Kette für jede autorisierte Vorrichtung aufweisen, die mit einem Genesis-Knoten für das Netzwerk verwurzelt ist. Alternativ könnte jede entfernte Vorrichtung ihren eigenen Genesis-Knoten und ihre eigene Identitätskette aufweisen. Bei einigen Implementierungen kann eine Identitätskette eine Hauptkette aufweisen und Seitenketten können weniger Befugnis darstellen. Beispielsweise kann eine entfernte Vorrichtung Anweisungen ausführen, wenn eine Hauptkette verifiziert ist, aber möglicherweise nur auf Abfragen antworten, wenn eine Seitenkette verifiziert ist.
Der verkettbare Identitätsgraph 131 ist anders als eine herkömmliche Datenbank oder ein ähnlicher Aufzeichnungs- bzw. Datensatzspeicher. Erstens können herkömmliche Datenbankaufzeichnungen bzw. -datensätze typischerweise geändert werden. Verkettbare Identitätsblöcke (auch als Blöcke oder Identitätsknoten bezeichnet) können nicht geändert werden, und eine Änderung in einem beliebigen Identitätsblock in der Kette führt zu einer unterbrochenen Kette, es sei denn, alle Nachfolgeblöcke werden ebenfalls identifiziert und modifiziert. Da alle Änderungen an Identitätsblöcken erhebliche Zeit- und Rechenleistungskosten mit sich bringen, sind solche Änderungen unpraktisch. Diese Unveränderlichkeit macht einen verkettbaren Identitätsgraphen 131 widerstandsfähig gegen Betrug und Identitätsdiebstahl. Der verkettbare Identitätsgraph 131 kann ein verbesserter Merkle-Baum sein, bei dem die verschiedenen Blöcke nur über eine Einbeziehung eines Hash des Vorgängerblocks verknüpft sind. Jeder Identitätsblock in einer Kette weist Inhalt auf. Der Inhalt enthält Nutzlastdaten und das Hash-Ergebnis des Inhalts seines Vorgängers. Ein Genesis-Block ist als Genesis-Block identifizierbar, da ihm ein Hash-Ergebnis fehlt. Wie hierin verwendet ist die Bezugnahme auf Hash als Substantiv dasselbe wie die Bezugnahme auf ein Hash-Ergebnis und umgekehrt.
Die Blöcke in dem verkettbaren Identitätsgraphen 131 können Aspekte der erfolgreichen Identitätsnachweisprozesse aufzeichnen. Beispielsweise können ein oder mehrere Identitätsblöcke als Nutzlastdaten Informationen über das Dokument oder die Dokumente aufweisen, die in dem Identitätsnachweisprozess verwendet werden. Beispielsweise kann ein solcher Block den Typ des Dokuments/der Dokumente, ein Bild des Dokuments/der Dokumente und ein oder mehrere aus dem/den Dokument(en) extrahierte,Datenelemente aufzeichnen. Ein oder mehrere Identitätsblöcke können als Nutzlastdaten Informationen von einem Dokument oder einem Berechtigungsnachweis aufweisen, das bzw. der als Ergebnis des erfolgreichen Identitätsnachweisprozesses ausgestellt wird, z. B. eine Führerscheinnummer, eine Passnummer, ein Titel etc. Ein oder mehrere Identitätsblöcke in einer Kette kann bzw. können eine Aufzeichnung aufweisen, die sich auf die Entität bezieht, z. B. eine Aufzeichnung einer Stimme. Ein oder mehrere Identitätsblöcke in einer Kette können als Nutzlastdaten Informationen über eine Aktivität aufweisen, die sich auf die Entität bezieht. Wenn die autorisierte Organisation beispielsweise eine Abteilung ist, die eine Lizenz ausstellt, kann einer Person, die die Lizenz erneuert, einen neuen Identitätsblock (oder Blöcke) zu der Identitätskette dieser Person hinzufügen lassen. Ein oder mehrere Identitätsblöcke in einer Kette können beliebige digitalisierte Materialien enthalten, die die Konsistenz und Vollständigkeit eines Blocks verbessern oder unterstützen.
Implementierungen umfassen auch Graphzugriffsdatensätze 135. Die Graphzugriffsdatensätze 135 erleichtern die Identifizierung eines letzten Knotens in einer Identitätskette für eine bestimmte Entität. Die Graphzugriffsdatensätze 135 speichern Datensätze, die durchsuchbare Eigenschaften von Entitäten enthalten. Diese durchsuchbaren Eigenschaften werden als Schlüsseleigenschaften oder Suchfelder (Search Field) bezeichnet. Schlüsseleigenschaften müssen eine Entität nicht eindeutig identifizieren, sollten jedoch Eigenschaften einer Entität identifizieren. Beispiele für Schlüsseleigenschaften sind Vor- und Nachname, Geburtsdatum, Kfz-Kennzeichen, Parzellennummer, Adresse etc. Zusätzlich zu einer oder mehreren Schlüsseleigenschaften enthält ein Datensatz in den Graphzugriffsdatensätzen 135 auch ein Hash-Ergebnis des nächsten Blocks in der Kette. Unabhängig davon, ob Graphzugriffsdatensätze 135 als Blöcke in dem verkettbaren Identitätsgraphen oder als eine Tabelle oder in einem anderen Format gespeichert werden, wird ein Graphzugriffsdatensatz daher als ein Endknoten in der Identitätskette angesehen.
Die Identitätsketten des verkettbaren Identitätsgraphen 131 unterscheiden sich von anderen Blockketten in der Verwendung eines Signaturschlüssels, der benötigt wird, um die Kette erfolgreich zu durchlaufen und den Genesis-Block zu lokalisieren. Dieser Signaturschlüssel wird ausgewählt, bevor eine Kette generiert wird, und wird vom Verwalter der Entität ausgewählt. Handelt es sich bei der Entität um eine Person, ist der Inhaber der Entität die Person selbst. Wenn die Entität keine Person ist, ist der Verwalter der Entität eine Person, die die Verwaltung der Entität beansprucht. Der Signaturschlüssel kann aus beliebigen Daten bestehen, die vom Verwalter der Entität ausgewählt werden. Beispielsweise kann der Signaturschlüssel ein Bild, ein Zitat, ein Lieblingsautor/Buch/Film/Ziel/Datum/Essen etc. sein. Wenn die Entität eine Vorrichtung ist, die Daten meldet, kann der Verwalter der Entität die Vorrichtung dahingehend konfigurieren, den Signaturschlüssel zu melden. Der Signaturschlüssel für die Vorrichtung kann z. B. ein digitales Bild oder ein Scan eines bestimmten Teils der Vorrichtung, ein der Vorrichtung zugeordneter Standort (z. B. Ursprungsort, aktueller Standort), Daten von einer statischen Speicheradresse etc. sein. Der Signaturschlüssel kann eine Kombination aus Datenelementen sein, z. B. ein Name, und Datum, ein Datum und Ort, ein Zitat und ein Autorenname etc. Der Signaturschlüssel muss möglicherweise Regeln entsprechen, die von der autorisierten Organisation festgelegt werden, kann aber auch alles andere sein, was der Verwalter der Entität auswählt. Der Signaturschlüssel wird zwar verwendet, um die Identitätsknoten zu generieren, wird jedoch niemals durch den Nachweis-Host 110a gespeichert. Der Signaturschlüssel wird von dem Nachweis-Host 110a nur beim Generieren von Identitätsknoten und beim Abfragen des verkettbaren Identitätsgraphen 131 verwendet. Dies erhöht die Sicherheit der Identitätskette, vermeidet aber das Risiko, einen Schlüssel zu verlieren, der zum Verifizieren der Kette benötigt wird. Da der Signaturschlüssel vom Verwalter ausgewählt wird, besteht unter normalen Umständen ein geringes Risiko, dass er vergessen wird oder verloren geht.
Die Nachweisanwendung 120 kann ein Kettengenerierungsprogramm 123 und eine Abfrage-API 125 enthalten. Das Kettengenerierungsprogramm 123 kann konfiguriert sein, nach einem erfolgreichen Identitätsnachweisprozess eine Identitätskette zu generieren. Das Kettengenerierungsprogramm 123 kann einen Genesis-Knoten aus Genesis-Daten generieren, kann einen oder mehrere Identitätsknoten aus Daten generieren, die sich auf den Identitätsnachweisprozess beziehen, und kann einen Graphzugriffsdatensatz als letzten Knoten in der Identitätskette generieren. Das Kettengenerierungsprogramm 123 kann die Kette unter Verwendung eines Signaturschlüssels generieren, der von der Entität oder dem Verwalter der Entität bereitgestellt wird. Bei einigen Implementierungen kann dieser Signaturschlüssel mit dem Inhalt eines vorherigen Knotens kombiniert und als Eingabe für den Hash-Algorithmus bereitgestellt werden, um ein Hash-Ergebnis für einen vorherigen Knoten zu generieren. So kann beispielsweise der Signaturschlüssel mit dem Inhalt eines Genesis-Knotens kombiniert werden, bevor ein Hash-Ergebnis generiert wird, das in einem ersten Identitätsknoten gespeichert wird. Der Inhalt dieses Identitätsknotens (z. B. Nutzlastdaten und das Hash-Ergebnis) kann mit dem Signaturschlüssel kombiniert werden, um ein zweites Hash-Ergebnis zu generieren, das in einem nächsten Identitätsknoten oder in dem Graphzugriffsdatensatz gespeichert wird. Bei einigen Implementierungen kann der Signaturschlüssel als der Schlüssel in einem Verschlüsselungsprozess verwendet werden, der den Inhalt eines Knotens verschlüsselt, bevor der Knoten in dem verkettbaren Identitätsgraphen - 131 gespeichert wird. Bei einigen Implementierungen kann der Signaturschlüssel sowohl als Eingabe für die Hash-Funktion als auch als Verschlüsselungsschlüssel verwendet werden.
Der Nachweis-Host 110a kann den verkettbaren Identitätsgraphen 131 verwenden, um Verifizierungsdienste anzubieten. Bei einem Verifizierungsdienst stellt ein angeblicher Verwalter einer Entität (die Entität oder der Eigentümer der Entität) einen Abfrageschlüssel und Abfrageeigenschaften als Parameter bereit, und der Nachweis-Host 110a verwendet diese Eingabe, um entweder zu verifizieren, dass eine ununterbrochene Kette unter Verwendung der Abfrageparameter identifiziert wird, oder dass keine Kette identifiziert wird. Wenn eine ununterbrochene Kette identifiziert wird, ist die Verifizierung erfolgreich. Wenn keine ununterbrochene Kette identifiziert wird, ist die Verifizierung nicht erfolgreich. Der Nachweis-Host 110a kann die Abfrage-API 125 verwenden, um anderen Plattformen, z. B. einem oder mehreren Clients 170 , eine Abfrageschnittstelle anzubieten. Der Client 170 kann die Abfrageparameter (den Abfrageschlüssel, Suchfelder und optional Rückgabefelder) bereitstellen und kann eine Abfrageantwort erhalten. Die Abfrageantwort kann ein Hinweis auf entweder eine erfolgreiche oder eine nicht erfolgreiche Verifizierung sein. Die Abfrageantwort kann Daten von dem Genesis-Knoten enthalten. Die Daten von dem Genesis-Knoten können für einen zusätzlichen Verifizierungsschritt beim Client verwendet werden. Die Abfrageantwort kann Daten von anderen Knoten in der Kette enthalten. Beispielsweise können beliebige Nutzlastdaten von einem Knoten in einer Antwort enthalten sein. Bei einigen Implementierungen kann der Abfrageanforderer anfordern, dass ein oder mehrere Datenelemente mit dem Verifizierungserfolgsindikator zurückgegeben werden, z. B. Rückgabefelder.
Ein Verifizierungsdienst wird durch eine Verifizierungsanfrage, auch Verifizierungsabfrage oder nur Abfrage genannt, initiiert. Die Nachweisanwendung 120 kann als Antwort auf eine Abfrage verifizieren, ob eine vollständige Identitätskette existiert. Die Abfrage kann von einem Benutzer des Nachweis-Hosts 110a oder Clients 170 initiiert werden. Eine vollständige Kettenverifizierung bzw. Verifizierung einer vollständigen Kette beginnt mit dem letzten Knoten in der Kette (z. B. einem Graphzugriffsdatensatz) und folgt einer Kette von Identitätsknoten, bis ein Genesis-Knoten erreicht ist. Wenn ein Genesis-Knoten nicht erreicht wird, schlägt die Verifizierung fehl. Bei einigen Implementierungen beinhaltet das Suchen nach Blöcken in dem verkettbaren Identitätsgraphen 131 eine Brute-Force-Suche. Bei einer Brute-Force-Suche sucht das System ausgehend von dem letzten Block nach einem Vorgängerblock in dem Graphen. Ein Vorgängerblock ist ein Block mit Inhalt, der nach Bereitstellung (optional mit dem Abfrageschlüssel) für die Hash-Funktion in einem Hash resultiert, der mit dem im letzten Block gespeicherten Hash-Ergebnis übereinstimmt. Dieser Vorgang wiederholt sich dann, wobei das Hash-Ergebnis des Vorgängerblocks verwendet wird, um dessen Vorgängerblock zu finden etc., bis ein Genesis-Block erreicht ist. Ein Genesis-Block kann identifizierbar sein, weil ihm ein als Teil des Inhalts gespeichertes Hash-Ergebnis fehlt. Diese Brute-Force-Suche kann rechenintensiv sein. Bei einigen Implementierungen kann der Nachweis-Host 110a spezielle Prozessoren umfassen, die verwendet werden, um Identitätsketten zu verifizieren.
Bei einigen Implementierungen kann jeder Block in einer Kette ein Datenelement enthalten, das den Block als zu derselben Kette gehörend identifiziert. Dieses Datenelement darf nicht verschlüsselt werden, selbst wenn der restliche Inhalt verschlüsselt ist. So kann beispielsweise, sobald ein Identitätsblock unter Verwendung des Hash-Ergebnisses des Graphzugriffsdatensatzes lokalisiert wird, ein Identifizierer (z. B. ein Gruppenidentifizierer) verwendet werden, um die Blöcke in dem verkettbaren Identitätsgraphen 131 einzugrenzen, die mögliche Kandidaten für die Kette sind. Ein solches System ist in der US-Patentveröffentlichung Nr. 2020-0265046-A1 beschrieben, die hierin durch Bezugnahme aufgenommen ist. Bei einigen Implementierungen kann die Nachweisanwendung 120 die Kette für eine Entität verifizieren, bevor irgendwelche zusätzlichen Aktionen an der Entität vorgenommen werden können.
Bei einigen Implementierungen kann die Nachweisanwendung 120 eine Kette möglicherweise nicht ändern, sobald die Kette generiert wurde. Bei einigen Implementierungen kann die Nachweisanwendung 120 als Antwort auf bestimmte Aktionen zusätzliche Blöcke zu einer Kette hinzufügen. Jede autorisierte Organisation kann ihre eigenen Richtlinien und Regeln festlegen, für die Aktionen einen Block zu einer Kette hinzufügen. Ein nicht einschränkendes Beispiel ist eine Lizenzierungsentität, die eine Lizenz erneuert; die Erneuerungsaktion kann der Kette nach Verifizierung der Kette hinzugefügt werden. Bei einigen Implementierungen kann die Nachweisanwendung 120 Verzweigungen von einem Genesis-Block oder einem anderen Block in der Identitätskette für bestimmte Aktionen hinzufügen. In einem nicht einschränkenden Beispiel kann eine Namensänderung (z. B. durch Heirat oder Scheidung) zur Generierung einer neuen Kette führen, die von dem Genesis-Block für die Entität abzweigt. Alternativ kann eine Namensänderung zu einem neuen Graphzugriffsdatensatz mit dem neuen Namen führen, so dass die Verzweigung weiter unten in der Kette erfolgt, d. h. weiter weg von dem Genesis-Block. In diesem Beispiel könnte eine Verzweigung an jedem Block in der Kette auftreten. Bei einigen Implementierungen kann eine Verzweigung, die aus dem Genesis-Block stammt, einen anderen Signaturschlüssel zum Generieren der neuen Verzweigung verwenden. Bei einigen Implementierungen kann diese zweite Kette (mit einem anderen Signaturschlüssel als die erste Kette) Schlüsseleigenschaften aufweisen, die sich von den Schlüsseleigenschaften der ersten Kette unterscheiden. Mit anderen Worten können sich die Datenelemente, die zum Identifizieren des Graphzugriffsdatensatzes verwendet werden, der als der letzte Block in der Kette angesehen wird, zwischen den zwei Ketten unterscheiden. Bei einer solchen Implementierung kann die Entität zwei unterschiedliche Arten zum Verifizieren einer Kette aufweisen. So kann beispielsweise ein Netzwerk von Vorrichtungen einen Genesis-Knoten für das Netzwerk aufweisen und die dem Netzwerk bekannten Vorrichtungen aufzeichnen und eine separate Kette für jede Vorrichtung aufweisen, sodass jede Vorrichtung die Kette unter Verwendung ihres eigenen Signaturschlüssels verifizieren könnte.
Der Client 170 kann ein persönliches Rechensystem, ein Terminal, ein Laptop, ein Tablet, eine Point-of-Sale-Vorrichtung, eine mobile Vorrichtung, ein Unternehmenssystem, ein Server oder eine andere Art von Computervorrichtung/- system sein, die bzw. das konfiguriert ist, Informationen über das Netzwerk 160 zu senden und zu empfangen. Der Client 170 kann einen oder mehrere Prozessoren 172 (z. B. einen in einem Substrat gebildeten Prozessor) enthalten, die konfiguriert sind, Anweisungen auszuführen, die in einem Speicher 174 gespeichert sind, wie etwa Hauptspeicher, RAM, Flash, Cache, oder Platte. Der Client 170 kann auch Eingabevorrichtungen 179 enthalten, wie etwa ein Mikrofon, eine Tastatur (virtuell oder physisch), einen Berührungsbildschirm, eine Maus, eine Kamera, ein Diktiergerät etc. Der Client 170 enthält auch eine Anzeige 178 oder eine andere Ausgabevorrichtung. Der Client 170 kann auch eine oder mehrere Anwendungen 176 enthalten, die verschiedene Funktionen ausführen, z. B. einen Browser, ein Textverarbeitungsprogramm, ein Tabellenkalkulationsprogramm, einen E-Mail-Client, eine mobile Anwendung etc. Der Client 170 kann mit dem Nachweishost 110a (und/oder Nachweishost 110b, 110n etc.) über Anwendungen 176 kommunizieren, die die Abfrage-API 125 unter Verwendung bekannter Techniken aufrufen.
Die Umgebung 100 kann auch mehrere unterschiedliche Nachweis-Hosts enthalten, wie z. B. den Nachweis-Host 110b und den Nachweis-Host 110n. Obwohl in 1 der Kürze halber nicht gezeigt, können der Nachweis-Host 110b und der Nachweis-Host 110n auch Komponenten enthalten, die für den Nachweis-Host 110a dargestellt sind. Bei einigen Implementierungen können einer oder mehrere der Nachweis-Hosts von derselben Geschäftsentität betrieben werden, z. B. als verteiltes System. Bei einigen Implementierungen kann die Nachweisanwendung 120 konfiguriert sein, auf Graphzugriffsdatensätze 135 und/oder verkettbare Identitätsgraphen 131 zuzugreifen, die an einem anderen Nachweis-Host 110 gespeichert sind. Bei einigen Implementierungen kann die Nachweisanwendung 120 konfiguriert sein, eine Abfrage mit einer anderen Nachweisanwendung zu koordinieren, die auf einem anderen Nachweis-Host 110 ausgeführt wird.
Die Konfiguration des Nachweis-Hosts 110a ist ein Beispiel, und Implementierungen umfassen andere Konfigurationen. Zum Beispiel können von der Nachweisanwendung 120 ausgeführte Fähigkeiten in einer oder mehreren der Anwendungen 112 enthalten sein. Gleichermaßen kann die Abfrage-API 125 ein eigenständiges Modul sein oder kann in einer oder mehreren der Anwendungen 112 enthalten sein. Ebenso können die Daten, wie ein oder mehrere der Daten 114, Graphzugriffsdatensätze 135 und der verkettbare Identitätsgraphen 131, über mehrere Rechenvorrichtungen verteilt sein und/oder für den Nachweishost 110a zugänglich, aber physisch entfernt davon sein. Darüber hinaus repräsentiert die Umgebung 100 eine exemplarische Umgebung. Obwohl sie in 1 mit spezifischen Komponenten dargestellt ist, kann die Umgebung 100 zusätzliche, nicht dargestellte Komponenten enthalten, oder sie kann nicht alle gezeigten Elemente enthalten. Außerdem können einige Komponenten zu einer einzigen Komponente kombiniert werden. Darüber hinaus ist der Nachweis-Host 110a so zu verstehen, dass er so konfiguriert ist, dass er alle anwendbaren Gesetze, Vorschriften oder andere Bedingungen in Bezug auf die Dateneingabe und die von den Datenquellen erhaltenen Daten erfüllt.
2 veranschaulicht ein Blockdiagramm exemplarischer Elemente, die bei einem Blockchain-Identifikationsnachweis verwendet werden, gemäß einer Implementierung. Der verkettbare Identitätsgraph 131 enthält mehrere Entität-Genesis-Blöcke 200, z. B. Block 200(1) bis 200(n). Die Genesis-Blöcke 200 repräsentieren Wurzeln von Identitätsketten. Jeder Genesis-Block 200 weist zugeordnete Nutzlastdaten 201 auf, z. B. Nutzlastdaten 201(1) bis Nutzlastdaten 201(n). Die Nutzdaten eines Genesis-Blocks können auch als Genesis-Daten bezeichnet werden. Die Genesis-Daten können beliebige Daten sein, die eine physische Eigenschaft der Entität erfassen. Bei einigen Implementierungen können die Genesis-Daten die Entität eindeutig identifizieren. Bei einigen Implementierungen müssen die Genesis-Daten für die Entität nicht eindeutig sein. Nicht einschränkende Beispiele für Genesis-Daten umfassen Bilder (2- oder 3-dimensional) der Entität, von der Entität erhaltene biometrische Daten (einschließlich genetischer Daten, Fingerabdrücke, Stimmprofile, Netzhautscans etc.), eine Adresse von Immobilien, ein Bild eine Fahrzeugidentifikationsnummer, eine Spektralanalyse eines Gemäldes etc. Bei einigen Implementierungen werden die Nutzdaten 201 verschlüsselt, bevor sie gespeichert werden. Einige Implementierungen können den vom Verwalter der Entität erhaltenen Signaturschlüssel als Verschlüsselungsschlüssel verwenden. Gemäß der Offenbarung kann der Signaturschlüssel irgendetwas sein, das von der Entität oder, wenn die Entität keine Person ist, einem Eigentümer der Entität ausgewählt wird. Der Genesis-Block 200 wird als ein erster Block in einer Identitätskette angesehen. Der Inhalt eines Genesis-Blocks 200 sind die Nutzlastdaten 201.
Der verkettbare Identitätsgraph 131 kann Hunderte, Tausende oder sogar Millionen von Identitätsketten aufweisen. Eine Identitätskette verläuft von einem Genesis-Block zu einem Graphzugriffsdatensatz, der ein Datensatz in den Graphzugriffsdatensätzen 135 ist. Blöcke zwischen dem Graphzugriffsdatensatz und dem Genesis-Block können als Verknüpfungsblöcke bezeichnet werden. In dem Beispiel von 2 enthalten Verknüpfungsblöcke die Blöcke 205, 210 und 215. Die Verknüpfungsblöcke können unterschiedliche Nutzlastdaten aufweisen. Zum Beispiel enthalten die Blöcke 205 in dem Beispiel von 2 Informationen über einen Identifikationsfaktor (Id Factor), der in dem Identitätsnachweisprozess verwendet wird. Die Blöcke 210 von 2 weisen Nutzlastdaten, die andere Informationen enthalten, die in dem Identitätsnachweisprozess erhalten werden, durch diesen generiert werden oder für diesen relevant sind. Die Blöcke 215 enthalten Nutzlastdaten, die sich auf eine Aktivität beziehen. Wie in 2 dargestellt, können Identitätsketten eine beliebige Anzahl von Blöcken aufweisen, sind aber im Allgemeinen kurz (zwischen drei und 10 oder 15 Blöcken). Die in 2 dargestellten Arten von Verknüpfungsblöcken werden zu Veranschaulichungszwecken verwendet, und Blöcke in einer Identitätskette können verschiedene Arten von Daten enthalten. Der Inhalt eines Verknüpfungsblocks sind die Nutzdaten und ein Hash-Ergebnis. Das Hash-Ergebnis wird aus dem Inhalt eines vorherigen Blocks in der Kette generiert. Somit kann beispielsweise <hash1> ein Hash-Ergebnis sein, das unter Verwendung der Nutzlastdaten 201(1) generiert wird, und <hash2> kann ein Hash-Ergebnis sein, das unter Verwendung von <ld Faktor 1>, <ld Faktor 2> und <Hash1> generiert wird. etc.
Die Verknüpfungsblöcke in dem verkettbaren Identitätsgraphen 131 werden unter Verwendung eines Signaturschlüssels generiert. Der Signaturschlüssel kann je nach Implementierung unterschiedlich verwendet werden. Beispielsweise können einige Implementierungen den Signaturschlüssel mit dem Inhalt eines vorherigen Blocks kombinieren, um das Hash-Ergebnis zu generieren, das im nächsten Block gespeichert wird. Zum Beispiel kann <Hash1> ein Hash-Ergebnis sein, das unter Verwendung der Nutzlastdaten 201(1) und des Signaturschlüssels generiert wird, während <Hash2> ein Hash-Ergebnis sein kann, das unter Verwendung von <ld Faktor 1>, <ld Faktor 2>, <Hash1> und des Signaturschlüssels etc. generiert wird. Bei einigen Implementierungen kann der Signaturschlüssel verwendet werden, um den Inhalt eines Blocks zu verschlüsseln, bevor er gespeichert wird. Bei solchen Implementierungen wird der Inhalt eines Blocks unter Verwendung eines Abfrageschlüssels entschlüsselt, bevor er einem Hash-Algorithmus bereitgestellt wird, der das Hash-Ergebnis generiert. Wenn der Abfrageschlüssel nicht mit dem zum Verschlüsseln des Inhalts verwendeten Signaturschlüssel übereinstimmt, findet das Korrekturprogramm keine ununterbrochene Kette. Auch Kombinationen davon sind möglich. Beispielsweise kann der Inhalt der Blöcke unter Verwendung des Signaturschlüssels verschlüsselt werden und der verschlüsselte Inhalt kann mit dem Signaturschlüssel als Eingabe für den Hash-Algorithmus kombiniert werden. Als weiteres Beispiel kann das Hash-Ergebnis aus einer Kombination des Signaturschlüssels und des Inhalts eines Blocks generiert werden, und der Signaturschlüssel kann verwendet werden, um den Inhalt des Blocks zu verschlüsseln. Implementierungen umfassen andere ähnliche Verwendungen des Signaturschlüssels beim Generieren der Identitätskette. Signaturschlüssel werden nicht als Teil des verkettbaren Identitätsgraphen 131 oder der Graphzugriffsdatensätze 135 gespeichert, was die Sicherheit des Verifizierungsprozesses erhöht.
Jede Identitätskette endet mit einem letzten Block, der eine Identifizierung der Kette unter Verwendung einiger Suchfelder ermöglicht. Die Suchfelder werden als Schlüsseleigenschaften der Entität bezeichnet. Schlüsseleigenschaften müssen nicht (können aber) eine Entität eindeutig identifizieren. Schlüsseleigenschaften reduzieren die Anzahl potenzieller Ketten, die als Antwort auf eine Abfrage untersucht werden müssen, erheblich. Beispiele für Schlüsseleigenschaften sind Vor- und Nachname, Geburtsdatum, Adresse, Lizenznummer, Sozialversicherungsnummer, Kontonummer etc. Der letzte Block wird auch als Diagrammzugriffsdatensatz bezeichnet. Der Graphzugriffsdatensatz kann ein ähnliches Format wie andere Blöcke in der Identitätskette aufweisen, z. B. wie der in 2 dargestellte Graphzugriffsdatensatz 135'. Der Graphzugriffsdatensatz 135' wird als ein Block in dem verkettbaren Identitätsgraphen 131 gespeichert. Bei solchen Implementierungen werden die Suchfelder (Schlüsseleigenschaften) möglicherweise nicht verschlüsselt, selbst wenn die verbleibenden Blöcke in der Kette verschlüsselten Inhalt aufweisen. Dies verbessert die Abfrageantwortzeit. Bei einigen Implementierungen kann der letzte Block ein Datensatz in einer Tabelle sein, wie etwa die in 2 veranschaulichten Graphzugriffsdatensätze 135". Eine Tabelle verbessert die Abfrageantwortzeit weiter, da die Suchfelder indiziert werden können, sodass ein als Antworter Gr Graphzugriffsdatensatz 135" schnell lokalisiert bzw. gefunden wird. Jeder Graphzugriffsdatensatz enthält ein Hash-Ergebnis, z. B. Hash 265. Der Hash 265 wird aus der Eingabe des vorletzten Blocks in der Kette generiert. So wird beispielsweise <hash8> aus <Proof Detail3> und <hash7> und optional einem Signaturschlüssel generiert.
Obwohl sie als letzter Block in der Kette angesehen werden, unterscheiden sich die Graphzugriffsdatensätze 135 von den anderen Blöcken dadurch, dass die Graphzugriffsdatensätze 135 der letzte Block in der Kette bleiben. Mit anderen Worten, wenn ein Block zu der Kette hinzugefügt wird, wird der Block nach dem vorletzten Block in der Kette hinzugefügt und nimmt als sein Hash-Ergebnis das Hash-Ergebnis auf, das in dem Graphzugriffsdatensatz gespeichert ist. Der Graphzugriffsdatensatz erhält bzw. empfängt einen neuen Hash, der aus dem eingefügten Block generiert wird, um seinen aktuellen Hash zu ersetzen. Wenn also beispielsweise ein neuer Block in die Identitätskette von Susan Jones eingefügt wird, nimmt der neue Block <hash8> in seinen Inhalt auf und der Hash 265 von Susan Jones' Graphzugriffsdatensatz wird mit einem neuen Hash-Ergebnis aktualisiert, z. B. <hash9>, generiert aus dem Inhalt des neuen Knotens. Bei einigen Implementierungen erfolgt die Aktualisierung durch Löschen des alten Graphzugriffsdatensatzes und Einfügen eines neuen Graphzugriffsdatensatzes. Wenn ein neuer Block von einem anderen Block in der Kette abzweigt, hat die zweite Kette natürlich ihren eigenen letzten Block.
Die in 2 dargestellten Graphzugriffsdatensätze 135" weisen drei Schlüsseleigenschaften auf: Suchfeld 250 (Nachname), Suchfeld 255 (Vorname) und Suchfeld 260 (Geburtsjahr). Dies sind jedoch nur Beispiele, und Implementierungen können weniger Suchfelder, zusätzliche Suchfelder oder andere Suchfelder enthalten, je nach Konfiguration und Präferenzen der vertrauenswürdigen Organisation. Ein Verweis auf ein Feld, wie er hier verwendet wird, bezieht sich je nach Kontext entweder auf den Feldnamen, den Feldwert oder beides. Beispielsweise kann eine Abfrage ein Suchfeld als Parameter aufweisen. Es versteht sich, dass das Feld einen bestimmten Datentyp darstellt (z. B. den Feldnamen) und einen Wert aufweist, sodass sich die Bezugnahme auf das Suchfeld auf den Datentyp und seinen Wert bezieht. Gleichermaßen kann ein Block in einer Kette ein oder mehrere Felder in der Nutzlast enthalten; der Block kann jedoch nur den Wert des Felds speichern. Bei einigen Implementierungen kann der Feldname (Typ) impliziert werden. Bei einigen Implementierungen kann der Feldname basierend auf der Position des Felds innerhalb des Inhalts bestimmt werden, zum Beispiel der Reihenfolge in einer mit Komma getrennten Liste oder den Byte-Positionen. Bei einigen Implementierungen kann der Feldname mit dem Wert gepaart werden.
3 veranschaulicht ein Flussdiagramm eines exemplarischen Prozesses 300 zum Generieren einer Identitätskette für eine Entität gemäß einer Implementierung. Der Prozess 300 kann von einer vertrauenswürdigen Organisation in Verbindung mit einem Identitätsnachweisprozess eingesetzt werden. Der Prozess 300 kann zumindest teilweise von einem System, wie z. B. dem Nachweis-Host 110a von 1, durchgeführt werden. Der Prozess 300 generiert eine Identitätskette für die geprüfte Entität aus Datenelementen in Bezug auf die Identitätsprüfung und aus einem Signaturschlüssel, der von dem Verwalter der Entität ausgewählt und von diesem erhalten wird (z. B. die Entität, wenn die Entität eine Person ist, oder eine Person, der die Entität gehört). Der Prozess 300 kann einen Identitätsnachweisprozess umfassen, der durch die Schritte 305 bis 315 dargestellt wird. Bei einigen Implementierungen kann ein Teil dieser Schritte von einem Vertreter der vertrauenswürdigen Organisation, z. B. von einem Angestellten, durchgeführt werden.
Der Prozess 300 kann mit dem Empfangen von Identitätsfaktoren für die Entität (305) beginnen. Identitätsfaktoren können beliebige Datenelemente sein, die die Identität der Entität gegenüber der vertrauenswürdigen Organisation herstellen. Identitätsmerkmale können beispielsweise eine Geburtsurkunde, eine Lizenz, eine Heiratsurkunde, einen Reisepass, ein Poststück mit einer Adresse, einen Titel, eine Urkunde, einen Sozialversicherungsausweis, einen Herkunftsnachweis, ein Gutachten, einen biometrischen Faktor (Iris, Stimme, Fingerabdruck, Gesichtsabdruck) etc. umfassen. Bei einigen Implementierungen können die Identitätsfaktoren z. B. durch den Vertreter der vertrauenswürdigen Organisation oder durch einen automatisierten Prozess verifiziert werden (310). Wenn die Verifizierung nicht erfolgreich ist (315, Nein), hat die Entität den Identitätsnachweisprozess nicht bestanden und es wird keine Identitätskette für die Entität generiert. Wenn die Verifizierung erfolgreich ist (315, Ja), ist der Identitätsnachweisprozess erfolgreich. Wenn die Identitätsfaktoren nicht bereits in einem für das System zugänglichen Format bereitgestellt werden, können sie eingegeben oder anderweitig dem System zur Verfügung gestellt werden, wenn die Verifizierung erfolgreich ist. Als Antwort auf einen erfolgreichen Identitätsnachweisprozess kann das System Genesis-Knotendaten erhalten und einen Genesis-Knoten generieren (320). Bei einigen Implementierungen erfassen die Genesis-Knotendaten einige physische Eigenschaften der Entität. Bei einigen Implementierungen können die Genesis-Knotendaten digitale Identifikationsinformationen wie einen digitalen Schlüssel, eine IP-Adresse etc. enthalten. Der Genesis-Knoten kann auch unterstützende Datenelemente wie ein Logo (2D oder 3D), einen Domänennamen etc. enthalten. Das System kann auch einen Signaturschlüssel vom Verwalter der Entität erhalten (325). Der Signaturschlüssel wird vom Verwalter der Entität ausgewählt. Bei einigen Implementierungen kann der Signaturschlüssel Größen- oder Formatanforderungen aufweisen, die von der vertrauenswürdigen Organisation festgelegt werden. Außerhalb der Anforderungen, die von einer bestimmten vertrauenswürdigen Organisation festgelegt werden, gibt es keine Beschränkungen, was ein Signaturschlüssel sein darf. Bei einigen Implementierungen wird der Signaturschlüssel erhalten, bevor der Genesis-Knoten generiert wird. Wenn zum Beispiel der Signaturschlüssel verwendet wird, um die Genesis-Daten zu verschlüsseln, kann der Signaturschlüssel vor dem Generieren des Genesis-Knotens erhalten werden.
Der Signaturschlüssel wird beim Generieren zusätzlicher Identitätsknoten in der Identitätskette verwendet. Die Anzahl der Knoten und die Nutzlast der verschiedenen Knoten sind Implementierungsdetails, die von der vertrauenswürdigen Organisation festgelegt werden können. Somit sind offenbarte Implementierungen nicht von irgendeiner bestimmten Kettenlänge oder Nutzlastdaten abhängig. Das System kann Knoten generieren, die jeweils als Inhalt aufweisen: Nutzlastdaten und einen aus Eingaben generierten Hash, der den Inhalt des vorherigen Knotens enthält (330, 330'). Bei einigen Implementierungen enthält die zum Generieren des Hash verwendete Eingabe den Inhalt des vorherigen Knotens und den Signaturschlüssel (330). Bei einigen Implementierungen generiert das System den Hash und verschlüsselt dann den Inhalt des Knotens unter Verwendung des Signaturschlüssels als Verschlüsselungsschlüssel (330'). Bei einigen Implementierungen kann das System den Signaturschlüssel mit dem Inhalt kombinieren und diesen als Eingabe für die Hash-Funktion verwenden und den Inhalt eines Knotens unter Verwendung des Signaturschlüssels verschlüsseln. Das System speichert die Knoten in einem verkettbaren Graphen. Als letzter Knoten in der Kette generiert das System einen Graphzugriffsdatensatz (335). Der Graphzugriffsdatensatz enthält ein Suchfeld (oder Suchfelder), oder mit anderen Worten eine Schlüsseleigenschaft (oder Schlüsseleigenschaften) für die Entität. Diese Felder können in Nutzlastdaten in einem oder mehreren Knoten enthalten sein. Diese Felder können speziell für den Graphzugriffsdatensatz erhalten worden sein. Der Graphzugriffsdatensatz enthält auch ein Hash-Ergebnis des letzten in der Kette generierten Knotens, z. B. als Teil von 330, 330' oder einer Kombination davon. Der Hash wird auf eine Weise generiert, die ähnlich derjenigen ist, die zum Generieren der Knoten in der Kette verwendet wird. Der Prozess 300 endet dann.
4 veranschaulicht ein Flussdiagramm eines exemplarischen Prozesses 400 zum Verwenden einer Identitätskette als Identifizierungsnachweis gemäß einer Implementierung. Der Prozess 400 ist ein Beispiel für einen Abfrageprozess, der von einem Client oder als erster Schritt bei der vertrauenswürdigen Organisation initiiert werden kann. Der Prozess 400 kann von einem Nachweis-Host, wie etwa dem Nachweis-Host 110a von 1, durchgeführt werden. Der Prozess 400 nimmt Abfrageparameter als Eingabe und stellt als Antwort eine Angabe darüber bereit, ob eine Identitätskette unter Verwendung der Abfrageparameter lokalisiert wurde. Bei einigen Implementierungen kann die Antwort auch Datenelemente enthalten, die aus der Nutzlast der Knoten in der Identitätskette erhalten werden.
Der Prozess 400 kann als Antwort auf das Empfangen von Abfrageparametern (405) beginnen. Die Abfrageparameter können ein oder mehrere Suchfelder spezifizieren. Die Felder können von der vertrauenswürdigen Organisation über eine spezifische API gesteuert werden. Beispielsweise kann die vertrauenswürdige Organisation nur bestimmte Felder für den Anfragenden zur Bereitstellung als Parameter verfügbar machen. Bei einigen Implementierungen entsprechen die Felder den Suchfeldern, die in den Graphzugriffsdatensätzen verfügbar sind. Bei einigen Implementierungen können die Felder zusätzliche Felder enthalten, z. B. zum Anfordern bestimmter Datenelemente, die in der Nutzlast der Knoten in der Kette verfügbar sind. Die in den Abfrageparametern enthaltenen Felder können kollektiv als Schlüsseleigenschaften bezeichnet werden. Zusätzlich zu den Schlüsseleigenschaften enthalten die Abfrageparameter einen Abfrageschlüssel. Der Abfrageschlüssel entspricht dem Signaturschlüssel. Der Abfrageschlüssel wird verwendet, um eine Kette von einem Graphzugriffsdatensatz (oder Datensätzen) zu einem Genesis-Knoten zu durchlaufen. Wenn ein Genesis-Knoten von einem Graphzugriffsdatensatz unter Verwendung des Abfrageschlüssels nicht erreicht wird, resultiert dies in einer nicht erfolgreichen Verifizierungsantwort.
Dementsprechend verwendet das System die Suchfelder, um übereinstimmende Graphzugriffsdatensätze zu identifizieren (410). Ein Graphzugriffsdatensatz ist ein übereinstimmender Datensatz, wenn das/die Suchfeld(er) im Graphzugriffsdatensatz mit dem/den in den Abfrageparametern bereitgestellten Feld(ern) übereinstimmen. Wenn keine übereinstimmenden Graphzugriffsdatensätze gefunden werden (415, Nein), sendet das System eine negative oder fehlgeschlagene Verifizierungsantwort (420) und der Prozess 400 endet. Wenn zumindest ein übereinstimmender Graphzugriffsdatensatz identifiziert wird (415, Ja), erhält das System den Abfrageschlüssel oder mit anderen Worten - einen Signaturschlüssel. Dieser Schlüssel wird von dem Verwalter der zu verifizierenden Entität bereitgestellt. Bei einigen Implementierungen kann der Abfrageschlüssel als Teil von Schritt 405 bereitgestellt worden sein. Das System verwendet den Abfrageschlüssel, um die Knoten in dem verkettbaren Graphen zu durchlaufen, um zu bestimmen, ob eine vollständige Kette (z. B. von dem Graphzugriffsdatensatz zu einem Genesis-Knoten) existiert. Dies ist ein iterativer Prozess, der durch die Schritte 430 bis 460 dargestellt wird und mit dem letzten Knoten (dem Graphzugriffsdatensatz) als dem „aktuellen“ Knoten beginnt. Der aktuelle Knoten weist ein Hash-Ergebnis auf und das System versucht, dieses Hash-Ergebnis mit einem abzugleichen, das für einen Knoten in dem Graphen berechnet wurde. Dieser Prozess umfasst die Verwendung des Schlüssels entweder als zusätzliche Eingabe für die Hash-Funktion oder als Entschlüsselungsschlüssel oder als beides, abhängig von der Implementierung und wie hierin beschrieben. Wenn kein übereinstimmender Knoten lokalisiert wird (435, Nein), dann konnte das System keine vollständige Kette für die Kombination aus dem Abfrageschlüssel und dem Graphzugriffsdatensatz finden. Wenn es keine anderen möglichen übereinstimmenden Graphzugriffsdatensätze gibt (445, Nein), kann das System eine negative Verifizierungsantwort senden (420) und der Prozess 400 endet für diese Entität. Wenn es zumindest einen zusätzlichen übereinstimmenden Graphzugriffsdatensatz gibt (445, Ja), fährt der Prozess 400 fort, diesen Graphzugriffsdatensatz als den „aktuellen Knoten“ zu verwenden, und das System versucht, eine Kette von diesem Knoten zu einem Genesis-Knoten unter Verwendung des Abfrageschlüssels zu lokalisieren. Bei einigen Implementierungen können Daten mit der Abfrage bereitgestellt werden und das System weist die Daten als Antwort auf eine nicht erfolgreiche Verifizierungsanfrage oder mit anderen Worten eine negative Verifizierungsantwort zurück. Zum Beispiel können die Daten Anweisungen sein, z. B. für eine Drohne oder eine andere entfernte Vorrichtung, und die entfernte Vorrichtung lehnt die Anweisungen als Antwort auf eine erfolglose Verifizierungsanfrage ab oder handelt nicht. Als weiteres Beispiel können die Daten Ablesungen bzw. Messwerte sein, die von Sensoren aufgenommen werden, und die Daten können als Antwort auf eine erfolglose Verifizierungsanfrage zurückgewiesen und nicht in die Analyse aufgenommen werden.
Wenn ein passender Knoten gefunden wird (435, Ja), kann das System einige oder alle Nutzdaten des Knotens extrahieren (440). Die Nutzlast kann beim Generieren eines Suchergebnisses verwendet werden, wenn ein Genesis-Knoten erreicht wird. Schritt 440 ist optional. Bei einigen Implementierungen extrahiert das System die Nutzlastdaten nur von einigen Knoten. Bei einigen Implementierungen kann es von den in den Abfrageparametern identifizierten Suchfeldern abhängen, ob Nutzlastdaten extrahiert werden oder nicht, und aus welchen Knoten. Wenn der Knoten nicht der Genesis-Knoten ist (445, Nein), verwendet das System den Knoten als aktuellen Knoten und beginnt eine Suche nach dem vorherigen Knoten, z. B. bei 430. Wenn der Knoten ein Genesis-Knoten ist (455, Ja), hat das System erfolgreich eine vollständige Kette identifiziert und sendet eine positive Verifizierungsantwort (460). Bei einigen Implementierungen wird als Antwort nur eine Angabe des Erfolgs bereitgestellt. Bei einigen Implementierungen werden ein oder mehrere Datenelemente bereitgestellt, die aus der Nutzlast von einem oder mehreren Knoten in der Kette erhalten werden. Bei einigen Implementierungen wird die Nutzlast des Genesis-Knotens mit der erfolgreichen Antwort bereitgestellt. Die zusätzlichen Daten können vom Anforderer verwendet werden, um zusätzliche Überprüfungen für die Entität durchzuführen. Wenn zum Beispiel die Genesis-Daten ein Bild der Entität sind, kann der anfordernde Prozess das Bild beim Client anzeigen, so dass ein Benutzer verifizieren kann, dass die präsentierte Entität mit der Entität in dem Bild übereinstimmt. Als weiteres Beispiel kann ein Alter in die Antwort aufgenommen werden und der anfordernde Prozess kann verifizieren, ob die präsentierte Entität eine gewisse Altersqualifikation erfüllt (z. B. über 21 Jahre alt ist und Alkohol kaufen darf). Den Daten aus der Nutzlast kann der Abfrageanforderer vertrauen, da sie unveränderlich sind; d.h. schwer zu modifizieren sind und mit hoher Sicherheit genau sind. So könnte beispielsweise ein Verkäufer im Geschäft leicht feststellen, ob eine im Geschäft vorgelegte Lizenz gefälscht ist. Bei einigen Implementierungen können Daten mit der Abfrage bereitgestellt werden und das System akzeptiert die Daten als Antwort auf eine erfolgreiche Verifizierungsanfrage. Beispielsweise können die Daten Anweisungen sein, z. B. für eine Drohne oder eine andere entfernte Vorrichtung, und die entfernte Vorrichtung reagiert auf die Anweisungen oder führt sie als Antwort auf eine erfolgreiche Verifizierungsanfrage aus. Als weiteres Beispiel können die Daten Ablesungen bzw. Messwerte sein, die von Sensoren aufgenommen werden, und die Daten können als Antwort auf eine erfolgreiche Verifizierungsanfrage zur Analyse akzeptiert werden.
5 veranschaulicht ein Flussdiagramm eines exemplarischen Prozesses 500 zum Hinzufügen von Knoten (Blöcken) zu einer Kette gemäß einer Implementierung. Der Prozess 500 kann im Anschluss an das Generieren der ursprünglichen Kette durch ein System, wie z. B. den Nachweis-Host 110a von 1, durchgeführt werden. Der Prozess 500 kann es dem System ermöglichen, zusätzliche Knoten in die Kette einzufügen. Eine vertrauenswürdige Entität kann dies tun, um eine zusätzliche Möglichkeit zum Verifizieren der Entität hinzuzufügen, z. B. einem Miteigentümer eine Kette zu geben, die von dem bestehenden Genesis-Knoten abzweigt, oder einer Person, die ihren rechtlichen Namen geändert hat, einen zusätzlichen Zweig zu geben. Ein anderer Wirkungskreis kann darin bestehen, einer Person einen zweiten Führerschein hinzuzufügen, wie z. B. eine Kraftfahrzeugabteilung, die einer Person, die einen herkömmlichen Führerschein besitzt, einen Motorradführerschein hinzufügt. Der Prozess 500 kann auch verwendet werden, um Knoten hinzuzufügen, die bestimmte Aktivitäten im Zusammenhang mit der Entität dokumentieren. Der Prozess 500 kann somit so verstanden werden, dass er das Hinzufügen eines einzelnen Knotens nach dem vorletzten Knoten in der Kette ermöglicht, einen zweiten Graphzugriffsdatensatz für die Kette einfügt oder eine separate Kette von dem Genesis-Knoten einfügt etc.
Der Prozess 500 beginnt mit dem Verifizieren, dass die Kette intakt ist 505. Mit anderen Worten, bevor irgendwelche Knoten zu einer Kette hinzugefügt werden, kann der Prozess 500 einen Prozess wie etwa den Prozess 400 von 4 verwenden, um die Identität der Entität zu verifizieren, an der eine Änderung vorgenommen wird. Abhängig von der Aktivität, die das System veranlasst hat, den Prozess 500 aufzurufen, kann ein zweiter Identitätsnachweisprozess erfolgreich abgeschlossen worden sein. Andere Aktivitäten erfordern keinen vollständigen Identitätsnachweisprozess, können aber nach erfolgreicher Verifizierung für die Entität initiiert werden. Für die Aktivität werden ein neuer Knoten oder neue Knoten generiert (510). Das Generieren der neuen Knoten kann denselben Signaturschlüssel verwenden, der zum Verifizieren der Kette verwendet wurde, z. B. in Schritt 505. Das Generieren der neuen Knoten kann einen neuen Signaturschlüssel verwenden, und das Generieren der neuen Knoten kann das Erhalten des neuen Signaturschlüssels umfassen. Die neuen Knoten werden in die Kette eingefügt (515). Wenn ein neuer Signaturschlüssel verwendet wird, können die neuen Knoten von dem Genesis-Knoten weg eingefügt werden, z. B. als eine neue Verzweigung von dem Genesis-Knoten. Wenn derselbe Signaturschlüssel verwendet wird, können die neuen Knoten so eingefügt werden, dass sie von jedem beliebigen Knoten in der Kette abzweigen. Bei einigen Implementierungen erhält jede Einfügung einen neuen Graphzugriffsdatensatz, so dass jede Einfügung eine neue Verzweigung generiert. Bei einigen Implementierungen kann der neue Knoten (oder können die neuen Knoten) von jedem der Knoten in der Kette eingefügt werden. Bei einigen Implementierungen wird der neue Knoten (oder werden die neuen Knoten) in die Kette eingefügt, z. B. vor dem Graphzugriffsdatensatz. Gegebenenfalls aktualisiert das System einen Graphzugriffsdatensatz oder fügt diesen hinzu (520). Der Prozess 500 endet dann.
Ein Arbeitsbeispiel wird nun beschrieben. Dieses Beispiel wird bereitgestellt, um das Verständnis dieser Offenbarung zu unterstützen, und Implementierungen sind nicht auf das beschriebene spezifische Szenario beschränkt, da die Verfahren und Techniken an andere Arten von Umgebungen angepasst werden können, wie oben beschrieben. Implementierungen umfassen somit Anpassungen der zugrunde liegenden Technologie und Techniken an andere Branchen.
Eine Akkreditierungsstelle, wie z. B. eine medizinische Zulassungsbehörde, ist ein Beispiel einer vertrauenswürdigen Organisation. Eine Zulassungsbehörde unterliegt Vorschriften, die sicherstellen, dass zugelassene Ärzte ordnungsgemäß überprüft und identifiziert werden. Zum Beispiel kann ein Arzt, um eine medizinische Approbation zu erhalten, mehrere Ausweisformen und etwaige zusätzliche Verifizierungsdokumente einreichen, wie Zeugnisse der medizinischen Hochschule, einen Wesens- und Fitnessantrag, eine Kreditauskunft, etc. Nachdem die medizinische Zulassungsbehörde alle Antragsunterlagen verifiziert hat, kann die medizinische Zulassungsbehörde eine Identitätskette für den Arzt generieren. Beispielsweise kann die Behörde einen 2- oder 3-dimensionalen Scan des Kopfes des Arztes erstellen. Der Scan kann als Genesis-Daten in dem Genesis-Block der Identitätskette verwendet werden. Der Arzt kann einen Signaturschlüssel bereitstellen, wie z. B. die erste Zeile des Lieblingsromans des Arztes. Das System verwendet den Signaturschlüssel beim Generieren eines zweiten Knotens in der Kette. Der zweite Knoten kann Informationen über die im Identitätsnachweisverfahren verwendeten Identifikationsformen enthalten, wie z. B. ein Bild einer Geburtsurkunde oder die Informationen aus der Geburtsurkunde. Der Signaturschlüssel kann beim Generieren eines als Teil des Inhalts des zweiten Knotens gespeicherten Hash verwendet werden. Beispielsweise kann der Signaturschlüssel mit dem Scan kombiniert und als Eingabe für eine Hash-Funktion bereitgestellt werden. Das Ergebnis der Hash-Funktion wird Teil des Inhalts des zweiten Knotens. Bei einigen Implementierungen werden zusätzliche Knoten generiert. Dann wird ein Graphzugriffsdatensatz erstellt. Der Graphzugriffsdatensatz kann den Namen des Arztes und/oder eine für den Arzt ausgestellte Arztkennung enthalten. Der Graphzugriffsdatensatz enthält auch einen Hash, der aus dem Inhalt des zweiten Knotens und dem Signaturschlüssel generiert wird. Dieser Hash wird dann mit dem Graphzugriffsdatensatz gespeichert. Alternativ oder zusätzlich kann der Signaturschlüssel verwendet werden, um den Inhalt jedes Knotens in der Kette zu verschlüsseln, bevor er gespeichert wird. Bei solchen Implementierungen wird der Signaturschlüssel zur Abfragezeit bereitgestellt, um den Knoteninhalt zu entschlüsseln, bevor er der Hash-Funktion bereitgestellt wird.
Die medizinische Zulassungsbehörde kann dann Verifizierungsdienste für Kunden anbieten. So kann beispielsweise ein Krankenhaus die Verifizierungsdienste im Rahmen eines Login-Vorgangs nutzen. Um beispielsweise auf die elektronischen Patientenakten im Krankenhaus zuzugreifen, kann es erforderlich sein, dass der Arzt ein Anmeldeverfahren verwendet, das als Eingabe einen Abfrageschlüssel und den Namen des Arztes verwendet. Diese Abfrageparameter können an den Server der Zulassungsbehörde übertragen werden, wo die Parameter verwendet werden, um zu bestimmen, ob eine Identitätskette existiert. Wenn eine gefunden wird, können die Server der Zulassungsbehörde die Scandaten von dem Genesis-Knoten der Kette bereitstellen. Bei einigen Implementierungen kann das Krankenhaus den Kopf des Arztes scannen und bestimmen, ob die Scans übereinstimmen. Wenn die Scans übereinstimmen, gewährt das Krankenhaus dem Arzt Zugang.
Bei den oben beschriebenen Konfigurationen kann sich ein Computerprozessor auf einen oder mehrere Computerprozessoren in einer oder mehreren Vorrichtungen oder beliebige Kombinationen von einem oder mehreren Computerprozessoren und/oder Geräten beziehen. Ein Aspekt einer Ausführungsform bezieht sich darauf, ein oder mehrere Geräte und/oder Computerprozessoren zu veranlassen und/oder zu konfigurieren, die beschriebenen Operationen auszuführen. Die erzeugten Ergebnisse können an eine Ausgabevorrichtung ausgegeben werden, z. B. auf dem Display angezeigt, über Lautsprecher abgespielt werden etc. Ein Gerät oder eine Vorrichtung bezieht sich auf eine physische Maschine, die Operationen ausführt, z. B. einen Computer (physische Computerhardware oder -maschinerie), die Anweisungen implementieren oder ausführen, beispielsweise Anweisungen mittels Software ausführen, bei der es sich um Code handelt, der von Computerhardware ausgeführt wird, einschließlich eines programmierbaren Chips (Chipsatz, Computerprozessor, elektronische Komponente), und/oder Anweisungen mittels Computerhardware implementieren (z. B. in Schaltkreisen, elektronischen Komponenten in integrierten Schaltkreisen etc.) - kollektiv als Hardwareprozessor(en) bezeichnet, um die beschriebenen Funktionen oder Operationen zu erreichen. Die Funktionen der beschriebenen Ausführungsformen können in jeder Art von Vorrichtung implementiert werden, die Befehle oder Code ausführen kann.
Insbesondere ein Programmieren oder Konfigurieren oder Bewirken, dass ein Gerät oder eine Vorrichtung, beispielsweise ein Computer, die beschriebenen Funktionen von Ausführungsformen ausführt, erzeugt eine neue Maschine, bei der im Fall eines Computers ein Universalcomputer tatsächlich zu einem Spezialcomputer wird, sobald er programmiert oder konfiguriert oder veranlasst wird, bestimmte Funktionen der Ausführungsformen gemäß Anweisungen von Programmsoftware auszuführen. Gemäß einem Aspekt einer Ausführungsform bezieht sich das Konfigurieren eines Geräts, einer Vorrichtung oder eines Computerprozessors auf ein solches Gerät, eine solche Vorrichtung oder einen solchen Computerprozessor, der durch Software programmiert oder gesteuert bzw. geregelt wird, um die beschriebenen Funktionen auszuführen.
Ein Programm/eine Software, das bzw. die die Ausführungsformen implementiert, kann auf einem computerlesbaren Medium aufgezeichnet sein, z. B. einem nicht flüchtigen oder persistenten computerlesbaren Medium. Beispiele der nicht flüchtigen computerlesbaren Medien umfassen eine magnetische Aufzeichnungsvorrichtung, eine optische Platte, eine magneto-optische Platte und/oder flüchtige und/oder nicht flüchtige Halbleiterspeicher (zum Beispiel RAM, ROM etc.). Beispiele der magnetischen Aufzeichnungsvorrichtung umfassen eine Festplattenvorrichtung (HDD), eine flexible Platte (FD). Beispiele der optischen Platte umfassen eine DVD (Digital Versatile Disc), DVD-ROM, DVD-RAM (DVD-Random Access Memory), BD (Blu-ray Disk), eine CD-ROM (Compact Disc - Read Only Memory), und eine CD-R (beschreibbar)/RW. Das Programm/die Software, das bzw. die die Ausführungsformen implementiert, kann über einen Übertragungskommunikationspfad übertragen werden, z. B. ein drahtgebundenes und/oder ein drahtloses Netzwerk, das über Hardware implementiert ist. Ein Beispiel für Kommunikationsmedien, über die das Programm/die Software gesendet werden kann, umfasst beispielsweise ein Trägerwellensignal.
Die vielen Merkmale und Vorteile der Ausführungsformen gehen aus der detaillierten Beschreibung hervor, und somit ist es durch die beigefügten Ansprüche beabsichtigt, alle solche Merkmale und Vorteile der Ausführungsformen abdecken, die in deren wahre Natur und Umfang fallen. Da Fachleuten zahlreiche Modifikationen und Änderungen leicht ersichtlich sind, ist es ferner nicht erwünscht, die erfinderischen Ausführungsformen auf die exakte dargestellte und beschriebene Konstruktion und Funktionsweise zu beschränken, und dementsprechend kann auf alle geeigneten Modifikationen und Äquivalente zurückgegriffen werden, die in deren Schutzbereich fallen.
Fachleute werden erkennen, dass die vorliegenden Lehren für eine Vielzahl von Modifikationen und/oder Verbesserungen zugänglich sind. Obwohl beispielsweise die Implementierung verschiedener oben beschriebener Komponenten in einer Hardwarevorrichtung verkörpert sein kann, kann sie auch als reine Softwarelösung implementiert werden - z. B. eine Installation auf einem vorhandenen Server. Außerdem können die Nachweisanwendung und ihre hier offenbarten Komponenten als Firmware, Firmware/Software-Kombination, Firmware/Hardware-Kombination oder Hardware/Firmware/Software-Kombination implementiert werden.
Während das Vorhergehende beschrieben hat, was als die beste Art und/oder andere Beispiele angesehen wird, versteht es sich, dass verschiedene Modifikationen daran vorgenommen werden können und dass der hierin offenbarte Gegenstand in verschiedenen Formen und Beispielen implementiert werden kann, und dass die Lehren in zahlreichen Anwendungen angewendet werden können, von denen hier nur einige beschrieben wurden. Durch die folgenden Ansprüche sollen alle Anwendungen, Modifikationen und Variationen beansprucht werden, die in den wahren Schutzbereich der vorliegenden Lehren fallen.
In einem allgemeinen Aspekt enthält ein System zumindest einen Prozessor, einen Identitätsgraphen, der Identitätsblöcke speichert, wobei die Identitätsblöcke Entstehungsblöcke bzw. Genesisblöcke und Graphzugriffsdatensätze enthalten, und einen Speicher, der Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen, Operationen durchzuführen. Die Operationen beinhalten ein Empfangen zumindest einer Eigenschaft, die eine Entität identifiziert, und eines Abfrageschlüssels, wobei der Abfrageschlüssel Daten sind, die ursprünglich von einem angeblichen Verwalter der Entität ausgewählt werden. Die Operationen beinhalten auch ein Identifizieren einer möglichen Übereinstimmung für die Eigenschaft aus Graphzugriffsdatensätzen, wobei die mögliche Übereinstimmung ein verknüpftes Hash-Ergebnis aufweist, wobei die mögliche Übereinstimmung und das verknüpfte Hash-Ergebnis als ein aktueller Knoten in einer Kette betrachtet werden. Die Operationen beinhalten auch ein Prüfen bzw. Verifizieren einer vollständigen Kette vom aktuellen Knoten bis zu einem Entstehungsknoten bzw. Genesis-Knoten durch Wiederholen von: Identifizieren eines Knotens in dem Identitätsgraphen, der Inhalt aufweist, der unter Verwendung des Abfrageschlüssels zum Generieren eines Hash-Ergebnisses ein Hash-Ergebnis aufweist, das mit dem verknüpften Hashergebnis des aktuellen Knotens übereinstimmt, wobei ein Scheitern beim Identifizieren eines Knotens das Wiederholen stoppt und wobei ein Bestimmen, dass der Knoten ein Genesis-Knoten ist, das Wiederholen stoppt und den Knoten zum aktuellen Knoten macht, wobei der Inhalt des Knotens ein verknüpftes Hash-Ergebnis enthält. Die Operationen beinhalten auch ein Generieren einer Antwort, die eine erfolgreiche Prüf- bzw. Verifizierungsanfrage angibt, als Antwort auf ein Lokalisieren des Genesis-Knotens, und ein Generieren einer Antwort, die eine erfolglose Verifizierungsanfrage angibt, als Antwort darauf, dass der Genesis-Knoten nicht lokalisiert bzw. gefunden wird. Bei einigen Implementierungen ist das System eine entfernte Vorrichtung, wie etwa eine ferngesteuerte Vorrichtung.
Gemäß einem Aspekt beinhaltet ein Verfahren ein Empfangen zumindest einer Eigenschaft, die eine Entität identifiziert, und eines Abfrageschlüssels, wobei der Abfrageschlüssel Daten sind, die ursprünglich von einem angeblichen Verwalter der Entität ausgewählt wurden, und ein Identifizieren einer möglichen Übereinstimmung für die Eigenschaft aus dem Graphzugriffsdatensätzen, wobei die mögliche Übereinstimmung ein verknüpftes Hash-Ergebnis aufweist, wobei die mögliche Übereinstimmung und das verknüpfte Hash-Ergebnis als ein aktueller Knoten in einer Kette angesehen werden. Das Verfahren beinhaltet auch ein Verifizieren einer vollständigen Kette vom aktuellen Knoten bis zu einem Entstehungsknoten bzw. Genesis-Knoten durch Wiederholen von: Identifizieren eines Knotens in einem Graphen, der Inhalt aufweist, der unter Verwendung des Abfrageschlüssels zum Generieren eines Hash-Ergebnisses ein Hash-Ergebnis aufweist, das mit dem verknüpften Hash-Ergebnis des aktuellen Knotens übereinstimmt, wobei ein Scheitern beim Identifizieren eines Knotens das Wiederholen stoppt und ein Bestimmen, dass der Knoten ein Genesis-Knoten ist, das Wiederholen stoppt und den Knoten zum aktuellen Knoten macht, wobei der Inhalt des Knotens ein verknüpftes Hash-Ergebnis enthält. Das Verfahren beinhaltet auch ein Generieren einer Antwort, die eine erfolgreiche Prüf- bzw. Verifizierungsanfrage angibt, als Antwort auf ein Lokalisieren des Genesis-Knotens, und ein Generieren einer Antwort, die eine erfolglose Verifizierungsanfrage angibt, als Antwort darauf, dass der Genesis-Knoten nicht lokalisiert bzw. gefunden wird.
Diese und andere Aspekte können eines oder mehrere der folgenden Merkmale beinhalten, allein oder in Kombination. Beispielsweise kann der Abfrageschlüssel eines von Ausdruck, Bild oder eine Kombination von Datenelementen sein, wobei der Abfrageschlüssel von dem angeblichen Verwalter als Teil eines Identitätsnachweisprozesses ausgewählt wird, der die Generierung des Genesis-Knotens initiiert hat. Als ein weiteres Beispiel kann das Verfahren für zumindest einen Knoten in der Kette auch ein Erhalten eines Datenelements aus dem Inhalt und ein Einbeziehen des Datenelements in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt, beinhalten. Als ein weiteres Beispiel kann das Verfahren auch ein Einbeziehen von Inhalt des Genesis-Knotens in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt, beinhalten. Bei einigen Implementierungen kann das Verfahren auch ein Entschlüsseln des Inhalts des Genesis-Knotens beinhalten, bevor der Inhalt in die Antwort aufgenommen wird. Bei einigen Implementierungen umfasst der Inhalt des Genesis-Knotens ein zweidimensionales Bild oder ein dreidimensionales Bild der Entität. Bei einer solchen Implementierung kann die Entität eine Person sein und der angebliche Verwalter ist die Person und der Inhalt des Genesis-Knotens ist ein biometrisches Bild, oder die Entität kann ein Gegenstand sein und der angebliche Verwalter ist eine Person.
Als ein weiteres Beispiel kann das Verfahren nach einer erfolgreichen Verifizierungsanfrage ein Generieren eines neuen Knotens in dem Graphen, wobei der neue Knoten Inhalt aufweist, der Datenelemente aus einer Aktivität, die nach der erfolgreichen Verifizierungsanfrage auftritt, und das Hash-Ergebnis enthält, das mit der möglichen Übereinstimmung der Eigenschaft verknüpft ist, die verwendet wird, um den Genesis-Knoten zu lokalisieren, ein Generieren eines neuen Hash-Ergebnisses unter Verwendung des neuen Knotens und des Abfrageschlüssels als Eingabe, und ein Aktualisieren des Hash-Ergebnisses der möglichen Übereinstimmung der Eigenschaft umfassen, die verwendet wird, um den Genesis-Knoten zu dem neuen Hash-Ergebnis zu lokalisieren. Als ein weiteres Beispiel kann die Entität eine entfernte Vorrichtung in einem Netzwerk sein und die entfernte Vorrichtung kann Daten mit der Eigenschaft und dem Abfrageschlüssel bereitstellen, und das Verfahren kann auch ein Akzeptieren der Daten als Antwort auf eine erfolgreiche Verifizierungsanfrage und ein Zurückweisen der Daten als Antwort auf eine erfolglose Verifizierungsanfrage umfassen. Als ein weiteres Beispiel kann das Verfahren von einer ferngesteuerten Vorrichtung durchgeführt werden und Anweisungen können mit der Eigenschaft und dem Abfrageschlüssel empfangen werden, und das Verfahren kann ferner ein Reagieren auf die Anweisungen als Antwort auf eine erfolgreiche Verifizierungsanfrage und ein Zurückweisen der Anweisungen als Antwort auf eine erfolglose Verifizierungsanfrage beinhalten. Als ein weiteres Beispiel kann das Verwenden des Abfrageschlüssels zum Generieren des Hash-Ergebnisses ein Hinzufügen des Abfrageschlüssels zu dem Inhalt des Knotens vor dem Generieren des Hash-Ergebnisses und/oder ein Entschlüsseln des Inhalts vor dem Generieren des Hash-Ergebnisses beinhalten.
Gemäß einem Aspekt beinhaltet ein Verfahren als Antwort auf einen erfolgreichen Identitätsnachweisprozess für eine Entität, die zumindest einen Identitätsfaktor enthält, ein Empfangen von Inhalt für einen Entstehungsknoten bzw. Genesis-Knoten in einer Identitätskette, wobei der Inhalt für den Genesis-Knoten Entstehungsdaten bzw. Genesis-Daten enthält, die eine eindeutige physische Eigenschaft der Entität erfassen. Das Verfahren beinhaltet auch ein Generieren eines Genesis-Knotens in einem Graphen, wobei der Genesis-Knoten Inhalt aufweist, der die Genesis-Daten enthält, ein Empfangen eines Signaturschlüssels von einem Verwalter der Entität, wobei der Verwalter den zumindest einen Identitätsfaktor bereitgestellt hat, ein Generieren eines ersten Hash-Ergebnisses unter Verwendung des Inhalts des Genesis-Knotens und des Signaturschlüssels als Eingabe, ein Generieren eines zweiten Knotens in der Identitätskette, wobei der zweite Knoten Inhalt aufweist, der eine Identifizierung des zumindest einen Identitätsfaktors und des ersten Hash-Ergebnisses beinhaltet, ein Generieren eines zweiten Hash-Ergebnisses unter Verwendung des Inhalts des zweiten Knotens und des Signaturschlüssels als Eingabe, und ein Speichern eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Schlüsseleigenschaft enthält, die verwendet wird, um die Entität als Antwort auf Verifizierungsanfragen zu lokalisieren. Knoten in dem Graphen und dem Graphzugriffsdatensatz können dann beim Antworten auf Verifizierungsanfragen verwendet werden.
Diese und andere Aspekte können eines oder mehrere der folgenden Merkmale umfassen, allein oder in Kombination. Beispielsweise kann das Verfahren auch ein Verschlüsseln der Genesis-Daten vor dem Generieren des Genesis-Knotens beinhalten, wobei der Genesis-Knoten die verschlüsselten Genesis-Daten speichert. Als ein weiteres Beispiel kann der Graphzugriffsdatensatz ein Knoten in dem Graphen und/oder ein Eintrag in einer Tabelle sein. Als ein weiteres Beispiel kann das Verwenden der Knoten in dem Graphen und des Graphzugriffsdatensatzes zum Antworten auf eine Verifizierungsanfrage ein Empfangen der Verifizierungsanfrage, die einen Abfrageschlüssel und eine Schlüsseleigenschaft enthält, ein Lokalisieren eines ersten Graphenzugriffsdatensatzes, der mit der Schlüsseleigenschaft übereinstimmt, und ein Bestimmen, ob eine Kette zu einem Genesis-Knoten existiert, unter Verwendung eines Hash-Ergebnisses in dem ersten Graphzugriffsdatensatz und dem Abfrageschlüssel beinhalten. Bei einigen Implementierungen kann das Verfahren als Antwort auf das Bestimmen, dass eine Kette zu einem Genesis-Knoten existiert, auch ein Generieren eines Aktivitätsknotens in dem Graphen, wobei der Aktivitätsknoten ein Hash-Ergebnis enthält, das mit dem ersten Graphenzugriffsdatensatz verknüpft ist, und Datenelemente enthält, die sich auf eine Aktivität für die Entität beziehen, ein Generieren eines dritten Hash-Ergebnisses durch Hashen des Aktivitätsknotens und des Abfrageschlüssels und ein Ersetzen des Hash-Ergebnisses in dem ersten Graphzugriffsdatensatz durch das dritte Hash-Ergebnis beinhalten. Bei einigen Implementierungen ist der Graphzugriffsdatensatz ein erster Graphzugriffsdatensatz und das Verfahren kann auch ein Speichern eines zweiten Graphzugriffsdatensatzes beinhalten, wobei der zweite Graphzugriffsdatensatz das zweite Hash-Ergebnis und eine Schlüsseleigenschaft enthält, die sich von der Schlüsseleigenschaft in dem ersten Graphzugriffsdatensatz unterscheidet. Bei einigen Implementierungen kann das Verfahren als Antwort auf das Bestimmen, dass eine Kette zu einem Genesis-Knoten existiert, auch ein Generieren eines Aktivitätsknotens in dem Graphen beinhalten, wobei der Aktivitätsknoten ein Hash-Ergebnis enthält, das mit dem ersten Graphenzugriffsdatensatz verknüpft ist, und Datenelemente enthält, die sich auf eine Aktivität für die Entität beziehen, ein Generieren eines dritten Hash-Ergebnisses durch Hashen des Aktivitätsknotens und des Abfrageschlüssels, und ein Hinzufügen eines zweiten Graphzugriffsdatensatzes beinhalten, wobei der zweite Graphzugriffsdatensatz das dritte Hash-Ergebnis aufweist.
Gemäß einem Aspekt enthält ein System zumindest einen Prozessor, einen Identitätsgraphen, der Identitätsblöcke speichert, wobei die Identitätsblöcke Genesis-Blöcke bzw. Entstehungsblöcke enthalten, und einen Speicher, der Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen Operationen durchzuführen. Die Operationen beinhalten ein Empfangen von Entstehungsdaten bzw. Genesis-Daten und eines Signaturschlüssels nach einem erfolgreichen Identitätsnachweisprozess für eine Person, wobei die Genesis-Daten eine physisches Eigenschaft der Person erfassen und der Signaturschlüssel durch die Person bereitgestellt wird, ein Generieren eines ersten Hash-Ergebnisses unter Verwendung der Genesis-Daten als Eingabe, ein Generieren eines Entstehungsblocks bzw. Genesis-Blocks in dem Identitätsgraphen, wobei der Genesis-Block die Genesis-Daten als Inhalt aufweist, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird, ein Generieren eines zweiten Hash-Ergebnisses unter Verwendung von Nutzlastdaten und dem ersten Hash-Ergebnis als Eingabe. Die Operationen können auch ein Generieren eines Identitätsblocks in dem Identitätsgraphen, wobei der Identitätsblock die Nutzlastdaten und das erste Hash-Ergebnis als Inhalt aufweist, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird, ein Generieren eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Sucheigenschaft für die Person, aber nicht den Signaturschlüssel, enthält, und ein Verwenden des Identitätsgraphen beim Antworten auf Prüf- bzw. Verifizierungsanfragen. Bei einigen Implementierungen ist der Graphzugriffsdatensatz ein Block, der in dem Identitätsgraphen gespeichert ist. Bei einigen Implementierungen können die Operationen ferner beinhalten: ein Empfangen von Aktivitätsdaten, eines Abfrageschlüssels und einer Abfrageeigenschaft für die Person, ein Bestimmen, ob eine Kette in dem Identitätsgraphen für die Person existiert, die den Abfrageschlüssel und die Abfrageeigenschaft verwendet, und ansprechend auf das Bestimmen, dass die Kette existiert: Generieren eines dritten Hash-Ergebnisses unter Verwendung der Aktivitätsdaten und des zweiten Hash-Ergebnisses als Eingabe, Generieren eines neuen Identitätsblocks in dem Identitätsgraphen, wobei der neue Identitätsblock die Aktivitätsdaten und das zweite Hash-Ergebnis als Inhalt aufweist, wobei der Inhalt des neuen Identitätsblocks unter Verwendung des Abfrageschlüssels verschlüsselt wird, und Aktualisieren des Graphzugriffsdatensatzes durch Ersetzen des zweiten Hash-Ergebnisses durch das dritte Hash-Ergebnis.
Gemäß einem allgemeinen Aspekt speichert ein nicht flüchtiges computerlesbares Medium Anweisungen, die, wenn sie von zumindest einem Prozessor ausgeführt werden, eine Rechenvorrichtung veranlassen, beliebige der hierin offenbarten Operationen oder Verfahren durchzuführen.
Gemäß einem allgemeinen Aspekt umfasst ein System zumindest einen Prozessor und einen Speicher, der Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, die Rechenvorrichtung veranlassen, beliebige der hierin offenbarten Operationen oder Verfahren durchzuführen.
Im Folgenden werden weitere Merkmale, Eigenschaften und Vorteile der vorliegenden Offenbarung anhand von Punkten beschrieben.

1. Verfahren, umfassend:
- ansprechend auf einen erfolgreichen Identitätsnachweisprozess für eine Entität, die zumindest einen Identitätsfaktor enthält, Empfangen von Genesis-Daten bzw. Entstehungsdaten, die eine eindeutige physische Eigenschaft der Entität erfassen;
- Generieren eines Genesis-Knotens bzw. Entstehungsknotens für eine Identitätskette in einem Graphen, wobei der Genesis-Knoten einen Inhalt aufweist, der die Genesis-Daten enthält;
- Empfangen eines Signaturschlüssels von einem Verwahrer bzw. Wächter bzw. Keeper der Entität, wobei der Keeper den zumindest einen Identitätsfaktor bereitgestellt hat;
- Generieren eines ersten Hash-Ergebnisses unter Verwendung des Inhalts des Genesis-Knotens und des Signaturschlüssels als Eingabe;
- Generieren eines zweiten Knotens in der Identitätskette, wobei der zweite Knoten Inhalt aufweist, der eine Identifizierung des zumindest einen Identitätsfaktors und das erste Hash-Ergebnis enthält;
- Generieren eines zweiten Hash-Ergebnisses unter Verwendung des Inhalts des zweiten Knotens und des Signaturschlüssels als Eingabe; und Speichern eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Schlüsseleigenschaft enthält, die verwendet wird, um die Entität ansprechend auf Verifizierungsanfragen zu lokalisieren.
2. Verfahren nach Punkt 1, ferner umfassend:
- Verschlüsseln der Genesis-Daten vor dem Generieren des Genesis-Knotens, wobei der Genesis-Knoten die verschlüsselten Genesis-Daten speichert.
3. Verfahren nach Punkt 1, wobei der Graphzugriffsdatensatz ein Knoten in dem Graphen ist.
4. Verfahren nach Punkt 1, wobei der Graphzugriffsdatensatz ein Eintrag in einer Tabelle ist.
5. Verfahren nach Punkt 1, ferner umfassend:
- Empfangen einer Verifizierungsanfrage, die einen Abfrageschlüssel und eine Abfrageeigenschaft enthält; Lokalisieren eines ersten Graphzugriffsdatensatzes mit einer Schlüsseleigenschaft, die mit der Abfrageeigenschaft übereinstimmt; und Bestimmen, ob eine Kette zu einem Genesis-Knoten existiert, unter Verwendung eines Hash-Ergebnisses in dem ersten Graphzugriffsdatensatz und dem Abfrageschlüssel.
6. Verfahren nach Punkt 5, ferner umfassend, ansprechend auf das Bestimmen, dass eine Kette zu einem Genesis-Knoten existiert:
- Generieren eines Aktivitätsknotens in der Identitätskette, wobei der Aktivitätsknoten ein Hash-Ergebnis enthält, das mit dem ersten Graphzugriffsdatensatz verknüpft ist, und Datenelemente enthält, die sich auf eine Aktivität für die Entität beziehen;
- Generieren eines dritten Hash-Ergebnisses durch Hashen des Aktivitätsknotens und des Abfrageschlüssels; und Ersetzen des Hash-Ergebnisses in dem ersten Graphzugriffsdatensatz durch das dritte Hash-Ergebnis.
7. Verfahren nach Punkt 5, wobei das Verfahren ferner umfasst:
- Empfangen einer zweiten Schlüsseleigenschaft, die sich von der Schlüsseleigenschaft in dem ersten Graphzugriffsdatensatz unterscheidet; und
- ansprechend auf das Bestimmen, dass eine Kette zu einem Genesis-Knoten existiert, Speichern eines zweiten Graphzugriffsdatensatzes, wobei der zweite Graphzugriffsdatensatz das zweite Hash-Ergebnis und die zweite Schlüsseleigenschaft enthält.
8. Verfahren nach Punkt 5, ferner umfassend, ansprechend auf das Bestimmen, dass eine Kette zu einem Genesis-Knoten existiert:
- Generieren eines Aktivitätsknotens in der Identitätskette, wobei der Aktivitätsknoten ein Hash-Ergebnis enthält, das mit dem ersten Graphzugriffsdatensatz verknüpft ist, und Datenelemente enthält, die sich auf eine Aktivität für die Entität beziehen;
- Generieren eines dritten Hash-Ergebnisses durch Hashen des Aktivitätsknotens und des Abfrageschlüssels; und Hinzufügen eines zweiten Graphzugriffsdatensatzes, wobei der zweite Graphzugriffsdatensatz das dritte Hash-Ergebnis aufweist.
9. Verfahren nach Punkt 1, ferner umfassend:
- Verwenden des Graphen und des Graphzugriffsdatensatzes, um auf eine Verifizierungsanfrage für die Entität zu antworten.
10. Verfahren nach Punkt 1, wobei die Genesis-Daten Bilddaten für die Entität enthalten.
11. Verfahren nach Punkt 1, wobei die Genesis-Daten biometrische Daten für die Entität enthalten.
12. Verfahren nach Punkt 1, wobei die Genesis-Daten Daten von einem bestimmten Speicherort eines Geräts enthalten.
13. Verfahren nach Punkt 1, wobei die Genesis-Daten einen Ort für die Entität enthalten.
14. System, umfassend:
- zumindest einen Prozessor;
- einen Identitätsgraphen, der Identitätsblöcke speichert, wobei die Identitätsblöcke Genesis-Blöcke bzw. Entstehungsblöcke enthalten; und
- einen Speicher, der Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen,
- Operationen durchzuführen, die beinhalten:
  - Empfangen von Genesis-Daten bzw. Entstehungsdaten und eines Signaturschlüssels nach einem erfolgreichen Identitätsnachweisprozess für eine Person, wobei die Genesis-Daten eine physische Eigenschaft der
  - Person erfassen und der Signaturschlüssel durch die Person bereitgestellt wird,
  - Generieren eines ersten Hash-Ergebnisses unter Verwendung der Genesis-Daten als Eingabe,
  - Generieren eines Genesis-Blocks bzw. Entstehungsblocks in dem Identitätsgraphen, wobei der Genesis-Block die Genesis-Daten als Inhalt aufweist, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird,
  - Generieren eines zweiten Hash-Ergebnisses unter Verwendung von Nutzlastdaten und dem ersten Hash-Ergebnis als Eingabe,
  - Generieren eines Identitätsblocks in dem Identitätsgraphen, wobei der Identitätsblock einen Inhalt aufweist, der die Nutzlastdaten und das erste Hash-Ergebnis enthält, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird,
  - Generieren eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Sucheigenschaft für die Person, aber nicht den Signaturschlüssel enthält, und
  - Verwenden des Identitätsgraphen beim Antworten auf Verifizierungs- bzw. Prüfanfragen.
15. System nach Punkt 14, wobei der Graphzugriffsdatensatz ein Block ist, der in dem Identitätsgraphen gespeichert ist.
16. System nach Punkt 14, wobei das Verwenden des Identitätsgraphen ansprechend auf die Verifizierungsanfragen beinhalten:
- Empfangen, für die Person, von Aktivitätsdaten, eines Abfrageschlüssels und
- einer Abfrageeigenschaft;
- Bestimmen, ob eine Kette in dem Identitätsgraphen für die Person existiert, die den Abfrageschlüssel und die Abfrageeigenschaft verwendet; und ansprechend auf das Bestimmen, dass die Kette existiert:
  - Generieren eines dritten Hash-Ergebnisses unter Verwendung der Aktivitätsdaten und des zweiten Hash-Ergebnisses als Eingabe, Generieren eines neuen Identitätsblocks in dem Identitätsgraphen, wobei der neue Identitätsblock die Aktivitätsdaten und das zweite Hash-Ergebnis als Inhalt aufweist, wobei der Inhalt des neuen Identitätsblocks unter Verwendung des Abfrageschlüssels verschlüsselt wird, und Aktualisieren des Graphzugriffsdatensatzes durch Ersetzen des zweiten Hash-Ergebnisses durch das dritte Hash-Ergebnis.
17. System nach Punkt 14, wobei das Verwenden des Identitätsgraphen ansprechend auf die Verifizierungsanfragen beinhaltet:
- Empfangen, für die Person, eines Abfrageschlüssels und einer Abfrageeigenschaft;
- Bestimmen, ob eine Kette in dem Identitätsgraphen für die Person existiert, die den Abfrageschlüssel und die Abfrageeigenschaft verwendet; und ansprechend auf das Bestimmen, dass die Kette existiert, Bereitstellen einer Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
18. System nach Punkt 17, wobei die Antwort zumindest einen Teil der Genesis-Daten enthält.
19. System nach Punkt 14, wobei die Genesis-Daten entweder Bilddaten für die Person oder biometrische Daten für die Person enthalten.
20. System nach Punkt 14, wobei der Signaturschlüssel zumindest eines von Textzeichenfolge oder Bild enthält.
21. Verfahren, umfassend:
- Empfangen zumindest einer Eigenschaft, die eine Entität identifiziert, und
- eines Abfrageschlüssels, wobei der Abfrageschlüssel Daten ist, die ursprünglich von einem angeblichen Verwahrer bzw. Wächter bzw. Keeper der Entität ausgewählt wurden;
- Identifizieren einer Übereinstimmung für die Eigenschaft aus Graphzugriffsaufzeichnungen, wobei die Übereinstimmung ein verknüpftes Hash-Ergebnis aufweist, wobei die Übereinstimmung als ein aktueller Knoten in einer Kette betrachtet wird;
- Verifizieren bzw. Prüfen einer vollständigen Kette von dem aktuellen Knoten
- zu einem Genesis-Knoten bzw. Entstehungsknoten durch Wiederholen von:
  - Identifizieren eines Knotens in einem Graphen, der einen Inhalt aufweist, der, wenn er unter Verwendung des Abfrageschlüssels gehasht wird, in einem zweiten Hash-Ergebnis resultiert, das mit dem verknüpften Hash-Ergebnis des aktuellen Knotens übereinstimmt, wobei ein Scheitern beim Identifizieren eines Knotens die Wiederholung stoppt und ein Bestimmen, dass der Knoten ein Genesis-Knoten ist, die Wiederholung stoppt, und Machen des Knotens zum aktuellen Knoten, wobei der Inhalt des Knotens ein verknüpftes Hash-Ergebnis enthält;
- ansprechend auf das Lokalisieren des Genesis-Knotens, Generieren einer Antwort, die eine erfolgreiche Verifizierungs- bzw. Prüfanfrage angibt; und ansprechend darauf, dass der Genesis-Knoten nicht lokalisiert wird, Generieren einer Antwort, die eine erfolglose Verifizierungsanfrage angibt.
22. Verfahren nach Punkt 21, wobei der Abfrageschlüssel entweder ein Ausdruck bzw. Satz, ein Bild oder eine Kombination von Datenelementen ist, wobei der Abfrageschlüssel von dem angeblichen Keeper als Teil eines Identitätsnachweisprozesses ausgewählt wird, der die Generierung des Genesis-Knotens initiiert hat.
23. Verfahren nach Punkt 21, ferner umfassend:
- für zumindest einen Knoten in der Kette, Erhalten eines Datenelements aus dem Inhalt; und
- Einschließen des Datenelements in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
24. Verfahren nach Punkt 21, ferner umfassend:
- Einschließen von zumindest etwas Inhalt des Genesis-Knotens in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
25. Verfahren nach Punkt 24, wobei der Inhalt des Genesis-Knotens ein Bild der Entität enthält.
26. Verfahren nach Punkt 25, wobei die Entität eine Person ist und der angebliche Keeper die Person ist und der Inhalt des Genesis-Knotens ein biometrisches Bild ist.
27. Verfahren nach Punkt 25, wobei die Entität ein Gegenstand ist und der angebliche Keeper eine Person ist.
28. Verfahren nach Punkt 21, ferner umfassend:
- Entschlüsseln des Inhalts des Genesis-Knotens vor dem Einschließen des Inhalts in die Antwort.
29. Verfahren nach Punkt 21, ferner umfassend, nach einer erfolgreichen Verifizierungsanfrage:
- Generieren eines neuen Knotens in dem Graphen, wobei der neue Knoten Inhalt aufweist, der Datenelemente von einer Aktivität, die nach der erfolgreichen Verifizierungsanfrage auftritt, und das Hash-Ergebnis enthält,
- das mit der Übereinstimmung der Eigenschaft verknüpft ist, die zum Lokalisieren des Genesis-Knoten verwendet wird;
- Generieren eines neuen Hash-Ergebnisses unter Verwendung des neuen Knotens und des Abfrageschlüssels als Eingabe; und
- Aktualisieren des Hash-Ergebnisses der Übereinstimmung der Eigenschaft, die zum Lokalisieren des Genesis-Knoten verwendet wird, auf das neue Hash-Ergebnis.
30. Verfahren nach Punkt 21, wobei die Entität eine entfernte Vorrichtung in einem Netzwerk ist und die entfernte Vorrichtung Daten mit der Eigenschaft und dem Abfrageschlüssel bereitstellt und das Verfahren ferner umfasst:
- Akzeptieren der Daten ansprechend auf eine erfolgreiche Verifizierungsanfrage; und
- Ablehnen der Daten ansprechend auf eine erfolglose Verifizierungsanfrage.
31. Verfahren nach Punkt 21, wobei das Verfahren durch eine ferngesteuerte Vorrichtung durchgeführt wird und Anweisungen mit der Eigenschaft und dem Abfrageschlüssel empfangen werden und das Verfahren ferner beinhaltet:
- Handeln gemäß den Anweisungen ansprechend auf eine erfolgreiche Verifizierungsanfrage; und
- Zurückweisen der Anweisungen ansprechend auf eine erfolglose Verifizierungsanfrage.
32. Verfahren nach Punkt 21, wobei das Verwenden des Abfrageschlüssels zum Generieren des Hash-Ergebnisses ein Hinzufügen des Abfrageschlüssels zu dem Inhalt des Knotens vor dem Generieren des Hash-Ergebnisses beinhaltet.
33. Verfahren nach Punkt 21, wobei das Verwenden des Abfrageschlüssels zum Generieren des Hash-Ergebnisses ein Entschlüsseln des Inhalts vor dem Generieren des Hash-Ergebnisses beinhaltet.
34. Verfahren nach Punkt 21, wobei die Eigenschaft eine erste Eigenschaft ist und das Verfahren ferner umfasst:
- Empfangen einer zweiten Eigenschaft, die sich von der ersten Eigenschaft unterscheidet; und
- Speichern, nach einer erfolgreichen Verifizierungsanfrage, eines neuen Graphzugriffsdatensatzes, wobei der neue Graphzugriffsdatensatz das verknüpfte Hash-Ergebnis der Übereinstimmung und eine Schlüsseleigenschaft enthält, die sich von der ersten Eigenschaft unterscheidet.
35. System, umfassend:
- zumindest einen Prozessor;
- einen Graphen, der Blöcke speichert, wobei die Blöcke Genesis-Blöcke bzw.
- Entstehungsblöcke enthalten; und
- einen Speicher, der Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen,
- Operationen durchzuführen, die beinhalten:
  - Empfangen zumindest einer Eigenschaft, die eine Entität identifiziert, und eines Abfrageschlüssels, wobei der Abfrageschlüssel Daten sind, die ursprünglich von einem angeblichen Verwahrer bzw. Wächter bzw. Keeper der Entität ausgewählt wurden;
  - Identifizieren einer Übereinstimmung für die Eigenschaft aus Graphzugriffsaufzeichnungen, wobei die Übereinstimmung ein verknüpftes Hash-Ergebnis aufweist, wobei die Übereinstimmung als ein aktueller Block in einer Kette betrachtet wird;
  - Verifizieren bzw. Prüfen einer vollständigen Kette von dem aktuellen Block zu einem Genesis-Block bzw. Entstehungsblock durch Wiederholen von:
    - Identifizieren eines Blocks in einem Graphen, der einen Inhalt aufweist, der, wenn er unter Verwendung des Abfrageschlüssels gehasht wird, in einem Hash-Ergebnis resultiert, das mit dem verknüpften Hash-Ergebnis des aktuellen Blocks übereinstimmt, wobei ein Scheitern beim Identifizieren eines Blocks die Wiederholung stoppt und ein Bestimmen, dass der Block ein Genesis-Block ist, die Wiederholung stoppt, und Machen des Blocks zum aktuellen Block,
  - ansprechend auf das Lokalisieren des Genesis-Blocks, Entschlüsseln des Inhalts des Genesis-Blocks und Generieren einer Antwort, die eine erfolgreiche Verifizierungs- bzw. Prüfanfrage angibt und etwas verschlüsselten Inhalte aus dem Genesis-Block enthält; und
  - ansprechend darauf, dass der Genesis-Block nicht lokalisiert wird, Generieren einer Antwort, die eine nicht erfolgreiche Verifizierungsanfrage angibt.
36. System nach Punkt 35, wobei die Graphzugriffsdatensätze Blöcke in dem Graphen sind.
37. System nach Punkt 35, wobei die Graphzugriffsdatensätze. Einträge in einer Tabelle sind.
38. System nach Punkt 35, wobei der Abfrageschlüssel entweder ein Ausdruck bzw. Satz, ein Bild oder eine Kombination von Datenelementen ist, wobei der Abfrageschlüssel von dem angeblichen Keeper als Teil eines Identitätsnachweisprozesses ausgewählt wird, der die Generierung des Genesis-Blocks initiiert hat.
39. System nach Punkt 35, ferner umfassend:
- für zumindest einen Block in der Kette, Erhalten eines Datenelements aus dem Inhalt; und
- Einschließen des Datenelements in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
40. System nach Punkt 35, wobei die Eigenschaft eine erste Eigenschaft ist und der Speicher Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen, weitere Operationen durchzuführen, die beinhalten:
- Empfangen einer zweiten Eigenschaft, die sich von der ersten Eigenschaft unterscheidet; und
- Speichern, nach einer erfolgreichen Verifizierungsanfrage, eines neuen Graph-Zugriffsdatensatzes, wobei der neue Graph-Zugriffsdatensatz das verknüpfte Hash-Ergebnis der Übereinstimmung und eine Schlüsseleigenschaft enthält, die sich von der ersten Eigenschaft unterscheidet.
41. System nach Punkt 35, wobei der Inhalt des Genesis-Blocks ein zweidimensionales Bild oder ein dreidimensionales Bild der Entität enthält.
42. System nach Punkt 35, wobei die Entität eine Person ist und der Inhalt des Genesis-Blocks biometrische Daten für die Person enthält.
43. System nach Punkt 35, ferner umfassend, nach einer erfolgreichen Verifizierungsanfrage:
- Generieren eines neuen Blocks in dem Graphen, wobei der neue Block Inhalt aufweist, der Datenelemente von einer Aktivität, die nach der erfolgreichen Verifizierungsanfrage auftritt, und das verknüpfte Hash-Ergebnis aus der Übereinstimmung enthält;
- Generieren eines neuen Hash-Ergebnisses unter Verwendung des neuen Blocks und des Abfrageschlüssels als Eingabe; und
- Aktualisieren des verknüpften Hash-Ergebnisses der Übereinstimmung auf das neue Hash-Ergebnis.
44. System nach Punkt 35, wobei die Entität eine entfernte Vorrichtung in einem Netzwerk ist und die entfernte Vorrichtung Daten mit der Eigenschaft und dem Abfrageschlüssel bereitstellt und der Speicher Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen, weitere Operationen durchzuführen, die beinhalten:
- Akzeptieren der Daten ansprechend auf eine erfolgreiche Verifizierungsanfrage; und
- Ablehnen der Daten ansprechend auf eine erfolglose Verifizierungsanfrage.
45. System nach Punkt 35, wobei das System eine ferngesteuerte Vorrichtung enthält und Anweisungen mit der Eigenschaft und dem Abfrageschlüssel empfangen werden und der Speicher Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, die ferngesteuerte Vorrichtung veranlassen, Operationen durchzuführen, die beinhalten:
- Handeln gemäß den Anweisungen ansprechend auf eine erfolgreiche Verifizierungsanfrage; und
- Zurückweisen der Anweisungen ansprechend auf eine erfolglose Verifizierungsanfrage.

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 17247110 B [0001]
US 62988271 B [0001]
US 17249592 B [0001]
US 20200265046 A1 [0025]

Claims

System, umfassend: zumindest einen Prozessor; einen Identitätsgraphen, der Identitätsblöcke speichert, wobei die Identitätsblöcke Genesis-Blöcke bzw. Entstehungsblöcke enthalten; und einen Speicher, der Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen, Operationen durchzuführen, die beinhalten: Empfangen von Genesis-Daten bzw. Entstehungsdaten und eines Signaturschlüssels nach einem erfolgreichen Identitätsnachweisprozess für eine Person, wobei die Genesis-Daten eine physische Eigenschaft der Person erfassen und der Signaturschlüssel durch die Person bereitgestellt wird, Generieren eines ersten Hash-Ergebnisses unter Verwendung der Genesis-Daten als Eingabe, Generieren eines Genesis-Blocks bzw. Entstehungsblocks in dem Identitätsgraphen, wobei der Genesis-Block die Genesis-Daten als Inhalt aufweist, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird, Generieren eines zweiten Hash-Ergebnisses unter Verwendung von Nutzlastdaten und dem ersten Hash-Ergebnis als Eingabe, Generieren eines Identitätsblocks in dem Identitätsgraphen, wobei der Identitätsblock einen Inhalt aufweist, der die Nutzlastdaten und das erste Hash-Ergebnis enthält, wobei der Inhalt unter Verwendung des Signaturschlüssels verschlüsselt wird, Generieren eines Graphzugriffsdatensatzes, wobei der Graphzugriffsdatensatz das zweite Hash-Ergebnis und zumindest eine Sucheigenschaft für die Person, aber nicht den Signaturschlüssel enthält, und Verwenden des Identitätsgraphen beim Antworten auf Verifizierungs- bzw. Prüfanfragen.
System nach Anspruch 1, wobei der Graphzugriffsdatensatz ein Block ist, der in dem Identitätsgraphen gespeichert ist.
System nach Anspruch 1 oder 2, wobei das Verwenden des Identitätsgraphen ansprechend auf die Verifizierungsanfragen beinhalten: Empfangen, für die Person, von Aktivitätsdaten, eines Abfrageschlüssels und einer Abfrageeigenschaft; Bestimmen, ob eine Kette in dem Identitätsgraphen für die Person existiert, die den Abfrageschlüssel und die Abfrageeigenschaft verwendet; und ansprechend auf das Bestimmen, dass die Kette existiert: Generieren eines dritten Hash-Ergebnisses unter Verwendung der Aktivitätsdaten und des zweiten Hash-Ergebnisses als Eingabe, Generieren eines neuen Identitätsblocks in dem Identitätsgraphen, wobei der neue Identitätsblock die Aktivitätsdaten und das zweite Hash-Ergebnis als Inhalt aufweist, wobei der Inhalt des neuen Identitätsblocks unter Verwendung des Abfrageschlüssels verschlüsselt wird, und Aktualisieren des Graphzugriffsdatensatzes durch Ersetzen des zweiten Hash-Ergebnisses durch das dritte Hash-Ergebnis.
System nach Anspruch 1, wobei das Verwenden des Identitätsgraphen ansprechend auf die Verifizierungsanfragen beinhaltet: Empfangen, für die Person, eines Abfrageschlüssels und einer Abfrageeigenschaft; . Bestimmen, ob eine Kette in dem Identitätsgraphen für die Person existiert, die den Abfrageschlüssel und die Abfrageeigenschaft verwendet; und ansprechend auf das Bestimmen, dass die Kette existiert, Bereitstellen einer Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
System nach Anspruch 4, wobei die Antwort zumindest einen Teil der Genesis-Daten enthält.
System nach einem der Ansprüche 1 bis 5, wobei die Genesis-Daten entweder Bilddaten für die Person oder biometrische Daten für die Person enthalten.
System nach einem der Ansprüche 1 bis 6, wobei der Signaturschlüssel zumindest eines von Textzeichenfolge oder Bild enthält.
System, umfassend: zumindest einen Prozessor; ein gespeicherter Graph von Blöcken, wobei die Blöcke Genesis-Blöcke bzw. Entstehungsblöcke enthalten; und einen Speicher, der Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen, Operationen durchzuführen, die beinhalten: Empfangen zumindest einer Eigenschaft, die eine Entität identifiziert, und eines Abfrageschlüssels, wobei der Abfrageschlüssel Daten sind, die ursprünglich von einem angeblichen Verwahrer bzw. Wächter bzw. Keeper der Entität ausgewählt wurden; Identifizieren einer Übereinstimmung für die Eigenschaft aus Graphzugriffsaufzeichnungen, wobei die Übereinstimmung ein verknüpftes Hash-Ergebnis aufweist, wobei die Übereinstimmung als ein aktueller Block in einer Kette betrachtet wird; Verifizieren bzw. Prüfen einer vollständigen Kette von dem aktuellen Block zu einem Genesis-Block bzw. Entstehungsblock durch Wiederholen von: Identifizieren eines Blocks in einem Graphen, der einen Inhalt aufweist, der, wenn er unter Verwendung des Abfrageschlüssels gehasht wird, in einem Hash-Ergebnis resultiert, das mit dem verknüpften Hash-Ergebnis des aktuellen Blocks übereinstimmt, wobei ein Scheitern beim Identifizieren eines Blocks die Wiederholung stoppt und ein Bestimmen, dass der Block ein Genesis-Block ist, die Wiederholung stoppt, und Machen des Blocks zum aktuellen Block, ansprechend auf das Lokalisieren des Genesis-Blocks, Entschlüsseln des Inhalts des Genesis-Blocks und Generieren einer Antwort, die eine erfolgreiche Verifizierungs- bzw. Prüfanfrage angibt und etwas verschlüsselten Inhalte aus dem Genesis-Block enthält; und ansprechend darauf, dass der Genesis-Block nicht lokalisiert wird, Generieren einer Antwort, die eine nicht erfolgreiche Verifizierungsanfrage angibt.
System nach Anspruch 8, wobei die Graphzugriffsdatensätze Blöcke in dem Graphen sind.
System nach Anspruch 8, wobei die Graphzugriffsdatensätze Einträge in einer Tabelle sind.
System nach einem der Ansprüche 8 bis 10, wobei der Abfrageschlüssel entweder ein Ausdruck bzw. Satz, ein Bild oder eine Kombination von Datenelementen ist, wobei der Abfrageschlüssel von dem angeblichen Keeper als Teil eines Identitätsnachweisprozesses ausgewählt wird, der die Generierung des Genesis-Blocks initiiert hat.
System nach einem der Ansprüche 8 bis 11, ferner umfassend: für zumindest einen Block in der Kette, Erhalten eines Datenelements aus dem Inhalt; und Einschließen des Datenelements in die Antwort, die eine erfolgreiche Verifizierungsanfrage angibt.
System nach einem der Ansprüche 8 bis 12, wobei die Eigenschaft eine erste Eigenschaft ist und der Speicher Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen, weitere Operationen durchzuführen, die beinhalten: Empfangen einer zweiten Eigenschaft, die sich von der ersten Eigenschaft unterscheidet; und Speichern, nach einer erfolgreichen Verifizierungsanfrage, eines neuen Graph-Zugriffsdatensatzes, wobei der neue Graph-Zugriffsdatensatz das verknüpfte Hash-Ergebnis der Übereinstimmung und eine Schlüsseleigenschaft enthält, die sich von der ersten Eigenschaft unterscheidet.
System nach einem der Ansprüche 8 bis 13, wobei der Inhalt des Genesis-Blocks ein zweidimensionales Bild oder ein dreidimensionales Bild der Entität enthält.
System nach einem der Ansprüche 8 bis 14, wobei die Entität eine Person ist und der Inhalt des Genesis-Blocks biometrische Daten für die Person enthält.
System nach einem der Ansprüche 8 bis 15, ferner umfassend, nach einer erfolgreichen Verifizierungsanfrage: Generieren eines neuen Blocks in dem Graphen, wobei der neue Block Inhalt aufweist, der Datenelemente von einer Aktivität, die nach der erfolgreichen Verifizierungsanfrage auftritt, und das verknüpfte Hash-Ergebnis aus der Übereinstimmung enthält; Generieren eines neuen Hash-Ergebnisses unter Verwendung des neuen Blocks und des Abfrageschlüssels als Eingabe; und Aktualisieren des verknüpften Hash-Ergebnisses der Übereinstimmung auf das neue Hash-Ergebnis.
System nach einem der Ansprüche 8 bis 13, wobei die Entität eine entfernte Vorrichtung in einem Netzwerk ist und die entfernte Vorrichtung Daten mit der Eigenschaft und dem Abfrageschlüssel bereitstellt und der Speicher Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, das System veranlassen, weitere Operationen durchzuführen, die beinhalten: Akzeptieren der Daten ansprechend auf eine erfolgreiche Verifizierungsanfrage; und Ablehnen der Daten ansprechend auf eine erfolglose Verifizierungsanfrage.
System nach einem der Ansprüche 8 bis 17, wobei das System eine ferngesteuerte Vorrichtung enthält und Anweisungen mit der Eigenschaft und dem Abfrageschlüssel empfangen werden und der Speicher Anweisungen speichert, die, wenn sie durch den zumindest einen Prozessor ausgeführt werden, die ferngesteuerte Vorrichtung veranlassen, Operationen durchzuführen, die beinhalten: Handeln gemäß den Anweisungen ansprechend auf eine erfolgreiche Verifizierungsanfrage; und Zurückweisen der Anweisungen ansprechend auf eine erfolglose Verifizierungsanfrage.
System, umfassend: zumindest einen Prozessor; einen Speicher, der Graphzugriffsdatensätze und Identitätsketten speichert; und einen Speicher, der Anweisungen speichert, die, wenn sie von dem zumindest einen Prozessor ausgeführt werden, das System veranlassen, Operationen durchzuführen, die beinhalten: Empfangen eines Identitätsfaktors für eine Entität und Genesis- bzw. Entstehungsdaten, die Daten enthalten, die eine eindeutige physische Eigenschaft der Entität erfassen; Empfangen eines Signaturschlüssels von einem Verwahrer bzw. Wächter bzw. Keeper der Entität, wobei der Keeper den Identitätsfaktor bereitgestellt hat; Generieren einer Identitätskette für die Entität, wobei die Identitätskette Knoten aufweist, die einen Genesis- bzw. Entstehungsknoten mit Inhalt aufweisen, der die Genesis-Daten enthält, und einen zweiten Knoten mit Inhalt enthält, der den Identitätsfaktor enthält, wobei der Signaturschlüssel verwendet wird, um Hash-Ergebnisse zu berechnen, die zum Verknüpften der Knoten in der Identitätskette verwendet werden; Speichern der Identitätskette in dem Speicher, der die Identitätsketten speichert; und Speichern eines Graphzugriffsdatensatzes zum Zugreifen auf die Identitätskette in dem Speicher, der die Graphzugriffsdatensätze speichert, wobei der Graphzugriffsdatensatz eine Schlüsseleigenschaft enthält, die verwendet wird, um die Identitätskette ansprechend auf eine Verifizierungsanfrageg für die Entität zu lokalisieren, und ein Hash-Ergebnis der Hash-Ergebnisse enthält, die verwendet werden, um ein Durchlaufen der Identitätskette zu initiieren.
System nach Anspruch 19, wobei das Verwenden des Signaturschlüssels zum Berechnen der Hash-Ergebnisse umfasst: Generieren eines ersten Hash-Ergebnisses unter Verwendung des Inhalts eines Knotens in der Identitätskette und des Signaturschlüssels als Eingabe, und Speichern des ersten Hash-Ergebnisses in dem Inhalt eines nächsten Knotens der Identitätskette.
System nach Anspruch 19 oder 20, wobei das Verwenden des Signaturschlüssels zum Berechnen der Hash-Ergebnisse umfasst: Generieren eines ersten Hash-Ergebnisses unter Verwendung von Inhalt für einen Knoten der Identitätskette als Eingabe; Verschlüsseln des Inhalts des Knotens unter Verwendung des Signaturschlüssels und Speichern des Knotens; und Einschließen des ersten Hash-Ergebnisses in den Inhalt eines nächsten Knotens der Identitätskette.
System nach einem der Ansprüche 19 bis 21, wobei die Operationen ferner beinhalten: Verwenden der Identitätskette und des Graphzugriffsdatensatzes, um auf die Verifizierungsanfrage für die Entität zu antworten.
System nach Anspruch 22, wobei das Verwenden der Identitätskette und des Graphzugriffsdatensatzes zum Antworten auf die Verifizierungsanfrage beinhaltet: Empfangen der Verifizierungsanfrage, die die Schlüsseleigenschaft für die Entität und einen Abfrageschlüssel enthält; Lokalisieren der Identitätskette unter Verwendung der Schlüsseleigenschaft; Verwenden des Abfrageschlüssels und des Hash-Ergebnisses, die in dem Graphzugriffsdatensatz enthalten sind, um zu versuchen, die Identitätskette zu dem Genesis-Knoten zu durchlaufen; Senden eines Hinweises auf eine nicht erfolgreiche Anfrage ansprechend auf ein Scheitern beim Durchlaufen der Identitätskette zu dem Genesis-Knoten unter Verwendung des Abfrageschlüssels; und Senden eines Hinweises auf eine erfolgreiche Anfrage ansprechend auf das Scheitern beim Durchlaufen der Identitätskette zu dem Genesis-Knoten unter Verwendung des Abfrageschlüssels.
System nach Anspruch 23, wobei die Operationen ansprechend auf das Scheitern beim Durchlaufen der Identitätskette zu dem Genesis-Knoten unter Verwendung des Abfrageschlüssels ferner beinhalten: Hinzufügen eines Knotens in der Identitätskette unter Verwendung des Abfrageschlüssels, um den hinzugefügten Knoten mit der Identitätskette zu verknüpfen.
System nach Anspruch 23 oder 24, wobei der Graphzugriffsdatensatz ein erster Graphzugriffsdatensatz ist und die Operationen ansprechend auf das Scheitern beim Durchlaufen der Identitätskette zu dem Genesis-Knoten unter Verwendung des Abfrageschlüssels ferner beinhalten: Empfangen einer zweiten Schlüsseleigenschaft, die sich von der Schlüsseleigenschaft in dem ersten Graphzugriffsdatensatz unterscheidet; und Speichern eines zweiten Graphzugriffsdatensatzes, wobei der zweite Graphzugriffsdatensatz das Hash-Ergebnis aus dem ersten Graphzugriffsdatensatz und die zweite Schlüsseleigenschaft enthält.
System nach einem der Ansprüche 19 bis 25, wobei die Genesis-Daten Bilddaten für die Entität oder biometrische Daten für die Entität enthalten.
System nach einem der Ansprüche 19 bis 26, wobei die Genesis-Daten Daten von einem spezifischen Speicherort einer Vorrichtung enthalten.
System nach einem der Ansprüche 19 bis 27, wobei die Genesis-Daten einen Ort für die Entität enthalten.