Zusammenfassung

  • verified=true bedeutet nach RFC 9796, dass der Einfüger des betreffenden Call-Info-Feldes die darin dargestellte Information erfolgreich geprüft hat. Das empfangende Gerät muss diesem Einfüger über eine authentisierte Beziehung vertrauen.
  • Die Aussage gilt für dieses Feld. Sie bestätigt nicht automatisch sämtliche Anruferdaten, den angegebenen Grund, die spätere Unterhaltung oder deren Ergebnis.
  • integrity kann die empfangenen Bytes an einen Hash binden. Herkunft, Aktualität, Verfügbarkeit, Anzeige, menschliche Wahrnehmung und Legitimität brauchen eigene Nachweise.

Die entscheidende Architekturfrage liegt nicht im grünen Symbol, sondern einen Schritt davor: Wer durfte es erzeugen? RFC 9796 beantwortet diese Frage für Rich Call Data in SIP. Der Standard definiert call-reason, verified, integrity und purpose=jcard im Header Call-Info.

Sein Wortlaut lässt wenig Raum für eine pauschale Lesart. verified=true besagt, dass die Partei, die genau dieses Feld aufgenommen hat, die dargestellte Information erfolgreich verifiziert hat. Ob der Empfänger dieser Aussage trauen kann, hängt von seiner Vertrauensbeziehung zur übermittelnden Partei ab.

Das ist eine attestierte Aussage, kein universelles Merkmal des Anrufs. Sie hat einen Aussteller, einen Gegenstand und einen Empfänger.

Der Prüfer wechselt, bevor das Ergebnis den Bildschirm erreicht

RFC 9795 schützt Rich Call Data und Hashes referenzierter Ressourcen in einem PASSporT. RFC 8225 definiert dieses signierte Token auf Grundlage der JWT-Familie aus RFC 7519; RFC 8224 verankert STIR-Identität in SIP.

Ein terminierender Anbieter kann Signatur, Zertifikatskette und Claims prüfen. Das angeschlossene Telefon kann dazu technisch nicht in der Lage sein. RFC 9796 erlaubt dem Anbieter, ausgewählte akzeptierte Ergebnisse in Call-Info zu übersetzen und sie einem authentisierten Gerät an einer vertrauenswürdigen Benutzer-Netz-Schnittstelle zu übergeben.

Damit ändert sich der unmittelbare Zeuge. Der Anbieter kann sagen: „Ich habe das PASSporT geprüft.“ Das Endgerät kann sagen: „Der Anbieter, dem ich vertraue, hat dieses Feld als verifiziert eingefügt.“ Beide Sätze können wahr sein, doch sie beruhen auf verschiedenen Belegen.

Eine belastbare Kette trennt deshalb Kandidatendaten, vorhandenes PASSporT, gültige Signatur und Zertifikate, Claim-Vergleich, lokale Annahme, Transformation durch einen benannten Akteur, konkretes Ausgabefeld, Authentisierung des UNI-Gegenübers, Ressourcenabruf, Hashvergleich, Renderentscheidung, Sichtbarkeit, Handlung, spätere Legitimitätsprüfung und Geschäftsergebnis.

Fehlt verified, soll der Empfänger davon ausgehen, dass die betreffende Information nicht nach RFC 9795 empfangen und geprüft wurde. Das ist kein Betrugsurteil. Es fehlt lediglich dieser bestimmte Nachweis.

Die Karte ist eine Komposition mit mehreren Beweisobjekten

RFC 3261 definiert SIP und Call-Info. Ein gewöhnlicher Anzeigename in From wird durch seine bloße Anwesenheit nicht vertrauenswürdig und kann auf dem Signalisierungsweg ersetzt werden. RFC 9796 gibt ausgewählten Darstellungen eine enger beschriebene Prüfherkunft.

jCard stammt aus RFC 7095, seine JSON-Grundlage aus RFC 8259. Das RCD-Profil beschränkt sich auf ein Entity-Objekt und verlangt Konsistenz zwischen sich überschneidenden Namen, Fotos, Logos, From, P-Asserted-Identity und Symbolen. Das ist nötig, weil eine Anruferkarte mehrere Darstellungen verbindet.

Eine jCard kann in einer data:-URI liegen, in einem MIME-Teil, der über das cid:-Schema aus RFC 2392 angesprochen wird, oder über eine Quelle mit überprüfbarer Integrität abgerufen werden, etwa HTTPS an einer validierten Domain. Eingebettete, nachrichteninterne und externe Ressourcen haben unterschiedliche Verwahrer und Ausfallbilder.

Sogar eine leere data:-URI mit purpose=jcard kann einen verifizierten Anzeigenamen signalisieren. Die kompakte Form beseitigt den Aussteller nicht. Sie macht einen separaten Herkunftsnachweis umso wichtiger.

Ein Hash kennt Bytes, aber keine Absicht

Der Parameter integrity verbindet Algorithmus und Digest mit einer URI-Ressource. Implementierungen müssen SHA-256, SHA-384 und SHA-512 unterstützen. Ein Treffer bestätigt, dass die abgerufenen Bytes dem angekündigten Wert entsprechen.

Er bestätigt nicht, wer die Ressource ursprünglich kontrollierte, ob sie aktuell war, rechtzeitig geladen werden konnte, angezeigt werden durfte oder vom Nutzer gesehen wurde. Er sagt auch nicht, dass die abgebildete Organisation tatsächlich anruft. Byte-Integrität ist kein Identitäts- oder Ergebnisbeweis.

call-reason besitzt eine ebenso klare Grenze. Das Feld ist optional, soll kurz sein, kann gekürzt werden und muss nicht angezeigt werden. Wie der Anrufer es setzt, liegt außerhalb der Spezifikation. „Kontoprüfung“ ist ein übermittelter Grund, kein Beleg für ein Konto oder eine legitime Aufforderung.

RFC 7852 zeigt beim SIP Resource-Priority Namespace dasselbe Muster: Ein Protokollmerkmal hat eine definierte Bedeutung in einem umgebenden Autorisierungsrahmen. Sein amtlich klingender Name ersetzt diesen Rahmen nicht.

Nachträgliche Bearbeitung trennt Anzeige und Prüfung

RFC 9796 verlangt eine einzige konsistente Fassung der RCD-bezogenen Call-Info. Weitere Teilnehmer dürfen sie nicht ändern oder widersprüchliche RCD-Felder hinzufügen. Ohne STIR oder einen anderen Schutz kann eine Veränderung über nicht vertrauenswürdige Verbundnetze nicht als erkennbar vorausgesetzt werden.

Wird ein Foto oder Name nach der Prüfung ausgetauscht, zeigt das Gerät nicht länger denselben Gegenstand. Eine zulässige Transformation braucht daher Belege über Eingang, Prüfrichtlinie, Prüfer, Transformator, Ausgabefeld, Ziel und Zeitpunkt.

Die öffentlichen Unterlagen belegen den Standard, nicht seine Nutzung. Textfassung und XML machen die Norm prüfbar. Informationsseite, Errata und IETF-Verlauf dokumentieren ihren Status. Das IANA-Register der SIP-Parameter dokumentiert die Namen. Keines davon beweist die Implementierung bei einem bestimmten Anbieter oder Gerät.

Das Prinzip des laufenden Codes fragt nach der Komponente, die den Vergleich tatsächlich ausführte. Die minimale Ausgangsspezifikation schafft einen gemeinsamen Koordinationsboden, ohne lokale Politik zur weltweiten Garantie zu machen. Die Trennung der Realitätsebenen hält Registrierung, Kryptografie, Anzeige, Glauben und Resultat auseinander.

RFC 9796 löst damit ein echtes Interoperabilitätsproblem: Komplexe Prüfung kann einem einfachen Gerät zugutekommen. Rechenschaft entsteht, wenn die Übersetzung sichtbar bleibt und der Einfüger nicht hinter seinem Symbol verschwindet.

Quellen