Geteilte Team-Identitäten: eine Identität, viele Menschen

Ein Team kann sich eine CardanoWall-Identität teilen, aber eine Identität zu teilen bedeutet, den Identity Seed zu teilen. Eine leichtere Variante davon gibt es nicht.

Den Seed weiterzugeben ist eine vollständige Delegation. Wer ihn besitzt, kann Einträge als diese Identität signieren und versiegelte Einträge entschlüsseln, die an sie adressiert sind. CardanoWall kann den Ablauf über getrennte Konten hinweg angenehm gestalten, aber es kann aus einem Seed keine teilweise, widerrufbare, personenbezogene Befugnis machen. So lässt sich die Kryptografie nicht biegen.

Nutze eine geteilte Identität also nur dann, wenn geteilte Befugnis genau das ist, was du willst.

Was ist eine geteilte Team-Identität?

Es ist eine Label 309-Identität, die von mehr als einer Person oder einem Konto genutzt wird.

Eine Label-309-Identität wurzelt in einem einzigen, 32 Byte großen Identity Seed. Wer diesen Seed importiert, rekonstruiert denselben Signaturschlüssel und dieselben Empfangsschlüssel – in jedem Konto und in jedem kompatiblen Werkzeug. Die Identität ist nicht an ein CardanoWall-Konto gebunden, denn der Seed allein definiert sie.

So könnte eine Redaktion eine „Press Team"-Identität betreiben. Die leitende Redakteurin erzeugt die Identität, speichert den Seed und teilt ihn über einen vertrauenswürdigen Kanal mit ausgewählten Kolleginnen und Kollegen. Jede und jeder importiert den Seed ins eigene Konto und entsperrt ihn mit den eigenen Passkeys. Von da an besitzen sie alle dieselbe kryptografische Identität.

Was kann jeder Seed-Inhaber tun?

Alles, was die Identität tun kann. Der Seed ist die Wurzel, keine eingegrenzte Berechtigung.

Jeder Inhaber kann:

• neue Label-309-Einträge als die Identität signieren;
• versiegelte Einträge entschlüsseln, die an die Identität adressiert sind;
• eingehende versiegelte Einträge lesen, sobald er sie entsperrt;
• den Seed erneut exportieren und weitergeben;
• die Identität in ein anderes kompatibles Werkzeug importieren, etwa die Open-Source-CLI;
• die Empfangsadressen der Identität überall veröffentlichen.

Das ist nicht so, als lade man jemanden mit eingeschränkten Rechten und einem Widerrufsknopf in einen Workspace ein. Es gibt keine Stufe „nur Lesen" oder „veröffentlichen, aber nicht entschlüsseln". Wer den Seed hat, hat die ganze Identität.

Wann ist eine geteilte Identität sinnvoll?

Wenn die Außenwelt eine Identität sehen soll, die für eine Rolle steht und nicht für eine Person.

Vernünftige Fälle sind etwa:

• eine Annahmeadresse einer Redaktion;
• die Beweis-Identität einer Rechtsabteilung;
• ein Kontakt für Sicherheitsmeldungen;
• die Identität eines Prüfungsausschusses;
• die Identität eines Compliance-Teams;
• eine Identität für Unternehmenseinträge;
• die geteilte Identität eines kleinen Projekts.

In jedem dieser Fälle steht die nach außen sichtbare Identität für eine Funktion oder ein Team, und dass mehrere Menschen dahinterstehen, ist genau der Punkt.

Welche Risiken birgt eine geteilte Identität?

Die Zurechnung wird geteilt – und das Gefährdungspotenzial ebenso.

Wenn mehrere Menschen als dieselbe Identität signieren können, sieht ein externer Verifizierer immer nur einen einzigen öffentlichen Ed25519-Schlüssel. Die Chain hält nicht fest, welcher Mensch den Seed verwendet hat. Das kann genau das sein, was das Team will – oder ein echtes Problem für die Rechenschaft, je nach Situation.

Die übrigen Risiken folgen aus derselben Wurzel:

• jedes einzelne Mitglied kann den Seed preisgeben, absichtlich oder versehentlich;
• ein einziges kompromittiertes Gerät kann die ganze Identität kompromittieren;
• ein ehemaliges Mitglied kann nach dem Ausscheiden eine Kopie behalten;
• jeder versiegelte Eintrag, der an die Identität geschickt wird, ist für jeden Seed-Inhaber lesbar;
• es gibt keine Schlüsselrotation – Schlüssel zu wechseln heißt, zu einer neuen Identität zu wechseln.

Geteilte Befugnis funktioniert, aber sie braucht operative Disziplin drumherum.

Wie handhabt CardanoWall das über Konten hinweg?

Jedes Konto behält seine eigene verschlüsselte Kopie der geteilten Identität.

Wenn zwei Personen – nennen wir sie Alice und Bob – denselben Seed importieren, erhält jedes Konto seine eigene Konto-zu-Identität-Verknüpfung und seinen eigenen verschlüsselten Tresor. Alices Passkeys entsperren Alices Tresor; Bobs Passkeys entsperren Bobs. Dieselbe kryptografische Identität erscheint einfach in beiden Konten, ohne geteilten serverseitigen Zustand zwischen ihnen.

Um eine bereits bestehende Identität anzuhängen, muss der Importeur nachweisen, dass er den Seed tatsächlich besitzt – nicht bloß, dass er die öffentlichen Schlüssel kennt, die jeder aus einem Profil oder von der Chain lesen kann. Das Konto signiert eine einmalige Server-Challenge mit dem aus dem Seed abgeleiteten Schlüssel, bevor die Verknüpfung angelegt wird. Das verhindert, dass jemand eine Identität anhängt, von der er nur die öffentlichen Schlüssel kennt, lässt aber einen echten Seed-Inhaber die Verknüpfung trotzdem herstellen.

Anzeigebezeichnungen bleiben pro Konto privat. Alice könnte die Identität „Press Team" nennen; Bob könnte sie „Intake" nennen. Diese Bezeichnungen leben im verschlüsselten Tresor jedes Kontos, niemals in der öffentlichen Identität – deshalb kann kein Konto die Bezeichnung des anderen sehen, und ein Datenbankeinbruch gibt keine davon preis.

Auch die Abrechnung bleibt pro Konto. Wenn Alice aus ihrem Konto veröffentlicht, zahlt Alices Konto. Es gibt kein geteiltes Guthaben, denn kryptografisch ließe sich ohnehin kein Guthaben erzwingen, wenn jeder mit dem Seed veröffentlichen kann.

Lässt sich eine geteilte Identität einer einzelnen Person entziehen?

Nicht kryptografisch – nicht, sobald sie den Seed bereits kennt.

CardanoWall kann die Identität aus dem Tresor eines Kontos entfernen, einen Passkey entfernen oder die Identität in einem bestimmten Konto deaktivieren. Das sind echte Kontrollen auf Service-Ebene, und sie sind wichtig für die Konten, über die du verfügst.

Aber keine davon erreicht eine Kopie des Seeds, die bereits im Passwortmanager von jemandem liegt, auf einem Ausdruck, in der Erinnerung, in einem Backup, in einem Desktop-Werkzeug oder in einem zweiten Konto. Wissen über 32 Byte lässt sich nicht zurückrufen.

Wenn also jemand, der den Seed besessen hat, keine Befugnis mehr haben soll, ist der ehrliche Schritt, eine neue Identität zu erzeugen und die alte auszumustern – und nicht so zu tun, als ließe sich der alte Seed wieder geheim machen.

Wie sieht ein gutes Vorgehen für eine geteilte Identität aus?

Behandle den Seed wie das hochwertige geteilte Geheimnis, das er ist.

Bevor irgendjemand ihn teilt, sollte sich das Team auf Folgendes einigen:

• wer den Seed besitzen darf;
• wie der Seed übertragen wird (persönlich oder Ende-zu-Ende verschlüsselt);
• wo die maßgebliche Backup-Kopie liegt;
• wer die Identität einem Konto hinzufügen darf;
• welche Passkeys den Tresor jedes Kontos entsperren;
• wer unter der Identität veröffentlichen darf;
• was passiert, wenn jemand ausscheidet;
• wann die Identität ersetzt werden muss;
• wo neue öffentliche Schlüssel angekündigt werden.

Schreib das auf, bevor ein Vorfall oder ein Personalwechsel die Entscheidung unter Druck erzwingt.

Sollte ein Team eine einzige geteilte Identität für alles nutzen?

Meistens nicht.

Getrennte Identitäten halten Abläufe sauber und begrenzen Schäden. Ein Unternehmen könnte eine Identität für Sicherheitsmeldungen betreiben, eine weitere für Rechtsbeweise, eine weitere für öffentliche Veröffentlichungen und noch eine für interne Prüfungen.

Diese Trennung begrenzt den Schadensradius. Wird eine Identität kompromittiert, erben die anderen die Kompromittierung nicht automatisch. Außerdem bleiben das Adressbuch und der Whitelist-Modus leichter zu durchdenken, weil jede Identität einen klaren, eng umrissenen Zweck hat.

Was tust du, wenn das Team rotiert?

Erzeuge eine neue Identität. Wissen über den alten Seed lässt sich nicht widerrufen, deshalb ist ein sauberer Schnitt die einzige echte Lösung.

Wenn eine geteilte Identität kompromittiert wird oder ein ehemaliger Inhaber den Zugang verlieren soll, ist der Weg:

1. erzeuge eine frische Identität und speichere ihren neuen Seed;
2. teile den neuen Seed nur mit den Mitgliedern, die ihn weiterhin haben sollen;
3. aktualisiere öffentliche Profile, Empfangsadressen und Kontakte mit den neuen Schlüsseln;
4. deaktiviere die alte Identität in den Konten, über die du verfügst;
5. höre auf, die alten Empfangsadressen zu nutzen;
6. veröffentliche optional einen Eintrag unter der neuen Identität, der die alte ablöst.

Versiegelte Einträge, die bereits an den alten Schlüssel adressiert sind, bleiben für jeden lesbar, der je den alten Seed besessen hat – auch für die Person, von der du dich gerade trennst. Das ist eine Eigenschaft davon, an einen langlebigen öffentlichen Schlüssel zu verschlüsseln, kein Fehler, den du patchen kannst. Plane darum herum; tu nicht so, als ließe sich das Teilen des alten Seeds rückgängig machen.

Die Kurzfassung

Geteilte Team-Identitäten sind mächtig und grobschlächtig.

Sie lassen ein Team eine öffentliche Label-309-Identität über mehrere Konten und Geräte hinweg betreiben. Aber jeder mit dem Seed hat volle Signier- und Entschlüsselungsmacht, und diese Macht lässt sich nicht teilweise gewähren oder stillschweigend entziehen.

Nutze eine geteilte Identität für Rollen, die geteilte Befugnis wirklich brauchen. Nutze getrennte Identitäten, wann immer Rechenschaft, Trennung oder Rotation wichtiger sind.

Weiterführende Lektüre

• Deine Identität ist ein Seed
• Aktiv, deaktiviert, gelöscht: der Lebenszyklus einer Identität
• Wie CardanoWall deine Identität speichert
• Identitäten für sensible Arbeit: Whistleblower-Beweise
• Der Standard, offen einsehbar: label309.org und der Open-Source-Code unter github.com/cardanowall