Résumé

  • RFC 9670 fournit un modèle commun de partage, mais laisse à chaque type de données la définition des objets partageables et du sens précis de ses droits.
  • La révocation se prouve sur les nouvelles opérations du service ; elle ne prouve pas la disparition d’une exportation, d’une copie ou d’un cache constitué pendant que l’accès était licite.

À 09 h 14, le propriétaire retira un Principal de shareWith. Le serveur accepta la modification, publia un nouvel état et renvoya désormais des myRights à faux. À 09 h 15, le destinataire ne pouvait plus ouvrir l’objet sur le service. Pourtant, le document exporté la veille restait sur son ordinateur.

La révocation était vraie. L’affirmation « le destinataire n’a plus les données » ne l’était pas.

Cette différence n’est pas un défaut caché de RFC 9670. C’est la frontière normale d’un protocole d’autorisation. Le texte standardise des objets Principal et ShareNotification ainsi qu’un cadre que d’autres types JMAP peuvent reprendre. Il ne choisit ni ce qui peut être partagé ni la granularité des permissions. Une boîte aux lettres, un calendrier ou une liste de tâches n’ont pas nécessairement les mêmes verbes ni le même coût de divulgation.

Trois propriétés, trois questions

Tout type partageable doit définir isSubscribed, myRights et shareWith.

shareWith décrit les droits attribués à des identifiants de Principal. myRights décrit les droits courants de l’utilisateur qui lit l’objet. isSubscribed indique si cet utilisateur souhaite que la ressource apparaisse dans son usage quotidien. Ces propriétés ne sont pas trois vues d’un même booléen.

Un collaborateur peut avoir la permission de consulter des centaines de ressources et ne s’abonner qu’à quelques-unes. Le serveur peut même refuser un abonnement alors que l’accès reste permis. Ainsi, l’absence d’un objet dans l’interface ne démontre pas un refus d’autorisation. Il faut interroger l’objet et ses droits, puis tenter l’opération concernée.

Inversement, la présence d’un nom dans shareWith n’est pas encore un constat d’usage. La valeur est une carte de droits demandés. Le type de données définit les clés, le serveur applique sa politique, et le destinataire reçoit un myRights propre à son contexte. Une lecture autorisée ne garantit pas une mise à jour ; une permission administrative ne garantit pas que le client sache l’exposer.

Le propriétaire n’apparaît pas dans shareWith : ses droits sont implicites. Conclure qu'une identité absente de la carte n'a aucune autorité serait donc déjà une erreur de modèle.

Le nom affiché ne suffit pas à choisir la personne

Le protocole identifie un Principal par son ID. Le nom, l’adresse, la description et le type servent à le présenter, pas à certifier son détenteur. RFC 9670 avertit qu’un utilisateur autorisé à modifier ces champs peut imiter une autre personne. L’unicité exacte du nom ne règle rien : une faute minime ou un caractère Unicode ressemblant peut tromper l’œil.

Une preuve de partage défendable relie donc le Principal à une génération de l’annuaire, à l’Account où il est défini et à l’identité humaine ou de service validée par l’organisation. Elle conserve aussi le Principal propriétaire de l’Account contenant l’objet. Une capture d’écran du sélecteur de destinataires ne remplace pas cette chaîne.

Le risque devient structurel quand la création de Principals est ouverte. Le RFC exige un contrôle strict de leur ensemble : sinon augmentent les partages accidentels, les contenus indésirables et le spam de notifications.

L’état protège une écriture, pas toute l’histoire

RFC 9670 s’appuie sur les méthodes JMAP de RFC 8620. Avec ifInState, un client peut demander que la modification n’ait lieu que si le type de données est encore dans l’état qu’il a lu. Si une autre écriture est intervenue, stateMismatch arrête l’opération. La réponse /set distingue updated de notUpdated et rend le nouvel état.

Cette discipline est essentielle pour shareWith, souvent remplacé comme une carte entière. Deux administrateurs peuvent partir de la même version, ajouter des destinataires différents et, sans précondition, faire disparaître le travail de l’autre.

Il faut conserver l’état antérieur, le hash exact de la carte, la précondition, le résultat par objet et l’état suivant. Mais le token reste un instrument de synchronisation. Il ne dit pas qui a voulu quoi, pourquoi la politique a réduit un droit, si le destinataire a été prévenu ni s’il a réussi son opération.

La notification peut être juste sans être vue

ShareNotification mémorise un changement de permissions. L’objet contient l’identité de l’objet partagé, les anciens et nouveaux myRights, une date et l’entité à l’origine du changement. Le principalId de cette dernière peut être nul.

Le serveur devrait créer une notification, mais il peut omettre les changements hérités d’un Principal de groupe si le volume devient inutilement écrasant. Il peut fusionner, limiter et expirer les notifications ; lorsque le plafond est atteint, la plus ancienne peut être supprimée. Le RFC souligne qu’une telle disparition peut masquer un événement de sécurité.

Une notification enregistrée prouve donc une décision du serveur selon sa politique. Elle ne prouve ni transport vers le client, ni affichage, ni lecture humaine. Son absence ne prouve pas nécessairement l’absence du changement, notamment pour les groupes.

La bonne formulation de la révocation

Pour révoquer, l’opérateur doit identifier l’objet et sa génération, modifier shareWith avec contrôle de concurrence, relire la carte, observer les myRights du destinataire et tester une nouvelle opération. Le résultat peut être formulé précisément : « à partir de tel état et de telle heure, ce Principal ne peut plus obtenir ou modifier cet objet par ce service ».

Cette phrase ne couvre pas les fichiers exportés, les captures, les sauvegardes ou les caches situés hors du contrôle du serveur. RFC 9670 ne prescrit pas leur suppression. Une politique de gestion des copies peut exister, mais son autorité et ses reçus sont autres.

La sécurité du RFC confirme la nécessité de garder les étages séparés. Un bref accès à un client déverrouillé peut devenir une persistance si l’attaquant ajoute son propre Principal à un partage. Des changements répétés peuvent épuiser les ShareNotifications. Un faux profil peut détourner le choix initial. Dans chaque cas, la carte est syntaxiquement valable ; c’est l’identité, l’attention ou la gouvernance qui a cédé.

Sources