Résumé

  • Open Cloud Mesh informe un destinataire qu’un accès lui a été accordé, mais s’arrête avant l’opération WebDAV, SSH ou applicative qui doit rendre cet accès réel.
  • Le nouveau projet d’intégration OCM distingue nettement trois pièces: la notification, un titre d’accès valable et la réussite de l’opération sur la ressource.

Un dossier apparaît dans une invitation de partage. Le destinataire clique. La requête échoue. Le premier message n’était pas nécessairement faux; c’est peut-être le système de suivi qui lui a attribué la valeur d’un reçu de bout en bout.

draft-ietf-ocm-integration-protocol-00, première version de groupe de travail publiée le 11 septembre, décrit précisément cette frontière. OCM coordonne la fédération et notifie qu’une partie a reçu un droit sur une Resource. L’accès effectif vient ensuite par WebDAV, SSH ou un protocole propre à l’application. Le projet permet au serveur OCM de déléguer ce travail à un Protocol Server sans révéler cette composition au pair receveur.

L’enjeu n’est pas le découpage d’un produit. C’est la séparation entre déclaration, autorisation, exécution et résultat.

La notification ouvre la suite, elle ne la termine pas

La Share Creation Notification contient les parties, un providerId, les entrées de protocole, les permissions et parfois une échéance. Elle peut indiquer où présenter la prochaine requête, jamais le résultat de cette requête.

Le providerId relie l’état du Share sur le canal arrière au titre présenté sur le canal frontal. Le texte précise pourtant qu’il s’agit d’un identifiant, non d’un credential. Le serveur receveur le connaît déjà par la notification; sa seule possession ne doit donner aucun accès. L’autorisation dépend d’un jeton vérifié ou, dans le mode introspected, d’un credential déclaré actif par l’endpoint d’introspection.

Même un JWT valide ne répond qu’à une question bornée. La signature établit l’émetteur et protège les claims. Le Protocol Server doit encore contrôler issuer, audience, subject, expiration, pairing et état du Share, puis appliquer les permissions. Le stockage ou l’application doit ensuite exécuter l’opération. Un jeton correct ne crée pas un fichier absent, ne choisit pas la bonne version et ne transforme pas une erreur WebDAV en transfert achevé.

Une fausse réussite expressément interdite

Le mode provisioned impose une séquence révélatrice. Le serveur OCM envoie d’abord une Share Provisioning Request signée. Le Protocol Server la vérifie, conserve le Share Record et acquitte. La notification au serveur receveur ne peut partir qu’après ce succès.

Si le provisioning échoue, le serveur OCM ne doit pas créer le Share: le destinataire serait autrement averti d’un accès qui ne peut pas fonctionner. La règle élimine un état précis, celui d’une annonce émise malgré le refus du serveur d’accès.

Elle ne garantit pas les tentatives futures. Un échange de jeton peut échouer, le jeton expirer, l’identité ne pas correspondre, la Resource changer de place, le Protocol Server devenir indisponible ou le protocole sous-jacent retourner sa propre erreur. Le reçu exact reste donc «provisioning réussi avant notification», et non «ressource consultée par le destinataire».

Trois modes et trois horloges de révocation

Les modes provisioned, self-contained et introspected peuvent produire une invitation semblable, mais pas la même preuve après coup.

Le premier conserve un Share Record au Protocol Server et dispose d’une requête de révocation. Le deuxième porte les données du Share dans le claim JWT signé ocm_ip; sans état individuel sur le canal arrière, le dernier jeton émis peut survivre jusqu’à son expiration. Le troisième demande si le credential est actif, mais une réponse positive mise en cache retarde l’effet de la révocation.

Dire «partage retiré à 14 h» ne fixe donc pas l’heure réelle de fin d’accès. Il faut regarder, selon le mode, la révocation du Share Record, la durée de vie du dernier jeton ou l’horizon du cache d’introspection. Il n’est pas nécessaire d’exposer la topologie interne aux pairs; l’opérateur doit en revanche garder localement le mode choisi et l’action de cycle de vie effectivement terminée.

Le dernier mot appartient au protocole d’accès

Sur le canal frontal, les erreurs gardent la sémantique de WebDAV, de SSH ou de l’application concernée. OCM n’a pas à inventer un résultat qu’il n’observe pas.

Pour WebDAV, le reçu peut inclure méthode, statut HTTP, ETag ou version et achèvement du corps. Pour SSH, authentification et ouverture de session ne prouvent pas que la commande ou la copie souhaitée a abouti. Pour une application web, charger une page autorisée ne prouve pas la fin du calcul demandé.

La chaîne défendable relie cinq étages: notification du Share; émission ou introspection du credential; décision d’autorisation du Protocol Server; réponse du protocole et version de la Resource; résultat dans l’application du destinataire. Un tableau de bord peut les résumer, pas effacer leur provenance.

Sources