Sicherer Speicher und Backup mit Privacy Garantie

[tobiaschristen]

Eine gut konzipierte digitale Brieftasche sollte sicherer und besser vor Verlust geschützt sein als eine physische Brieftasche. Gemäss den Absichten einiger Europäischer Wallet Hersteller allerdings nur, wenn der Besitzer die notwendigen Schritte zur Vorbereitung auf die Wiederherstellung regelmässig selbst unternimmt. Unserer Ansicht nach, muss diese Absicherung kontinuierlich und automatisch geschehen. Diese Dringlichkeit ergibt sich daraus, dass die Daten apriori nur auf dem Gerät der Digital-Wallet existieren und die Benutzer nicht in die Pflicht genommen werden sollten für technische Risiko-Mitigation.

Es existieren mehrere Alternativen für ein Wallet Backup. Das Buch «Self-Sovereign Identity» (ISBN 9781617296598) beschreibt “Offline Recovery (USB devices)”, “Automated encrypted (cloud) backup”, “Social recovery”. Nach Jahren der Marktbeobachtung sind wir unverändert davon überzeugt, dass «automatische, verschlüsselte und privatsphären-geschützte Cloud-Backups» die einzig sinnvolle Lösung sind. Am besten unterstützt ein entsprechender sicherer Speicher neben dem Recovery einer Wallet auch die geräteübergreifende Wallet-Synchronisation, die Konsolidierung von mehreren Wallets, und die Konsolidierung mit digitalen Assets aus der Vor-SSI Welt über eine separate «Off-Wallet-Applikation».

Ein Cloud-Speicher mit Privatsphärenschutzgarantie kann nicht nur die oben genannten
benutzer-zentrischen Use-Cases unterstützen, sondern auch als Transfer-Medium für zusätzliche Daten und Dokumente in ein Wallet verwendet werden. Ein Beispiel dafür ist der Transfer einer Versicherungspolice, welche vom Versicherer in den Cloud-Speicher gesendet wird, von wo sie dann automatisch im Wallet hinterlegt werden kann.

Wir gehen hierbei von der Annahme aus, dass es einen offenen API-Standard geben wird der die Anbindung und Einlieferung von hoch vertrauenswürdigen Daten aus einem Digital-Wallet in sichere Drittsysteme erlaubt. Für regelmässige und asynchron ausgestellte Daten/Dokumente sollte auch die direkte Einlieferung von der Quelle in den Cloud-Speicher möglich sein.

Das Grund-Setup einer solchen Lösung sollte 4 Eigenschaften haben:

• Der User muss initial seine Zustimmung zur Einlieferung explizit geben, und diese jederzeit widerrufen können.
• Alle involvierten Systeme (Wallet, Cloud-Speicher und ggf. Provider-System) sollten entkoppelt und eine Korrelation der Accounts nur durch den User möglich sein. Heisst: Die Services sollten gegenseitig keine kunden-identifizierenden Daten austauschen müssen.
• Da der Cloud-Speicher selbst mit einer hohen Anzahl Kunden-identifizierenden Daten arbeitet, sind höchste Anforderungen an die Daten-Prozessierung und das Logging geboten. Der Grundsatz von Daten-Sparsamkeit muss damit insbesondere auch bei der Prozessierung verfolgt werden.
• Die Datenübertragung sollte vollautomatisch erfolgen, folgend der Anforderung im ersten Abschnitt (das technische Risiko und die Komplexität sollte nicht auf den User abgewälzt werden).
• Sämtliche Datenübertragung muss verschlüsselt erfolgen, zur Wahrung Privatsphäre am besten doppelt verschlüsselt und nicht nur mit TLS (ausser es kommt mTLS zum Einsatz).

Die Vertraulichkeit der Daten in den prozessierenden Systemen ist über weiterführende Controls zu gewährleisten.

Damit dieser Post hier nicht zu lang wird würden wir folgende Themen in separaten Posts skizzieren:

• Importance of publicly documented domain model
• Evolution readyness of the API
• Levels of Documentation for developers of the API
• REST idioms to be considered in the API
• Recovery Procedure

[grt-dti]

Guten Morgen @tobiaschristen

in Ableitung der Annahme eines cloudbasierten Backup-&Recovery-Systems erscheinen ihre Erwartungen plausibel, aber wie kommen "Sie" zur Annahme / Überzeugung, das nur "«automatische, verschlüsselte und privatsphären-geschützte Cloud-Backups» die einzig sinnvolle Lösung" wären. Können Sie den "Sinn" formulieren und motivieren (also die Antwort auf die Frage: "Wieso sollte dies "gut" für mich als Anwender sein?"), die alle anderen Backup-&Recovery-Systeme unzulänglich erscheinen lassen?

freundliche Grüsse

[tobiaschristen]

Hallo,
gerne führen wir unsere Erfahrungen und Ansichten zu diesem Punkt im Detail aus. Brauche allerdings noch ein paar Kalendertage um die Antwort zu formulieren. Die Antwort wird sich zusammensetzen aus

• den Nachteilen der exkludierten Lösungen und entsprechenden Ableitungen und Erfahrungen von anderen Wallet-Typen
• den Vorteilen der Cloud-Lösungen und unseren Erfahrungen mit SecureSafe und seinen Konkurrenten
• der Architektur und Operational Excellence Erfahrungen mit Backup Strategien von Grossfirmen

viele Grüsse, Tobias Christen

[grt-dti]

bin ich ernsthaft interessiert daran!

[tobiaschristen]

Lieber/Liebe grt-dti,
Die untenstehende Ausführung wurde ein bisschen lang. Hoffe das stört nicht, und beantwortet die Frage nach dem "warum".

Warum ist ein automatisches Backup in einen privatsphären geschützten SecureStore die beste Backup Methode für eine SSI Wallet?

Lehren aus der Home-Computer und Mobile Welt
Die Backups von Home-Computer waren Jahrzehnte lang ein wunder Punkt und eine der kritischsten Sicherheits-Bedrohungen. Externe Hard-Disks blieben einfach am Computer angeschlossen und lokale (z.B. Malware), physische (z.B. Feuer) sowie Diebstahl-Risiken blieben nicht mitigiert. Schon in den Nuller-Jahren tauchten «Online-Backup Firmen» auf, welche die ganze Harddisk in die Cloud spiegeln wollten Der breite Einsatz scheiterte allerdings daran, dass aufgrund des schlechten Verhältnisses von Disk-Grösse zu verfügbarer Bandbreite das initiale Backup bis zu mehreren Wochen dauerte. Dropbox war eine der ersten Firmen, welche nur Nutzerdaten (und keine System-Daten) in die Cloud stellte. Da die einzelnen Nutzerfiles praktisch nie änderten, war ein Backup viel einfacher und schneller ausgeführt und konnte auch gut im Hintergrund ausgeführt werden. Das Teilen und der universelle (geräteübergreifende) Zugriff waren massgeblich für den Erfolg ausschlaggehend.
Ein weiteres erfolgreiches Beispiel findet sich beim Backup von Mobile-Telefonen. Ein regelmässiges manuelles Backup (zBsp auf einen Home-Computer) ist eine lästige Angelegenheit, die nur die pflichtbewusstesten und IT-affinen unter uns sauber ausführen. Zusätzlich erschwerend kamen Versions-Abhängigkeiten und entsprechende Inkompatibilitäten dazu. Die Mobile-Anbieter (allen voran Apple) helfen den Benutzern heute mit (i)Cloud Storage und Backup, das im Hintergrund abläuft und bei extrem niedrigen Kosten höchste Verlässlichkeit bietet. Da jedes Programm für das Lesen und Schreiben der eigenen Daten in die Cloud selber verantwortlich ist, fallen beispielsweise die erwähnten OS-Versions-Restriktionen nicht mehr ins Gewicht.

Lehren aus der Server Backup Welt
Der Autor hat bei verschiedenen Grossfirmen Audits für die Funktionstüchtigkeit von Back-infrastrukturen gemacht. Die Resultate waren jeweils erschreckend. Vor allem bei Backup-Infrastrukturen mit beweglichen und auswechselbaren Speichermedien (Tape, USB Disks) fielen die Recoverability Tests schlecht aus. Menschliches Versagen bei manuellen Arbeiten und Hardware-Fehler waren dabei die Hauptursachen. Hinzu kamen Fehler in der Definition von Backup-Frequenz und Löschzyklus, ebenso sowie Beschädigungen und Verlustrate beim Transport von beweglichen und auswechselbaren Speichermedien (z.B. beim Verschieben in sichere Aufbewahrungsorte).

Erfahrungen mit Peer-to-Peer Speicherung
Schon in den Nuller-Jahren erschienen die ersten Datenverteilungsmechanismen (zum Beispiel Wuala), welche initial auf ein Peer-to-Peer Mechanismus setzten. Da auch bei sehr hoher Redundanzraten die online Verfügbarkeit der eigenen Daten nicht im notwendigen Masse garantiert werden konnte, setzen auch diese Dienstleister wieder auf zentrale Kopien der End-Benutzer-Daten.

Lehren aus der Crypto-Wallet Welt
Verschiedene Statistiken aus der Crypto-Welt vermuten, dass bis heute insgesamt über 4 Mio. BitCoins verloren gingen, was einer Rate von mehr als 20% entsprechen würde. Typischerweise gehen die BitCoins verloren, weil der zum Wallet gehörige Privatekey verloren hat. Die Angst vor einem solchen Totalverlust und die Benutzerfreundlichkeit von Cloud Anbietern wie CoinBase führte auch dazu, dass heute die meisten Kleinanleger sich «Wallet-Anbietern» anvertrauen und auf eine rein lokale Speicherung des Key-Materials verzichten. Damit führen eigene Fehler nicht mehr automatisch zu Totalverlust.

Case-Study: DSwiss e-Safe Lösungen
Diese Erkenntnisse haben DSwiss dazu gebracht, bei SecureSafe wie auch bei allen anderen ihrer Lösungen auf ein dreifach-redundantes, Disk-basiertes Speichersystem zu setzen. Dieses wird automatisiert kontrolliert und regelmässig manuell beübt. Der Setup nutzt 3 verschiedene Lokationen, sprich jeder Datensatz wird automatisch und instantan auf 3 unabhängigen Systemen gespeichert.

Damit die Vertraulichkeit der gespeicherten Daten gewährleistet werden kann, ist zudem und insbesondere eine Verschlüsselungs-Architektur notwendig, welche den Grundsätzen von «Privacy Protection» und «Datenminimierung» folgt. DSwiss hat hier auf ein selbst entwickeltes Modell gesetzt, welches den Zugang zu gespeicherten Daten in Abwesenheit des Benutzers kryptographisch verhindert. Die frühe Publikation des Modells hat sich als positive vertrauensbildende Massnahme herausgestellt.

SecureSafe setzte initial auf reinen Online-Zugriff, unter anderem weil dadurch die Erhaltung der Datenkonsistenz vereinfacht wurde und für reinen Web-Zugriff kein Offline-Access notwendig schien. Durch die starke Verbreitung von mobilem Access und der damit verbundenen reduzierten Zuverlässigkeit des Netzwerks (vor allem international) ergaben sich neue Anforderungen. Gewisse Use-Cases benötigen aus UX-Gründen eine sehr tiefe Latenz (z.B. das automatische Einfügen von Passwörtern), weshalb die Lösung um automatisch erstellte, lokale verschlüsselte Cache-Kopien erweitert wurde.

DSwiss führte zudem seit dem Start von SecureSafe Zusatz-Dienstleistungen wie eine Datenvererbung ein. Datenvererbung schützt vor dem Totalverlust von digitalen Assets, falls der Besitzer handlungsunfähig wird oder sogar verstirbt. Solche Zusatzdienstleistungen von Dritten können nur in einem Modell mit automatischer, zentraler und privatsphärengeschützter Speicherung sinnvoll angeboten werden. Im Laufe der Jahre kamen verschiedene spezialisierte Anbieter für digitale Datenvererbung auf den Markt, die allermeisten von ihnen verschwanden jedoch wieder. Dies unter anderem auch, weil sie automatische und regelmässige Updates der Daten nicht unterstützten, was jedoch absolut essentiell für die Nützlichkeit solcher Zusatzdienste ist.

Konklusion für SSI Wallets
SSI Wallets beinhalten Daten, welche höchste Ansprüche an alle Sicherheits-Eigenschaften (Confidentiality, Availability, Integrity) stellen. Vertraulichkeit und Integrität können durch rein lokale Wallets erfüllt werden, nicht jedoch die Verfügbarkeit. Diese ist dann nicht mehr gewährleistet, wenn das speichernde Gerät verloren, bzw kaputt geht, oder ersetzt wird. Diese Lücke kann durch eine automatische Online-Speicherung (unter Beibehaltung der lokalen Speicherung) geschlossen werden. Damit durch diese Ergänzung die Vertraulichkeit der gespeicherten Daten nicht reduziert wird, ist es jedoch unabdingbar, dass der Online-Speicher höchste Ansprüche an diese erfüllt. Hierzu gehört nicht nur ein starker kryptographischer Schutz der Daten «at rest», sondern auch Schutzmassnahmen «in transit» sowie «in use». Hierzu gehören beispielsweise ein sicheres Memory-Management ohne Caching auf persistenten Medien, strikte Regeln was das Logging von Informationen betrifft sowie eine konsequente Reduktion von jeglichem Datenfluss auf das absolute Minimum.

[grt-dti]

ich würde gerne applaudieren, aber das gibt's nur bei LinkedIn.......
Für den "Otto-Normalo" bin ich absolut bei Ihnen @tobiaschristen - genau diese Erfahrungen im Umgang mit Backups bei "normal IT-verständigen Menschen" kann ich nur bestätigen; bei den Firmen sah/sieht es etwas anders aus, aber da hing es immer vom IT-Management, dessen Fachkompetenz und Motivation ab.
Die Frage ist: was ist mit denen "Nicht-Otto-Normalo", die zwar ein Backup aber eben keines bei einem (potentiell kompromittierbaren) Anbieter wollen? Gibt es die überhaupt? Das hängt wahrscheinlich massgeblich vom "Leumund" des Anbieters und seiner Lösung ab.....

[AnAnalogGuy]

Bitte die Rand- resp. Metadaten nicht vergessen. Diese mögen im Einzelfall punkto Privacy und Information Security eine untergeordnete Bedeutung haben, werden aber, wenn man alle E-IDs zusammen zentral in ein cloud repository packt, problematisch. Ein Stichwort dazu ist "Seitenkanalattacken". Ich möchte daher anregen, mal strukturiert eine Risiko- und Impact-Analyse im Zusammenhang mit einer solchen zentralen cloud-Lösung zu machen.

[mcgfeller]

Lieber @tobiaschristen , liebe Community

Ich schreibe dies als Privatperson und als Laie in SSI: Ich habe Sorgen bei den von Ihnen beschriebenen Backup-Speichern (und Password-Managern) mit 2FA: Was passiert, wenn ich den einen Faktor (den ich wissen muss) auf Grund eines medizinischen Ereignisses vergesse?

Kann hier die e-ID helfen – die ausstellenden Behörden kennen mich und können mich eindeutig identifizieren? Kann ich den Zugang mit einer e-ID verknüpfen, ohne alle meine Daten zu verknüpfen (und doch ohne zusätzliches, nicht wiederherstellbares Master-Geheimnis)?

Ich erinnere mich an eine Begegnung mit ärmeren US-Bürgern, die bei einem Hausbrand alle Dokumente inkl. Geburtsurkunde verloren haben, und diese mangels zentralem Einwohner-Register nicht wieder herstellen konnten. Dies kann in der Schweiz nicht passieren, aber kann ich mit der Identität auch meine Daten wieder haben?

Beste Grüsse
Martin Gfeller

[AnAnalogGuy]

Hallo Herr Gfeller

die kurze Antwort: Nein, die E-ID kann für das beschriebene Szenario keine Lösung bieten.

Was ist die E-ID, was ist sie nicht?
Die E-ID ist die digitale Repräsentation der allseits bekannten physischen ID. Sie kann im Grundsatz nicht mehr und nicht weniger als eine physische ID. Der einzige Unterschied liegt darin, dass die E-ID einen Mechanismus bietet, der eine Identifikation über ein digitales Medium ermöglicht.

Es gilt noch zu bemerken, dass die E-ID vorerst wohl "nur" im Inland eingesetzt werden kann, da ihr Anerkennung im Ausland erst auf Ebene Staatsvertrag mit anderen Staaten zu vereinbaren ist. Dies ist nur dann möglich und sinnvoll, wenn alle Beteiligten über technisch kompatible (nicht zwingend identische) Lösungen für digitale Nachweise verfügen, damit diese überhaupt gegenseitig gelesen und verarbeitet werden können. Dies ist derzeit und wohl auch auf absehbare Zeit (noch) nicht der Fall.

Die E-ID ist ein Identitätsnachweis, kein Login, kein User Account, kein Passwort und kein Authentisierungsverfahren. Sie kann in Authentisierungsverfahren verwendet werden, wie zB. bei AGOV, genauso wie die physische ID in Authentisierungsverfahren verwendet wird, wenn jemand ein entsprechendes Authentisierungsverfahren in seinem Anwendungsszenario implementiert.

Denken Sie an das Verfahren zur Eröffnung eines Bankkontos. Dort weisen Sie die ID als Identifikationsnachweis vor, damit die Bank dann ein Konto (defacto ein User Account) für Sie erstellen kann. Danach authentisieren Sie sich z.B. am E-Banking mittels Username und Passwort und bei 2FA über ein weiteres Token. Die E-ID spielt nach der Identifkation keine Rollen mehr, sie ist nicht Teil der Authentisierung und nicht Teil der Authorisierung in der Anwendung.

Rücksetz-Prozesse in Authentisierungsverfahren
Die E-ID kann folglich keine Probleme, die mit User Accounts und der Authentisierung an Anwendungen (offline und/oder online) lösen, es ist nicht ihre Anwendungsdomäne. Die jeweiligen Anwendung selbst muss entsprechende Passwort-Rücksetz-Prozesse definieren.

In solchen Prozessen kann eine ID, physisch oder elektronisch, als Identitätsnachweis dienen. Es ist also in unserem Beispiel an der Bank, zu definieren, ob ihr das Vorweisen einer ID oder einer E-ID ausreicht, um für ein Benutzer-Account einen Passwort-Reset durchzuführen - sofern es keine gesetzlichen Regulierungen gibt, die das verbieten würden. Grundsätzlich sollte die E-ID hierfür überall dort einsetzbar sein, wo die physischen ID heute schon eingesetzt wird oder werden darf. Mit dem grossen Aber, dass es sich hier um nationale Gesetzgebung handelt, die in anderen Ländern keine Rechtswirksamkeit hat, solange entsprechende Staatsverträge fehlen. Und mit dem Hinweis darauf, dass beim Vorweisen einer physischen ID ein Foto-Abgleich mit der vorweisenden Person möglich ist, bei der E-ID nicht, ohne dass man ein weiteres Verfahren hierfür implementierte (Video-Ident). Letzteres wird meiner Einschätzung nach dazu führen, dass E-IDs für Rücksetzungsverfahren in kritischen Bereichen alleine schon aus haftungsrechtlichen Gründen nicht eingesetzt werden.

2-Faktor-Authentisierung
Bei der klassischen 2-Faktor-Authentisierung erfolgt die Authentisierung über ein Passwort und ein physisches resp. physisch gebundenes Token. Ein Faktor ist folglich "Wissen", das anderen "Haben". Physisch gebunden heisst, dass das Haben Token von einem physischen Gerät bereitgestellt wird, von dem mit ausreichender Sicherheit ausgegangen werden kann, dass nur der legitime Inhaber Zugang hat. Beim E-Banking ist das meist das Smartphone, auf das dann ein sms oder ein Push-Alert mit einem Einmal-Code geschickt wird.

Die E-ID ist zwar physisch an ein Gerät gebunden (Holder Binding - eine aktuell allerdings nicht vollständig ausgereifte Methode, die auf der Sicherheitsarchitektur von Smartphones beruht, die, wie es u.a. die EPFL Ende letzten Jahres zeigte, nicht ausreichend sicher ist), aber sie ist kein Einmal-Code. Damit erfüllt sie eine elementare Anforderung an den Haben Token in einem 2FA Prozess nicht. Der Verzicht auf ein Passwort, oder generell auf das "Wissen", wie von Ihnen angedacht, hätte zur Folge, das 2FA Verfahren auf einen Faktor Haben zu reduzieren. Wäre das Haben Token dann auch noch mit der ID identisch, würden Sie mit Verlust des Haben Tokens gleichzeitig auch noch die Möglichkeit zum Identitätsnachweis verlieren (Verlust heisst hier nicht nur Verloren sondern auch Gestohlen oder Kompromittiert). Wird die ID in einem Rücksetz-Verfahren verwendet, könnten Sie dieses Rücksetz-Verfahren nicht durchführen. Der Einsatz einer ID zu Authentisierung ist daher nicht nur nicht möglich, sondern das letzte, was man machen sollte und wollte.

Das E-ID Ökosystem
Die E-ID wird als eine Anwendung auf dem E-ID Ökosystem bereitgestellt. Das Ökosystem kann verwendet werden, um beliebige Nachweise zu erstellen. Es wäre denkbar, Ihre Anforderung einer Authentisierung ohne den Faktor Wissen mit einer entsprehenden Anwendung auf dem Ökosystem zu implementieren, indem man einen zweiten Haben Faktor einführt, auf welchem dann ein Einmal-Token, das an eine Identität gebunden ist, ausgestellt wird. Dieser zweite Token dürfte dann aber nicht an das gleiche physische Gerät gebunden sein wie der erste Haben Token. Das Smartphone kann daher in einem solchen Szenario nur einmal verwendet werden. Das ist in der Regel nicht praktikabel und wirft zudem eine Reihe von Folgeproblemen auf (z.B. dürfen beide Geräte beispielsweise auch nicht durch die gleichen biometrischen Daten der gleichen Person zugangsgeschützt sein, ansonsten man den Token schwächt). Zudem müsste das zweite Token laufend erneuert werden, damit man dessen Gütligkeit zeitlich begrenzen kann (andernfalls wäre das zweite Token defacto ein Einmal-Token).

Kurzum: Auch dieser Weg führt nicht zu einer praktikablen Lösung.

[mcgfeller]

Hello @AnAnalogGuy : Ganz herzlichen Dank für Ihre kompetenten und ausführlichen Erläuterungen. Sie helfen mir sehr, die Situation einzuschätzen. Ich hoffe, die Industrie findet eine gute Lösung für die Rücksetz-Prozesse, zumindest im nationalen Rahmen. Wenn ich dazu z.B. auf einer Poststelle, Bank oder Versicherung vorbeigehen müsste, störte mich das nicht - es geht ja um ganz wichtige "Master"-Zugriffe, nicht um das Github-Passwort.

Nochmals besten Dank und freundliche Grüsse
Martin Gfeller

[tobiaschristen]

Lieber Martin, Ich verstehe Deine Frage wie folgt:  - Szenario:  ein Online-Speicher wird als Backup bzw als Online-Speicher für SSI Verifiable Credential (bzw entsprechende Human Readable PDF Versionen) hinterlegt.  Die Wallet und der Online-Speicher sind dabei unabhängige Systeme die von 2 unterschiedlichen Provider zur Verfügung gestellt werden können. Bei der initialen Verknüpfung der Systeme erfahren die 2 Systeme den Identifier der Person im jeweils anderen System.  Meine Annahme wäre dazu, dass die nachfolgende Ablage der Daten über eine API basierte Einlieferung stattfindet.  Falls der Benutzer also zum Zeitpunkt der Verknüpfung noch keinen Online-Speicher besitzt,  eröffnet er seinen Speicher in diesem Moment und wählt eine Authentisierungs-Credential (e.g. UID/PW/2FA oder FIDO).   Nun ist die Frage wie der Benutzer, wenn er die Authentisierungs-Credential verliert je wieder an seine (e.g. automatisch eingelieferten) Daten kommt.    - Hersteller von privatsphären-geschützten Online-Speicher wie Apple, SecureSafe, Proton offerieren für die Account Wiederherstellung einen "Recovery-Code". Typischerweise wird aus dem Code nach Eingabe durch den User in einer dedizierten Recovery (Web-)App ein Schlüssel generiert der zur Entschlüsselung der Key-Chain verwendet werden kann. Die Key-Chain enthält alle Schlüssel die verwendet wurden um die einzelnen eingelieferten Datensätze zu verschlüsseln.  Es gibt auch Hersteller, welche es ermöglichen den Recovery-Code in 2-3 Stücke zu zerteilen und diese getrennt an vertrauenswürdige Bekannte zu übergeben.  Bei SecureSafe wird auch der "Daten-Vererbungsmechanismus" über einen ähnlichen Mechanismus wie der oben erwähnte Recovery-Code abgehandelt.  - Es wäre auch denkbar, dass der RecoveryCode bei vertrauenswürdigen Anbieter (e.g. Escrow Agenturen, Bundes-Agentur, Bank,...) hinterlegt wird und dort mit vorweisen der eID wieder abgeholt werden kann. Hoffe dies addressiert Deine Frage?   Herzliche Grüsse Tobi 

…

On 2025-02-01T15:56:56.000+01:00, Martin Gfeller ***@***.***> wrote: ***@***.*** [https://github.com/tobiaschristen] , liebe  Community    Ich schreibe dies als Privatperson und als Laie in SSI: Ich habe  Sorgen bei den von Ihnen beschriebenen Backup-Speichern (und  Password-Managern) mit 2FA: Was passiert, wenn ich den einen Faktor  (den ich wissen muss) auf Grund eines medizinischen Ereignisses  vergesse?    Kann hier die e-ID helfen – die ausstellenden Behörden kennen  mich und können mich eindeutig identifizieren? Kann ich den Zugang  mit einer e-ID verknüpfen, ohne alle meine Daten zu verknüpfen  (und doch ohne zusätzliches, nicht wiederherstellbares  Master-Geheimnis)?    Ich erinnere mich an eine Begegnung mit ärmeren US-Bürgern, die  bei einem Hausbrand alle Dokumente inkl. Geburtsurkunde verloren  haben, und diese mangels zentralem Einwohner-Register nicht wieder  herstellen konnten. Dies kann in der Schweiz nicht passieren, aber  kann ich mit der Identität auch meine Daten wieder haben?     Beste Grüsse   Martin Gfeller    —  Reply to this email directly, view it on GitHub  [#19 (comment)],  or unsubscribe  [https://github.com/notifications/unsubscribe-auth/AX3PU5PWWXW33IDV666EI732NTODPAVCNFSM6AAAAABTQKW522VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMBSGY2DMOI].  You are receiving this because you were mentioned.Message ID: ***@***.***>

[mcgfeller]

Hallo @tobiaschristen, herzlichen Dank - ja das adressiert meine Frage.

Vor allem der dritte Ansatz dünkt mich für ein bereiteres Publikum interessant, mit Prozessen, die z.B. auch das Erben und Vollmachten integrieren. (Wer allerdings mit Bankensystemen zu tun hat, weiss, dass Vollmachtsprozesse sehr kompliziert sein können).

Vielen Dank und herzliche Grüsse
Martin