Zusammenfassung

  • shareWith ist eine Principal-zu-Rechte-Map; wird sie als Ganzes ersetzt, können parallele Bearbeitungen ohne ifInState einander still überschreiben.
  • Auch eine konfliktfreie Mutation beweist nur den neuen Kontrollzustand. Empfänger-myRights, Subscription, Notification, ausgeführte Operation und Widerrufsgrenze bleiben eigene Belege.

Administratorin A las eine Freigabekarte und fügte ein Incident-Team hinzu. Administrator B hatte dieselbe Ausgangsversion geöffnet und entfernte einen externen Dienstleister. A speicherte zuerst, B wenige Sekunden später. Beide Oberflächen zeigten Erfolg. Im Ergebnis war das Incident-Team wieder verschwunden.

Der zweite Save hatte nicht die Absicht von A widerlegt. Er hatte eine veraltete vollständige Map über sie gelegt.

RFC 9670 definiert für teilbare Datentypen shareWith, myRights und isSubscribed. shareWith ist null, wenn mit niemandem geteilt wird, sonst eine Map von Principal IDs auf datentypspezifische Rechte. Ein berechtigter Nutzer darf sie ändern.

Die einheitliche Form verbessert Interoperabilität. Sie erzeugt aber eine operative Verpflichtung: Wer eine zusammengesetzte Autorisierung ersetzt, muss nachweisen, auf welchem Zustand die Entscheidung beruhte.

JMAP State ist eine Sperre gegen veraltete Entscheidungen

RFC 9670 nutzt die Standardmethoden aus RFC 8620. Ein Client kann einem /set ein ifInState mitgeben. Stimmt dieser Wert nicht mehr mit dem aktuellen Zustand des Datentyps überein, bricht der Server mit stateMismatch ab. Die Antwort trennt erfolgreiche updated-Objekte von notUpdated und liefert oldState und newState.

Für eine Freigabeänderung sollten daher Ausgangs-State, Hash der gelesenen Map, beabsichtigte Änderung, ifInState, Ergebnis pro Objekt und neuer State gemeinsam gespeichert werden. Ein allgemeines „200 OK“ reicht nicht.

Auch dieser vollständige Mutationsbeleg hat eine Grenze. Der State String ist Synchronisationskontrolle, kein universelles Auditprotokoll. Er erklärt weder menschliche Absicht noch Principal-Herkunft, Policy-Berechnung, Notification Delivery oder die erfolgreiche Nutzung eines Rechts.

Ein Principal ist mehr als seine sichtbaren Felder

Ein Principal kann Person, Gruppe, Ort, Raum, Gerät oder eine andere Entität darstellen. Er kann mit mehreren Accounts verbunden sein. Die Owner Capability zeigt, welchem Principal ein Account gehört und wo der zugehörige Principal gespeichert ist.

Das Management der Principal-Menge liegt außerhalb des RFC. Verzeichnis, Provisionierung, Gruppenauflösung und Service Accounts bleiben lokale Verantwortung. Deshalb muss der Freigabebeleg die unveränderliche ID, Verzeichnisgeneration, Principal-Art, Identity Account, Object Account und Owner verbinden.

Name, E-Mail und Beschreibung sind Darstellungsdaten. RFC 9670 warnt vor Spoofing, wenn Nutzer diese Eigenschaften ändern dürfen. Eine Regel gegen identische Namen verhindert weder kleine Schreibvarianten noch visuell ähnliche Unicode-Zeichen.

Der Owner selbst steht nicht in shareWith; seine Rechte sind implizit. Die sichtbare Map ist also ausdrücklich nicht das vollständige Autoritätsinventar.

Zuweisung und wirksames Recht werden getrennt gelesen

shareWith beschreibt, welche Rechte einem Principal zugeteilt werden. myRights beschreibt die aktuellen Rechte des lesenden Nutzers am Objekt. Beide verwenden String-Boolean-Maps, doch deren Schlüssel werden vom jeweiligen Datentyp definiert.

Ein erfolgreicher Save beweist daher nicht, dass ein Kalender, Postfach oder eine andere Anwendung denselben Begriff von Update oder Administration besitzt. Server Policy kann Rechte begrenzen. Gruppenmitgliedschaft kann sich ändern. Ein Client kann die Funktion nicht anbieten.

Die Prüfung liest zuerst shareWith auf Eigentümerseite, dann myRights als Empfänger und führt schließlich genau die relevante Operation aus. Read, Update, Destroy und Admin sind keine austauschbaren Proben.

isSubscribed trennt zusätzlich Berechtigung von Interesse. Ein Nutzer darf auf ein Objekt zugreifen, ohne es abonniert zu haben. Der Server kann ein Abonnement ablehnen und die Berechtigung dennoch bestehen lassen. „Nicht in der Navigation“ ist somit kein Entzugsnachweis.

ShareNotification ist kein lückenloses Journal

Der Server sollte bei Rechteänderungen eine ShareNotification erzeugen. Sie enthält Objektart, Account und ID, alte und neue myRights, Zeitpunkt und changedBy; dessen principalId darf null sein.

Bei Gruppenänderungen darf der Server einzelne Notifications auslassen, wenn die Menge überwältigend wäre. Er kann Einträge zusammenfassen, begrenzen oder veralten lassen. Erreicht die Ablage ihr Maximum, kann eine neue Meldung die älteste löschen. Der RFC weist darauf hin, dass diese Löschung selbst ein Sicherheitsereignis verbergen kann.

Deshalb ist ShareNotification eine policy-gebundene Änderungsnotiz und kein vollständiges Autorisierungsjournal. Nachweise für Erzeugung, Coalescing, Client-Abruf, Anzeige und menschliche Bestätigung bleiben getrennt.

Widerruf hat ein definiertes Objekt

Ein sauberer Widerruf entfernt den Principal mit State-Precondition, liest Map und myRights zurück und testet eine neue Operation. Dann kann die Organisation sagen, dass der Dienst ab Generation X neue Zugriffe verweigert.

Sie kann daraus nicht folgern, dass zuvor exportierte Dateien oder Offline-Kopien verschwunden sind. RFC 9670 definiert kein Zurückholen solcher Bytes. Der Widerrufsbeleg betrifft Live Authority; Copy Governance braucht eine andere Kontrollfläche.

Die Security Considerations zeigen weitere Übergänge. Bearbeitbare Principal-Daten ermöglichen Verwechslung. Kurzer Zugriff auf einen entsperrten Client kann durch eine neue Freigabe persistent werden. Viele Statuswechsel können Notification-Ressourcen erschöpfen. Eine unkontrollierte Principal-Registrierung erleichtert Fehlfreigaben, unerwünschte Inhalte und Spam.

Der Wert des Standards liegt im minimalen gemeinsamen Modell. Seine Glaubwürdigkeit steigt, wenn Betreiber nicht behaupten, dass diese Map auch Identität, Aufmerksamkeit, Ausführung und Datenrückholung erledigt.

Quellen