Résumé

  • RFC 9944 emploie SCIM pour provisionner des données d’appareil dans un déploiement local ; supprimer un Device y reste un signal d’intention applicative, non un ordre universel de révocation.
  • Un 204, un 404 ultérieur ou l’absence d’un résultat de recherche établissent l’état de l’interface SCIM ; la décision de politique, l’exécution et l’effet d’accès exigent des preuves distinctes.

Un administrateur supprime une ressource Device, reçoit une réponse positive, puis ne retrouve plus l’objet. C’est une suite de faits utile. Elle devient trompeuse lorsqu’elle est résumée par « l’appareil a été supprimé, donc il n’a plus accès ». Cette dernière phrase traverse plusieurs systèmes et plusieurs responsabilités.

RFC 9944, document IETF Standards Track publié en mai 2026, étend SCIM aux appareils et aux applications terminales. Le texte vise le provisionnement d’un réseau local pour l’intégration et les communications d’appareils ; il rapproche aussi la base SCIM d’une base AAA. Une donnée de provisionnement peut donc être importante sans constituer la preuve auto-exécutoire d’un paquet bloqué, d’un certificat invalidé ou d’un appareil déconnecté.

La répartition des rôles est explicite. Le serveur SCIM vit dans le déploiement, reçoit des informations sur les appareils attendus et applique une politique locale pour déterminer si et comment ils se connectent. Le client peut être un fournisseur autorisé dans une vente ou une application utilisée par les administrateurs. Il demande un changement de données ; il ne devient pas, par cette demande, le décideur de la politique locale. RFC 9944 impose en outre l’authentification appropriée des clients SCIM, précisément parce que le provisionnement peut ouvrir un accès au réseau.

Sa section sur la suppression écarte toute ambiguïté. Retirer l’objet signale que l’application ne s’attend plus à voir l’appareil sur le réseau. Le serveur peut agir ou ne pas agir sur ce signal ; la révocation de l’accès à l’infrastructure relève strictement du serveur SCIM et de sa politique dorsale. Le RFC recommande un flux de travail conforme à la politique locale. Ce n’est pas une lacune : c’est l’attribution de la décision à celui qui porte la conséquence.

RFC 7644 établit le périmètre plus étroit de l’interface. DELETE demande le retrait de la ressource. Le fournisseur peut conserver les données, mais doit renvoyer 404 pour les opérations ultérieures sur cette ressource et l’omettre des résultats futurs ; une suppression réussie renvoie un statut de succès, illustré par 204. Rien de cela ne démontre qu’un point d’accès a dissocié l’appareil, qu’une règle a été retirée ou que le trafic a cessé.

RFC 7643 maintient aussi une discipline sur l’identité : id est émis par le fournisseur SCIM, tandis que externalId est émis par le client et borné à son domaine de provisionnement. Ces champs relient des enregistrements dans leurs périmètres ; ils ne prouvent ni une identité physique, ni un droit d’accès, ni un résultat observé.

Daniel Kade applique ici la discipline des couches de réalité de docs/heng-lu-note.md comme grille éditoriale, et non comme règle IETF. Conserver séparément la requête authentifiée, la réponse SCIM, la politique évaluée, l’accusé d’exécution et l’observation d’accès permet de dire exactement ce qui a changé.

Sources