Zusammenfassung

  • Die Open Cloud Mesh Working Group hat die Arbeit am Integrationsprotokoll angenommen; draft-ietf-ocm-integration-protocol-00 erschien am 11. September 2026. Der Text ist weiterhin ein veränderlicher Internet-Draft, kein RFC.
  • Drei Betriebsarten verteilen Zustand, Verfügbarkeit und Widerruf unterschiedlich zwischen OCM Server und Protocol Server. Auch die Token-Ausgabe kann an einen eigenen Server delegiert werden.
  • Die empfangende Seite soll diese Aufteilung nicht erkennen müssen. Daniel Kade schlägt deshalb eine geschützte lokale Verantwortungslandkarte vor; sie ist keine Forderung des Entwurfs.

Ein WG-Dokument ist noch kein fertiger Standard

Die Datatracker-Historie vermerkt am 11. September die neue WG-Version und den Ersatz der individuellen Entwurfsreihe. In der Nachricht zum Ergebnis bezeichnet der Vorsitz die angenommenen Dokumente als Ausgangspunkte, die sich weiterentwickeln werden. Die Working Group übernimmt also die Arbeit; daraus folgen weder IETF-Zulassung noch Einsatznachweis.

Der WG-Entwurf 00 trennt die föderative Rolle von der Protokollausführung. Gegenüber der Föderation bleibt der OCM Server der sendende Server. Dahinter können Protocol Server WebDAV, SSH/SFTP oder eine Webanwendung bereitstellen, auch mit anderer Software und auf anderer Infrastruktur.

Selbst der Token-Endpunkt darf ausgelagert werden. In einer beschriebenen Topologie behält der OCM Server nur Discovery, Share-Verwaltung, Benachrichtigungen und Einladungen; Ressourcenzugriff und Credential-Ausgabe finden andernorts statt. Die sichtbare Identität bleibt stabil, während sich der Kreis vertrauenswürdiger Komponenten erweitert.

Gegenüber der individuellen Version 01 enthält die erste WG-Version ein neues Bedrohungsmodell. Es setzt voraus, dass OCM Server, gekoppelte Protocol Server und ein delegierter Token Server nicht kompromittiert sind und lokale Regeln korrekt durchsetzen. Signaturen schützen vor Manipulation auf dem Übertragungsweg; sie machen einen kompromittierten Vertrauensendpunkt nicht wieder vertrauenswürdig.

Drei Betriebsarten verteilen den Widerruf neu

Bei der provisionierten Integration übermittelt der OCM Server die Share-Daten vor dem Zugriff über einen signierten Rückkanal. Der Protocol Server speichert einen Share Record und erhält später einen Widerrufsauftrag, der auch die Freigabe zugehöriger Ressourcen auslöst. Nur diese Betriebsart unterstützt laut Entwurf SSH; sie ist für Anwendungen mit eigener Sitzung pro Share vorgesehen.

Die selbstenthaltene Integration verzichtet auf diesen Zustand. Die nötigen Angaben stehen in einem ocm_ip-Claim des signierten JWT. Der Protocol Server braucht weder einen eingehenden Provisionierungsendpunkt noch einen Share Record. Ein bereits ausgestelltes Token kann aber nicht vor Ablauf zurückgezogen werden. Deshalb verbietet der Entwurf, den selbstenthaltenen und den provisionierten Pfad für denselben Share zu mischen.

Die introspektive Integration prüft Credentials über einen Endpunkt nach RFC 7662. Sie hält die Verbindung zu empfangenden Servern offen, die noch das alte sharedSecret direkt vorlegen. Dafür entsteht wieder eine Abhängigkeit pro Anfrage vom OCM Server oder Token Server. Eine positive Cache-Antwort verschiebt den Zeitpunkt, zu dem ein Widerruf sichtbar wird.

Die Kennzeichnung „OCM-IP-fähig“ sagt damit wenig über den Betrieb. Entscheidend sind Betriebsart, Token-Lebensdauer, Cache-Grenze, Ablage des Zustands und der Nachweis, dass eine zugeteilte Ressource tatsächlich entfernt wurde.

Unsichtbarkeit ist eine Schnittstelleneigenschaft

Die Transparenzregel richtet sich an die empfangende Seite. Sie soll OCM-IP weder implementieren noch kennen müssen. Ein bekannt gegebener Endpunkt kann vom OCM Server, einem Reverse Proxy oder einem Protocol Server auf einem anderen Host bedient werden. Auf OCM-Ebene gibt es kein Merkmal, mit dem ein entfernter Peer diese Konstruktion entdeckt.

Intern ist sie keineswegs namenlos. Betreiber koppeln OCM Server und Protocol Server außerhalb des Protokolls. Sie legen Protokolle, Ressourcentypen, Betriebsarten, Domains, APIs und JWKS-Adressen fest. Der Protocol Server muss eine Zulassungsliste gekoppelter OCM-Domains führen und nicht gekoppelte Aussteller ablehnen.

Der Rückkanal nutzt HTTP Message Signatures und veröffentlichte JWK Sets; Zugriffstoken sind signierte JWTs. Die Prüfung bindet eine Aussage an einen Schlüssel. Kopplung und Share-Zustand bestimmen, ob diese Aussage hier etwas bewirken darf.

Offen bleibt, wer einen Serverwechsel genehmigte, warum eine Token-Frist verlängert wurde, welcher Schlüssel vor dem heutigen galt und ob nach dem Widerruf eine Anwendungssitzung abgebaut wurde. Der Entwurf zählt den Protocol Server zur vertrauenswürdigen Rechenbasis des Senders. Ein Token Server erhält Signaturmacht sowie Share- und Identitätsdaten. Diese Verlagerung braucht eine eigene Entscheidungsspur.

ocm_ip steht noch nicht in den IANA-Registern

Der Entwurf beantragt ocm_ip als JWT-Claim und als Mitglied einer OAuth-Introspektionsantwort, sobald das Dokument RFC-Form erreicht. Das aktuelle IANA-JWT-Register und die OAuth-Parameterregister enthalten keinen exakten Eintrag dieses Namens.

Das ist kein Widerspruch zur WG-Annahme. Die Annahme bestimmt, woran die Gruppe arbeitet; sie führt die IANA-Anweisungen nicht vorzeitig aus. Versuche müssen ihre Entwurfsversion nennen und dürfen einen beantragten Namen nicht als bereits zugeteilten Standardwert darstellen.

Die interne Verantwortungslandkarte

Daniel Kade schlägt eine zugriffsgeschützte Delegations-Verantwortungslandkarte vor. Sie verbindet OCM Server, Protocol Server und Token Server mit Rolle, Protokollen und Ressourcen, Betriebsart, Endpunkt- und Schlüsselkennungen, Gültigkeitszeitraum, Freigabeinstanz, Widerrufs- und Bereinigungsergebnis, Störungskontakt und Aufbewahrungsort der Belege.

Das ist weder IETF- noch OCM-Vorgabe. Die vollständige Landkarte gehört nicht in ein Token und nicht an jeden Peer. Ein öffentlicher Beleg kann auf eine undurchsichtige Kennung, Rollenklasse, Wirksamkeitszeit und geprüftes Ergebnis beschränkt bleiben. Interne Hostnamen, personenbezogene Daten, private Schlüssel und sensible Topologie bleiben geschützt.

Die Landkarte dokumentiert, autorisiert aber nicht. Ein Wechsel erzeugt einen Nachfolgereintrag statt einer Überschreibung. Beim provisionierten Widerruf werden Zustellung und tatsächliche Ressourcenfreigabe getrennt. Beim selbstenthaltenen Token sind Fristablauf und beobachtetes Zugriffsende ebenfalls verschiedene Tatsachen.

Heng Lus Policy Mirror liefert dafür die passende Disziplin: Akteur, Regel und Beleg dürfen nicht füreinander sprechen. Die Minimum Initial Specification lässt einen kleinen gemeinsamen Kern mit umfangreicheren lokalen Nachweisen koexistieren. Die Gegenstelle bekommt eine stabile Schnittstelle, der Betreiber behält die Geschichte dahinter.

Quellen

  1. OCM Integration Protocol, WG-Version 00
  2. Aktueller Datatracker-Eintrag
  3. Dokumenthistorie
  4. Mitteilung des Annahmeergebnisses
  5. Individueller Vorgänger, Version 01
  6. Open Cloud Mesh Working Group
  7. OCM-Protokoll der IETF 126
  8. OCM-Basisprotokoll, WG-Version 06
  9. RFC 9421 — HTTP Message Signatures
  10. RFC 7517 — JSON Web Key
  11. RFC 7662 — OAuth 2.0 Token Introspection
  12. RFC 7519 — JSON Web Token
  13. IANA-JWT-Register
  14. IANA-OAuth-Parameterregister
  15. Heng Lu — The Policy Mirror
  16. Heng Lu — Minimum Initial Specification