Résumé

  • La révision 08 du projet d’extensions iCalendar introduit le rôle OWNER, mais précise qu’il n’est qu’indicatif et ne doit jamais suffire à autoriser une modification.
  • JMAP Calendars rend visibles les contrôles manquants : le participant doit correspondre à une identité du compte, puis les droits du calendrier et les contraintes de l’événement doivent encore permettre l’opération.
  • Lecture du rôle, décision d’autorisation, mutation acceptée, envoi des messages, traitement distant et visibilité pour les participants sont des preuves différentes.

Le dossier le plus dangereux n’est pas forcément invalide. Il peut respecter la syntaxe, passer le parseur et afficher un badge de propriétaire très convaincant. Le problème apparaît lorsqu’un logiciel transforme cette description en permission.

La révision 08 du projet définit OWNER comme rôle de participation. Elle explique que ce rôle désigne l’utilisateur capable d’effectuer des changements qui concernent tous les participants, par exemple déplacer l’événement ou modifier les invités. Puis elle impose une limite nette : ce rôle reste indicatif, sa portée dépend du protocole d’échange, et aucune application ne doit accorder un droit de modification sur ce seul fondement.

Cette phrase sépare une affirmation transportée par les données du pouvoir exercé par un service. Les calendriers rendent cette séparation facile à oublier : le rôle arrive au milieu de dates, récurrences, lieux et participants, tous immédiatement exploitables par l’interface.

La donnée voyage plus loin que l’autorité

RFC 5545 fournit un format portable. Le même objet peut passer par un fichier, un message, un entrepôt CalDAV ou un service JMAP. Or ces environnements ne partagent pas nécessairement la même identité, le même compte ni le même modèle de droits.

Le projet indique expressément qu’il ne définit pas la sémantique de OWNER pour CalDAV. Un récepteur peut donc conserver et afficher le rôle, mais il ne peut pas inventer une règle d’écriture absente du protocole qui l’entoure. Même une future inscription dans les registres iCalendar de l’IANA ne changerait pas cela : un registre coordonne un nom et une référence, il n’authentifie pas l’utilisateur et n’accorde aucun pouvoir.

C’est une application directe de la spécification initiale minimale. Le vocabulaire commun doit être assez précis pour voyager, sans absorber toutes les décisions locales. Le rôle peut être interopérable ; l’autorisation reste une décision du protocole et de l’autorité qui l’exploite.

JMAP expose la chaîne de décision

Le projet actif JMAP Calendars donne un exemple concret. Un utilisateur est propriétaire d’un événement seulement si un participant porte le rôle owner et si ce participant correspond à l’une de ses identités dans le compte.

Cette correspondance ne crée toujours pas un pouvoir universel. mayWriteOwn n’autorise une écriture que sur le calendrier concerné et seulement lorsque l’utilisateur possède l’événement ou que celui-ci n’a pas de propriétaire. mayWriteAll, mayRSVP, mayShare et mayDelete couvrent d’autres capacités. Les réduire à un bouton unique intitulé « propriétaire » détruirait la preuve.

Lors d’un CalendarEvent/set, le serveur doit appliquer les droits présents dans myRights et refuser l’opération avec une erreur forbidden si elle n’est pas permise. Ce verdict est le reçu d’autorité. Le rôle n’en est qu’une entrée.

D’autres limites interviennent encore. Une copie qui n’est pas l’origine de la planification ne doit pas recevoir de modifications globales côté client, même si certains droits semblent les permettre, car une mise à jour ultérieure de l’origine peut l’écraser. La confidentialité, la récurrence, l’appartenance aux calendriers et l’état d’origine changent aussi la portée d’une opération.

Étape Preuve obtenue Question encore ouverte
Analyse Le rôle OWNER est syntaxiquement présent Qui l’a déclaré et s’il est actuel
Identité Le participant correspond à une identité du compte Quels droits portent sur ce calendrier
Autorisation Une règle actuelle permet l’opération Si l’écriture a réussi
Mutation Le serveur a accepté un nouvel état Si une notification a été envoyée
Livraison Un autre système a reçu un message S’il l’a appliqué et montré
Relecture Un participant observe le changement Si toutes les copies ont convergé

Enregistrer n’est pas encore changer la réunion

JMAP permet de demander l’envoi de messages de planification pendant une mutation. La demande ne prouve ni leur émission complète, ni leur réception, ni leur application. Un service peut modifier sa copie locale puis échouer au transport, rencontrer un refus distant ou livrer un message que personne ne consulte.

RFC 6638 et RFC 4791 montrent pourquoi stockage et planification sont des surfaces liées mais distinctes. Une collection, une autorité de planification, une boîte de sortie et la copie d’un invité ne constituent pas un fait atomique.

Un journal crédible relie donc plusieurs reçus : empreinte de l’objet source, emplacement du rôle, correspondance d’identité, version des droits, état d’origine et de confidentialité, verdict de politique, identifiant de mutation, empreintes avant et après, sélection des destinataires, résultat de transport et relecture visible. Des empreintes et identifiants suffisent ; nul besoin d’enregistrer le contenu privé de la réunion.

Le processus de normalisation n’est pas une preuve d’exploitation

La fiche Datatracker présente la révision 08 comme projet du groupe CALENDAR EXTENSIONS destiné au statut Proposed Standard, avec publication demandée. L’historique et le rapport du shepherd décrivent le processus. Aucun RFC n’existe encore et aucun déploiement universel n’en découle.

Le même document ajoute SHOW-WITHOUT-TIME, mais précise que cet indice de présentation ne change pas la durée utilisée pour le calcul des conflits. La discipline est identique : une apparence ne doit pas réécrire l’état profond. OWNER ne peut donc pas réécrire silencieusement l’autorisation.

La primauté du code en fonctionnement demande d’examiner l’identité résolue, les droits réellement chargés et le verdict du serveur. The Policy Mirror révèle le pouvoir caché dans les caches de droits, la résolution d’identité et les valeurs par défaut. Reality Layers rappelle enfin que syntaxe, rôle déclaré, autorité et résultat ne sont pas une seule réalité.

La question de direction n’est donc pas « le calendrier affiche-t-il propriétaire ? », mais « quel système a permis quelle opération sur quel état, et quelle preuve montre ensuite que le changement a atteint ceux qui en dépendaient ? »

Sources