Seminar swiyu – DID:tdw, Base Registry und Trust Registry

Die Teilnahme als Issuer oder Verifier setzt eine kontrollierte technische Identität und einen nachvollziehbaren Trust-Onboarding-Prozess voraus. Das Seminar führt durch DID:tdw beziehungsweise die did:webvh-Grundlage, DID-Logs, Base Registry, Proof of Possession, Trust Registry und Schlüsseländerungen.

Inhaltsübersicht

• Zielsetzung
• Zielgruppe
• Voraussetzungen
• Seminarinhalte
• Praxisübungen
• Methodik

Zielsetzung

• DID:tdw und die zugrunde liegenden Prinzipien verifizierbarer DID-Historien verstehen
• DID-Logs und getrennte Verification Methods sicher erzeugen, prüfen und veröffentlichen
• Base- und Trust-Registry-Onboarding einschließlich Proof of Possession durchführen
• DID-Updates, zusätzliche DIDs, Schlüsselrotation und Verifier-Zwecke kontrolliert betreiben

Zielgruppe

swiyu-Administratoren, DevOps, Security Engineers, Issuer- und Verifier-Betreiber, Integrationsentwickler und technische Consultants.

Voraussetzungen

Gute Kenntnisse zu Schlüsselpaaren, JWT, REST, OAuth-basierten APIs und sicherer Dateiverarbeitung. Kommandozeilenerfahrung ist erforderlich.

Seminarinhalte

1. Schritt 1: DID-Methode und Registry-Modell einordnen

   DID:tdw, did:webvh-Konzepte, Self-Certifying Identifier, DID Log, DID Document, verifizierbare Historie und zentrale Bereitstellung im Base-Registry-Kontext werden voneinander abgegrenzt.

2. Schritt 2: Business-Partner- und API-Zugänge vorbereiten

   Partnerzuordnung, API-Abonnements, Client Credentials, Access- und Refresh Tokens, Umgebungen und sichere Ablage werden dokumentiert. Verwaltungszugriffe bleiben von öffentlichen Auflösungsendpunkten getrennt.

3. Schritt 3: DID-Schlüsselrollen planen

   Update-, Authentication- und Assertion-Schlüssel werden nach Zweck, Algorithmus, Zugriff, HSM-Eignung, Rotation und Notfallverwendung festgelegt. Schlüsseldateien erhalten eindeutige Besitzer und Schutzklassen.

4. Schritt 4: DID Log mit der Toolbox erzeugen

   Identifier Space, SCID, Initialeintrag, Verification Methods, Services und Signaturen werden erstellt und lokal geprüft. Ungültige oder unvollständige Logs werden vor dem Upload erkannt.

5. Schritt 5: DID in der Base Registry veröffentlichen

   Identifier-Eintrag, Upload, Statusprüfung, Auflösung und Abgleich des resultierenden DID-Dokuments werden mit kontrollierten Prüfpunkten ausgeführt.

6. Schritt 6: Proof of Possession erstellen

   Nonce, Schlüssel-ID, private Schlüsseldatei, JWT-Erzeugung, kurze Gültigkeit und sichere Übermittlung werden nachvollzogen. Der Nachweis wird nur für den vorgesehenen Onboarding-Vorgang verwendet.

7. Schritt 7: Trust-Onboarding abschließen

   DID, Proof of Possession, Organisationsbezug und Registry-Rückmeldung werden geprüft. Technische Registrierung und fachlicher Trust-Status werden ausdrücklich getrennt bewertet.

8. Schritt 8: Zusätzliche DIDs und Berechtigungen verwalten

   Weitere DIDs, Permission DID, gemeinsame Nonce, mehrere Proofs of Possession und organisationsweite Zuständigkeiten werden ohne Vermischung der Schlüsselrollen umgesetzt.

9. Schritt 9: DID aktualisieren und Schlüssel rotieren

   Vollständiger neuer DID-Stand, Hinzufügen und Entfernen von Verification Methods, Pre-Rotation-Konzept, Upload, Auflösung und Übergangsfrist werden als Change-Prozess getestet.

10. Schritt 10: Trust Statements und Verifier-Zwecke vorbereiten

    Vertrauensbezogene Aussagen, Status, vqPS beziehungsweise Verifikationszwecke und DCQL-Bezug werden so eingeordnet, dass technische Identität, fachliches Vertrauen und angeforderte Daten nachvollziehbar bleiben.

Praxisübungen

• DID-Schlüssel- und Rollenmatrix für Issuer und Verifier erstellen
• DID Log erzeugen, lokal validieren und als DID-Dokument auflösen
• Proof of Possession für einen Onboarding-Vorgang erstellen und prüfen
• Zusätzlichen DID mit mehreren Nachweisen konzipieren
• Schlüsselrotation mit vollständigem Update- und Rückfallplan durchführen

Methodik

Fachvortrag, Kommandozeilen- und API-Labor, DID-Log-Analyse, Registry-Demonstrationen und Fehlerdiagnose. Drei Tage sind erforderlich, weil Identitätserzeugung, Registry-Onboarding und kontrollierte Änderungen jeweils praktisch geübt werden.