Zusammenfassung

  • vCon overview Revision 02 und core Revision 04 sind weiterhin Internet-Drafts in Arbeit. Der Ersteller bestimmt den Gesprächsumfang; alle vier Hauptteile des Containers sind optional.
  • JWS belegt die Integrität des signierten Payloads und innerhalb einer Vertrauenspolitik den Besitz des Signaturschlüssels. Vollständige Erfassung, richtige Personenzuordnung, wirksame Einwilligung oder zutreffende Analyse folgen daraus nicht.
  • Eine amended-Kette bewahrt signierte Zustände, kürt aber nicht automatisch die jüngste Version zur Wahrheit. Entscheidungen brauchen zusätzlich ein Register, das jede Behauptung an Quelle, Umfang, Zweck und befugte Stelle bindet.

Im Prüfbericht ist zunächst alles grün. Drei vCon-Versionen bilden eine Kette: Aufnahme, Transkript, danach Namenskorrektur und Stimmungsanalyse. Jede JWS ist gültig, die jüngeren Fassungen nennen den Vorgänger in amended, und die SHA-512 der erreichbaren Audiodatei stimmt mit content_hash überein.

Erst die Sachprüfung öffnet die Lücken. Ein zweiter Audiokanal liefert 403. Den Kontonamen hat nicht das Authentisierungssystem, sondern der Transkriptionsdienst einer Person zugeordnet. vendor nennt den Analyseanbieter, aber kein Modell, keine Sprache und keine Konfiguration. Die dokumentierte Einwilligung bezog sich auf Aufzeichnung und Qualitätssicherung, nicht auf eine Personalentscheidung.

Die Kryptografie hat nichts Falsches gemeldet. Sie zeigt, welcher Sicherheitsbereich sich auf welche Bytes festgelegt hat. Sie zeigt nicht, ob diese Bytes das ganze Gespräch abbilden und ob jener Bereich jede darin stehende Aussage machen durfte.

draft-ietf-vcon-overview-02 trägt das Datum 30. September 2026, draft-ietf-vcon-vcon-core-04 den 7. September. Beide sind Arbeitsdokumente der IETF-Arbeitsgruppe Virtualized Conversations, keine RFCs und keine abgeschlossenen Standards. Sie entwerfen einen JSON-Container, der zwischen Kommunikationsplattformen, Analysediensten und Sicherheitsbereichen wandert. Gerade diese Portabilität macht präzise Vertrauensgrenzen notwendig.

Hinter „verifiziert“ stecken fünf Urteile

Integrität fragt, ob das Payload unverändert ist. Signatorkennung fragt, welche Identität Schlüssel und Zertifikatskette tatsächlich binden. Erfassungsprovenienz fragt, welches System ein Element beobachtet, erzeugt oder verändert hat. Semantische Wahrheit betrifft Namen, Zeiten, Transkripte und Schlussfolgerungen. Befugnis entscheidet, ob der Akteur Daten erheben, ändern, offenlegen oder für diesen Zweck nutzen durfte.

JWS beantwortet die erste Frage und unterstützt bei passender Trust Policy die zweite. Die vCon-Struktur kann Evidenz für die dritte mitführen. Die beiden letzten bleiben Entscheidungen über die Welt außerhalb des Payloads. Auch eine falsche Aussage lässt sich korrekt signieren; auch eine wahre Aussage kann unzulässig verwendet werden.

Ein globales Label „Gespräch verifiziert“ verwischt das. Besser sind getrennte Zustände: Payload-Integrität gültig, Zertifikatskette akzeptiert, Erfassungsabdeckung unbekannt, Identitätsaussage ungeprüft, Zweck nicht freigegeben.

Der Ersteller zieht die Gesprächsgrenze

Das overview behandelt ein Gespräch als Definition. Ein vCon kann eine einzelne Aufnahme oder den Weg von einer Nachricht über einen Anruf bis zur Folge-E-Mail umfassen. Bei SMS existiert oft keine natürliche Sessiongrenze; jemand muss sie setzen.

parties, dialog, attachments und analysis sind sämtlich optional. Eine Aufnahme ohne definierte Beteiligte kann gültig sein. Der core unterscheidet recording, recording-set, text, transfer und incomplete und erlaubt Platzhalter. Ein Recording kann nur einen Call-Leg oder einzelne Kanäle darstellen und muss nicht alle Personen nennen.

Das ermöglicht Datensparsamkeit und schrittweise Einführung. Es verhindert zugleich, aus Schema-Gültigkeit Vollständigkeit abzuleiten. Eine Lücke kann legitim minimiert, technisch verursacht oder interessengeleitet ausgewählt sein. Die Signatur friert die Auswahl ein; sie beweist nicht, dass außerhalb nichts Relevantes liegt.

Für folgenschwere Nutzung braucht es eine Scope-Erklärung: Beginn, Ende, Kanäle, Transfers, Quellsysteme, bekannte Lücken, Aufnahmepolitik und verantwortliche Stelle. Call-Control-Ereignisse, Message IDs, Recorderstatus und fremde Logs können sie stützen.

Das overview nennt Dialog „ground truths“. Gemeint ist Primärmaterial im Gegensatz zur abgeleiteten Analyse. Eine echte Aufnahme kann trotzdem unvollständig sein oder einer falschen Person zugeschrieben werden.

Ein Party Object ist noch kein Identitätsnachweis

Party Objects können Namen, Telefon, E-Mail, SIP URI, DID, UUID und Ort enthalten. validation beschreibt die Prüfmethode, ohne die eigentlichen Prüfdaten offenzulegen. Das ist datensparsam, überträgt die Bewertung aber an den Empfänger.

Steht dort „mit Zugangsdaten validiert“, belegt die Signatur nur, wer diese Aussage abgegeben hat. Welche Zugangsdaten, welcher Zeitpunkt, welches Assurance-Niveau und welcher Account-Lebenszyklus bleiben offen. Jede verwendete Identitätsaussage muss an Prüfereignis, Evidenzreferenz, Zeit und verantwortlichen Bereich gebunden werden.

Auch eine dauerhafte UUID gilt zunächst nur im Namespace ihres Herausgebers. Sie korreliert vielleicht einen Agenten intern, wird aber durch Portabilität nicht universell. Ändert eine neue Version einen Alias in einen bürgerlichen Namen, braucht der Signator Befugnis für Identitätsänderungen, nicht bloß einen gültigen Schlüssel.

Ein Hash kann länger leben als sein Beweisstück

Dialog, Anhang und Analyse dürfen inline oder per HTTPS referenziert werden. content_hash und SHA-512 erlauben zu prüfen, ob abgerufene Bytes den signierten entsprechen.

Der core lässt sichere Speicherung, Zugriffskontrolle und Credential-Austausch für externe Daten ausdrücklich außerhalb seines Umfangs. Eine URL kann 403 oder 404 liefern; Retention kann die Datei entfernen. Der Hash bleibt richtig, während der Inhalt nicht mehr prüfbar ist.

Drei Zustände müssen getrennt werden: signierte Referenz intakt, Objekt verfügbar, Nutzung für den aktuellen Zweck erlaubt. Dateisicherheit, Dekodierung und zeitliche Abdeckung kommen hinzu.

Wer nur vCon und Hash archiviert, bewahrt die Bindung an ehemals vorhandene Bytes, nicht die Fähigkeit zur Nachprüfung. Die Organisation muss Bytes kontrolliert archivieren, dauerhaften Zugriff sicherstellen oder den Verfall der Evidenz ausdrücklich akzeptieren.

Herkunft einer Analyse ist kein Gütesiegel

Analysis Objects können Transkript, Übersetzung, Zusammenfassung, Sentiment oder Bericht enthalten. Der core vereinheitlicht nicht alle Formate; vendor ist erforderlich, product und schema sind möglich. Das overview weist auf erhebliche Qualitäts- und Interpretationsunterschiede hin.

Diese Felder benennen Quelle und Format, nicht zwingend Modellversion, Prompt, Locale, Schwelle, Vorverarbeitung, Eingabestand oder menschliche Korrektur. Ein signiertes Sentiment kann authentisch vom genannten Anbieter stammen und dennoch falsch oder für eine Personenentscheidung ungeeignet sein.

Abgeleitete Aussagen brauchen einen eigenen Beleg: Input-Indizes und -Hashes, vendor, product, schema, Modell- oder Regelversion, Konfiguration, locale, Output-Hash, Bedeutung der Konfidenz, menschliche Freigabe und erlaubter Zweck. Dieses Evidenzregister ist Daniel Kades Betriebsvorschlag, keine normative Forderung der Drafts.

Die Signatur bewahrt, was das System ausgegeben hat. Sie wandelt Provenienz weder in Richtigkeit noch in Entscheidungsbefugnis um.

Einwilligung hat Zweck und Zeit

Das overview behandelt Einwilligung und Provenienz als Kontext. Privacy Primer und Lawful-Basis-Draft untersuchen Hinweis, Zweck und Jurisdiktion. Kein Dokument macht aus einer vCon-Signatur einen universellen Rechtsnachweis.

Eine Einwilligungsbehauptung braucht betroffene Person, Identifizierung, Methode, Zeitpunkt, Policy-Version, Zwecke, Jurisdiktion und Widerruf. Erfassung, Analyse, Weitergabe und Aufbewahrung können unterschiedlichen Grundlagen folgen; die Grundlage muss nicht Einwilligung sein. Dieser Beitrag gibt keine Rechtsberatung, sondern beschreibt die Evidenzgrenze.

Eine gültige Signatur authentisiert die historische Aussage. Der Empfänger prüft weiterhin, ob der Signator sie machen durfte, ob sie den heutigen Zweck umfasst und was ein Widerruf auslöst.

Wird morgen widerrufen, soll die Signatur von gestern gültig bleiben: Geschichte darf nicht umgeschrieben werden. Geändert wird die aktuelle Verarbeitungsbefugnis.

Amendments bewahren Zustände, nicht die beste Wirklichkeit

Eine direkte Änderung am signierten vCon bricht die Signatur. Daher entsteht eine neue Instance Version als Deep Copy der vorherigen, ergänzt oder korrigiert, mit amended-Verweis auf UUID und optional URL und Hash des Vorgängers. Verschiedene Sicherheitsbereiche können nacheinander signieren.

Die Kette bewahrt Verpflichtungen. Sie beweist nicht, dass vollständig kopiert, Indexbedeutung erhalten, korrekt geändert oder befugt gehandelt wurde. Der Empfänger muss den Vorgänger abrufen und prüfen, Objektunterschiede vergleichen und die Autorität jeder Änderung bewerten.

Bei Redaction ist die Grenze besonders sichtbar. Der core lässt die Methode außerhalb des Umfangs und weist die Assurance dem Ersteller und Signator der redacted Version zu. Er kann ehrlich signieren und dennoch persönliche Daten in Attachment, Analysis oder unbekannter Extension übersehen.

„Neueste signierte Fassung“ darf nicht automatisch „autoritative Fassung“ heißen. Ein Analysedienst darf möglicherweise ein Transkript hinzufügen, aber keine Person umbenennen.

Extension-Kompatibilität hängt von der Aufgabe ab

Extensions können Felder hinzufügen, Bedeutung ändern oder Parameter außer Gebrauch setzen. Inkompatible Extensions müssen in critical stehen; ein nicht unterstützender Processor darf nicht weiterarbeiten, sondern muss ablehnen oder melden.

Ein Transcriber kann ein unbekanntes Feld eventuell ignorieren. Ein Redactor muss womöglich jedes datenführende Feld verstehen, um nichts Persönliches stehen zu lassen. Derselbe vCon kann für die erste Aufgabe geeignet und für die zweite unzulässig sein.

Zu protokollieren sind Extensions, critical, Registry- und Softwareversion, Operation sowie die Begründung für Ignorieren oder Ablehnen. Erfolgreiches JSON-Parsing ist keine semantische Interoperabilität.

Das Gesprächsevidenzregister steht neben dem Container

Jede Entscheidung bindet UUID, Payload-Hash und Form; Umfang und Lücken; beitragende Systeme; Signator, Zertifikatsstatus und Policy; Identitätsevidenz; Aufnahmeabdeckung; externe Erreichbarkeit und Berechtigung; Analyseinputs und Konfiguration; Zweckbefugnis; Extension-Fähigkeit; Vorgänger und Differenz; Verantwortlichen und Rückweg.

Beobachtung und transportierte Aussage bleiben getrennt. „SHA-512 der abgerufenen Bytes stimmt“ wurde beobachtet. „Identität durch Credentials validiert“ bleibt bis zur Ereignisbindung eine Payload-Aussage. „Für Qualität bis Datum X freigegeben“ ist eine lokale Entscheidung.

Der Ablauf lautet: Umfang -> Abruf -> Bytes -> Signator -> Befugnis -> Extensions -> Abstammung -> Aussagen -> Zweck -> Abhängigkeit -> Widerruf.

Im Ausgangsfall bleiben Signaturen und Hashes gültig. Die vollständigkeitssensitive Entscheidung wartet auf den fehlenden Kanal. Die Identitätsänderung wird isoliert. Sentiment wird archiviert, aber nicht entscheidend verwendet. Historische Einwilligung bleibt echt; der neue Zweck verlangt neue Autorisierung.