Zusammenfassung

  • DAV:current-user-principal ist geschützt und wird pro Anfrage berechnet; es enthält genau eine HTTP(S)-URL zu einer Principal-Ressource oder den unauthentifizierten Pseudo-Principal.
  • Die ausgewählte URL startet weitere Abfragen. Sie ist weder vollständige Identitätsliste noch universeller Personenschlüssel noch Zugriffszusage.
  • Belastbarer Betrieb trennt Dienstfund, Authentifizierung, Principal-Auswahl, Darstellungsstabilität, Ressourcenzugriff, Privilegprüfung, Aktion und beobachtete Wirkung.

Gleichheit der Zeichenfolge war nie der Vertrag

RFC 3744 hatte Principals, Gruppen, ACLs und die Privilegien des aktuellen Benutzers definiert. Was fehlte, war ein direkter empfohlener Weg vom authentifizierten HTTP-Benutzer zu einer zugehörigen Principal-Ressource. DAV:principal-match konnte neben dem individuellen Principal auch alle Gruppen liefern, denen er angehörte.

RFC 5397 ergänzt DAV:current-user-principal. Der Wert ist ein einzelnes DAV:href oder DAV:unauthenticated. Das href muss HTTP(S) verwenden und zu den auf der Principal-Ressource erklärten URLs gehören. Von dort kann ein Client Gruppen, alternative Kennungen oder Anwendungs-Home-Sammlungen ermitteln.

Die Norm wählt bewusst einen Einstieg statt einer vollständigen Identitätsauflistung. Ein Client erhält eine handlungsfähige Adresse für die nächste Frage. Ob die nächste Ressource erreichbar ist, welche Rechte dort gelten und ob eine Änderung wirksam wird, bleibt offen.

Darstellung und Principal haben keine Eins-zu-eins-Garantie

Mehrere URLs dürfen dieselbe Principal-Ressource bezeichnen. Mehrere Principal-Ressourcen dürfen demselben authentifizierten Principal entsprechen. Bei mehreren Kandidaten darf der Server einen auswählen, sollte für denselben Principal aber konsistent bleiben.

Diese Freiheit passt zu verschiedenen Verzeichnisarchitekturen. Sie widerspricht einem Datenmodell, das das beobachtete href ungeprüft zum globalen Benutzerschlüssel macht. Ein Umbau des Verzeichnisses kann die URL ändern, ohne die Person zu ändern. Gleiche Pfade bei verschiedenen Diensten können verschiedene Principals bezeichnen.

Ein Beleg speichert deshalb Dienstautorität, Zeitpunkt, Authentifizierung, gewählte URL, Weiterleitungen und nachfolgende Eigenschaften. Die Gleichwertigkeit zweier Darstellungen braucht eine Aussage der zuständigen Autorität. Textähnlichkeit, Redirect oder gleichzeitige Nutzung reichen außerhalb ihres Kontexts nicht.

Konsistenz ist dennoch prüfbar. Unerklärte Wechsel können auf Migration, fehlerhafte Affinität oder geändertes Mapping hinweisen. Ein Alarm soll die Ursache klären, nicht automatisch ein neues Konto erzeugen oder Historien zusammenführen.

Der aktuelle Principal ist Anfragestatus

Die Eigenschaft ist geschützt, weil der Server sie setzt, und anfragebezogen, weil die Antwort von der Authentifizierung dieser Anfrage abhängt. COPY und MOVE übertragen sie nie. Sie gehört nicht zum gespeicherten Dokument.

Ein Export, der sie als dauerhafte Metadaten schreibt, friert eine alte Beobachtung ein. Nach der Migration könnte der Principal eines früheren Akteurs einem späteren Leser zugeschrieben werden. Audit-Akteur und aktuell entdeckter Principal sind unterschiedliche Datensätze.

RFC 6764 erlaubt Clients, erfolgreiche Dienst- und Principal-Daten zu cachen. Bei anhaltenden Verbindungs- oder Authentifizierungsfehlern sollen sie SRV-Suche und Kontenermittlung wiederholen. Ein Cache hat Herkunft und Erneuerungsbedingung; er übernimmt nicht die Autorität des Servers.

Damit lässt sich ein Fehler zerlegen: alter Endpunkt, ungültige Anmeldung, anderes Principal-Mapping, nicht erreichbare Principal-Ressource, fehlende Home-Eigenschaft oder geänderte Berechtigung. Ein einziges Konto-rot-Signal kann diese Besitzer nicht unterscheiden.

Unauthentifiziert ist kein zu füllendes Nullfeld

Ohne erfolgreiche Authentifizierung muss die Eigenschaft DAV:unauthenticated enthalten. Der Wert ist ein ausdrücklicher Zustand. Er darf nicht durch die letzte erfolgreiche URL oder eine aus dem Benutzernamen konstruierte Adresse ersetzt werden.

RFC 6764 verlangt Authentifizierung für PROPFIND-Anfragen, die die Eigenschaft abrufen, damit der Wert zum anfragenden Benutzer gehört. Fehlt die Eigenschaft, muss der Client möglicherweise den Principal-Pfad vom Benutzer erfragen. Das ist ein alternativer Ablauf, keine Erlaubnis zum Raten.

Das explizite Ergebnis schützt auch die Zuordnung von Ereignissen. Eine technisch erfolgreiche anonyme HTTP-Antwort darf nicht dem zuletzt sichtbaren Konto zugerechnet werden, nur weil die Oberfläche Kontinuität bevorzugt.

Identität lokalisiert, Privileg noch offen

Der aktuelle Principal sagt, wo der Client weitere Identitätsinformationen findet. DAV:current-user-privilege-set aus RFC 3744 sagt, welche Privilegien der Server dem aktuellen Benutzer auf einer bestimmten Ressource gewährt. Das Ziel gehört zur Aussage.

Ein Benutzer kann die Principal-Ressource lesen und einen Kalender nicht ändern. Gruppenmitgliedschaft kann eine ACL beeinflussen, ohne die Gruppe zur individuellen Principal-Ressource zu machen. Selbst ein Schreibprivileg garantiert keinen Erfolg bei einer ETag-Vorbedingung oder einem Anwendungskonflikt.

CalDAV- und CardDAV-Ermittlung verlängern die Kette: Dienst finden, TLS prüfen, authentifizieren, Principal erhalten, Home finden, Zielsammlung prüfen, Methode ausführen und Ergebnis beobachten. RFC 5397 standardisiert eine Brücke, nicht die gesamte Reise.

Eine ehrliche Statusanzeige zeigt die Stufen. Principal gefunden kann grün sein, während Home unbekannt, Zugriff verweigert oder Wirkung unbestätigt bleibt. Das ist keine schlechte UX, sondern präzise Verantwortlichkeit.

Genügend Evidenz ohne Vollkopie

Nicht jede Gruppe und ACL muss in zentrale Logs kopiert werden. Erforderlich sind begrenzte, strukturierte Daten: Dienst, Korrelation, Authentifizierungsklasse, Ergebnisform, scoped URL-Kennung, Folgeressource, Privilegentscheidung, Methode und Wirkung.

Identitäts- und Mitgliedschaftsdaten brauchen Minimierung, Zugriffsschutz und Löschfristen. Getrennte Nachweise verhindern, dass Teams aus Unsicherheit vollständige Verzeichnisse sammeln, obwohl ihnen nur die Übergangsinformation fehlt.