Seminar KERI/ACDC – Management- und Architekturbriefing

KERI und ACDC versprechen portable Schlüsselkontrolle und verifizierbare Datenketten, ersetzen jedoch weder Governance noch Fachprüfung noch sicheren Betrieb. Das Briefing schafft eine realistische Entscheidungsgrundlage ohne in Implementierungsdetails zu versinken.

Inhaltsübersicht

• Seminarprofil
• Zielgruppe
• Lernziele
• Seminarinhalte
• Praxisanteile
• Voraussetzungen

Seminarprofil

Der Tag kombiniert verständliche Architekturmodelle mit einem strukturierten Entscheidungsworkshop. Ergebnis ist ein gemeinsames Vokabular, eine Use-Case-Bewertung und ein klar abgegrenzter nächster Schritt.

Zielgruppe

Geschäftsführung, Bereichsleitungen, CIO- und CISO-Organisationen, Enterprise Architects, Innovations- und Programmverantwortliche sowie Compliance-Entscheider.

Lernziele

• KERI und ACDC ohne Marketingverkürzung einordnen
• Nutzen, Grenzen und kritische Vertrauensannahmen benennen
• geeignete und ungeeignete Einsatzfälle unterscheiden
• Governance-, Betriebs- und Integrationsaufwand abschätzen
• Pilot, Vertiefung und Entscheidungsprozess strukturieren

Seminarinhalte

Schritt 1: Ausgangsproblem und Zielbild klären

Die Teilnehmer bestimmen, welche Identitäten, Nachweise und Autorisierungen heute nicht ausreichend überprüfbar, portabel oder automatisierbar sind. Erst danach wird der Technologiebezug hergestellt.

• Geschäftsrisiko formulieren
• Beweisbedarf definieren
• bestehende Lösungen und Lücken erfassen

Schritt 2: KERI verständlich einordnen

Selbstzertifizierende Identifikatoren, Key Event Logs, Rotation, Witnesses und Delegation werden auf Managementebene erklärt. Der Unterschied zu Blockchain, klassischer PKI und zentralem IAM wird herausgearbeitet.

• Kontrollmodell verstehen
• Infrastrukturabhängigkeiten benennen
• Schlüsselkompromittierung realistisch bewerten

Schritt 3: ACDC und Credential Chains einordnen

Authentische Datencontainer verbinden Aussagen mit Aussteller, Schema, Status, Regeln und Quellen. Beispiele zeigen Organisationsrollen, Qualifikationen, Lieferketten- und Mandatsnachweise.

• Herkunft und Autorisierung unterscheiden
• Status und Widerruf berücksichtigen
• Datenminimierung und Prüfbarkeit abwägen

Schritt 4: Governance und Betrieb bewerten

Rollen, Zulassung, Haftung, Schlüsselverwahrung, Verfügbarkeit, Audit und Incident Handling werden als notwendige Teile des Systems bewertet. Technische Dezentralität beseitigt keine organisatorische Verantwortung.

• Owner und Betreiber benennen
• Assurance und Kontrollen bestimmen
• Betriebskosten und Kompetenzbedarf erfassen

Schritt 5: Use Cases priorisieren

Potenzielle Anwendungen werden nach Nutzen, Risiko, Integrationsaufwand, Datenverfügbarkeit und regulatorischem Wert bewertet. Ein Pilot soll eine kritische Annahme prüfen und nicht nur eine Demonstration liefern.

• Bewertungskriterien gewichten
• Pilotumfang begrenzen
• Erfolg und Abbruch messbar machen

Schritt 6: Lern- und Einführungsweg festlegen

Passende Vertiefungsseminare, Architekturarbeit, Prototyping und Governance-Aufgaben werden in eine Reihenfolge gebracht. Abhängigkeiten und Entscheidungstore werden dokumentiert.

• Kompetenzlücken bestimmen
• Entscheidungspunkte terminieren
• Verantwortung für nächste Schritte zuordnen

Praxisanteile

• Use-Case-Landkarte erstellen
• Nutzen-Risiko-Matrix ausfüllen
• Pilot mit Erfolgs- und Abbruchkriterien definieren
• passenden Seminar- und Entscheidungsweg auswählen

Voraussetzungen

Keine technischen Spezialkenntnisse erforderlich. Ein konkreter Geschäfts- oder Transformationskontext ist hilfreich.