Zusammenfassung

  • Open Cloud Mesh informiert die empfangende Partei über eine erteilte Berechtigung, endet aber vor dem WebDAV-, SSH- oder Anwendungsvorgang, der sie nutzbar macht.
  • Der neue OCM-Integrationsentwurf macht eine wichtige Beweisgrenze sichtbar: Meldung, gültige Berechtigung und erfolgreiche Ressourcenoperation sind verschiedene Datensätze.

Eine Einladung meldet einen freigegebenen Ordner. Der Empfänger klickt, doch der Zugriff schlägt fehl. Daraus folgt nicht zwingend, dass die Einladung unwahr war. Wahrscheinlicher hat das Berichtssystem eine Kontrollmeldung zum Beleg für alle nachfolgenden Schritte erhoben.

draft-ietf-ocm-integration-protocol-00, die am 11. September veröffentlichte erste WG-Fassung, legt diese Trennung offen. OCM meldet einem Receiving Server, dass einer Partei Zugriff auf eine Resource gewährt wurde. Der tatsächliche Zugriff erfolgt später über WebDAV, SSH oder ein anwendungsspezifisches Protokoll. Der Entwurf erlaubt die Delegation an einen Protocol Server, ohne dass der empfangende Peer die interne Anordnung erkennen muss.

Es geht um Realitätsebenen: Mitteilung, Autorisierung, Ausführung und Ergebnis sind nicht identisch.

Die Meldung weist den nächsten Weg

Die Share Creation Notification enthält Parteien, providerId, Protokolleinträge, Berechtigungen und gegebenenfalls Ablaufdaten. Sie kann auf den nächsten Endpunkt verweisen, enthält aber nicht dessen Antwort.

Der providerId verbindet den Share-Zustand im Back Channel mit dem Front-Channel-Zugriff. Dennoch bezeichnet ihn der Entwurf als Identifier, nicht als Credential. Sein Besitz darf keinen Zugriff gewähren. Dieser muss aus einem geprüften Access Token oder im introspected Modus aus einer als aktiv bestätigten Berechtigung folgen.

Auch ein valides JWT beweist nur Begrenztes. Die Signatur schützt Aussteller und Claims. Der Protocol Server prüft weiterhin issuer, audience, subject, Ablauf, Pairing und Share-Zustand und setzt Berechtigungen durch. Danach muss Speicher oder Anwendung die Operation ausführen. Eine korrekte Signatur erzeugt keine fehlende Datei, bestimmt nicht automatisch die richtige Version und verwandelt einen WebDAV-Fehler nicht in eine abgeschlossene Übertragung.

Eine verbotene Scheinerfüllung

Im provisioned Modus sendet der OCM Server zunächst eine signierte Share Provisioning Request. Der Protocol Server prüft sie, speichert den Share Record und bestätigt. Erst danach darf die Share Creation Notification versandt werden.

Scheitert das Provisioning, darf der Share nicht erzeugt werden; sonst erhielte die empfangende Partei eine Meldung über einen Zugriff, der nicht funktionieren kann. Diese Reihenfolge verhindert genau einen falschen Zustand: Ankündigung trotz abgelehnter Bereitstellung.

Spätere Zugriffe bleiben offen. Token-Austausch oder Identitätsbindung können scheitern, Token können ablaufen, die Resource kann sich ändern, der Protocol Server ausfallen oder das Zugriffsprotokoll einen Fehler liefern. Der genaue Nachweis lautet daher „Provisioning vor Meldung erfolgreich“, nicht „Empfänger griff auf die Resource zu“.

Drei Betriebsarten, drei Uhren

Provisioned, self-contained und introspected können nach außen dieselbe OCM-Einladung erzeugen. Ihre Widerrufs- und Nachweisgrenzen unterscheiden sich.

Provisioned speichert einen Share Record und kennt einen ausdrücklichen Widerruf. Self-contained trägt Share-Daten im signierten ocm_ip-Claim; ein ausgegebenes Token kann bis zum Ablauf weiterwirken. Introspected fragt den Aktivstatus ab, doch eine positiv zwischengespeicherte Antwort verzögert den Widerruf.

„Um 14 Uhr entzogen“ sagt deshalb nicht, wann der Zugriff endete. Entscheidend sind je nach Modus Widerruf des Share Records, Laufzeit des letzten Tokens oder Ablauf des Introspection-Caches. Die interne Topologie muss nicht öffentlich werden. Der Betreiber muss jedoch lokal festhalten, welcher Modus galt und welcher Lebenszyklusschritt tatsächlich abgeschlossen wurde.

Das Zugriffsprotokoll liefert den letzten Beleg

Front-Channel-Fehler folgen der Semantik von WebDAV, SSH oder der Anwendung. OCM soll kein Ergebnis behaupten, das es nicht beobachtet.

Bei WebDAV können Methode, HTTP-Status, ETag oder Version und vollständiger Response Body relevant sein. Bei SSH beweisen Authentifizierung und Session-Aufbau nicht die gewünschte Dateioperation. In einer Webanwendung bedeutet eine autorisierte Ansicht nicht, dass der dahinterliegende Auftrag beendet wurde.

Eine belastbare Kette verbindet fünf Ebenen: Share-Meldung; Token-Ausgabe oder Introspection; Autorisierungsentscheidung; Protokollantwort und Resource-Version; Ergebnis in der Empfängeranwendung. Ein Dashboard darf verdichten, aber die Herkunft nicht auslöschen.

Quellen