Résumé

  • Le nouveau projet individuel définit une ressource GroupMembership pour chaque lien entre un groupe et un membre. Les clients pourraient filtrer ces liens, les parcourir par pages et supprimer un lien précis.
  • Le signal facultatif membersEmbedded distinguerait une liste intégrale d’une liste dont l’exhaustivité n’est pas garantie. Une liste volontairement exclue de la réponse ne devient jamais une preuve que le groupe est vide.

Une révocation mérite un reçu lisible

Dans le modèle du RFC 7643, les membres figurent dans l’attribut members du groupe. La présentation est pratique pour un petit effectif. Pour les grands ensembles, l’auteur du projet décrit des réponses trop lourdes, parfois amputées de cet attribut. Certains clients demandent eux-mêmes son exclusion. Ils peuvent alors envoyer des changements sans pouvoir confronter leur intention à l’état conservé par le fournisseur. Les chiffres de taille cités dans le projet sont des exemples avancés par l’auteur, pas une mesure indépendante de tous les services SCIM.

La proposition traite l’appartenance comme un objet adressable. Le serveur délivrerait un identifiant opaque au couple groupe–membre. Un filtre retrouverait tous les membres d’un groupe, tous les groupes d’un utilisateur ou le lien entre deux identifiants. Une deuxième création du même couple devrait recevoir un conflit, plutôt qu’un second lien. Pour une équipe chargée de retirer des accès, cette granularité transforme une recherche dans une longue liste en opération sur une relation identifiable.

La petite mention membersEmbedded évite surtout un gros mensonge par omission. Sa valeur true garantirait une liste complète si la requête autorise le retour de members. Si le client a exclu cet attribut, il ne peut conclure à l’absence de membres. false veut dire que le serveur ne garantit rien sur l’exhaustivité, même si la liste visible se trouve par hasard complète. Sans mention, l’ancien modèle garde son interprétation. Le projet impose par ailleurs à /GroupMemberships de rendre disponibles tous les liens que ce client est autorisé à voir. Le périmètre d’autorisation définit donc la portée du contrôle.

Le projet exige un filtrage sur les identifiants du groupe et du membre, plus au moins une pagination. Il recommande le curseur : une liste qui change pendant qu’on avance par indices peut déplacer des éléments entre deux pages. L’ordre stable exigé par le texte suppose lui-même que les appartenances ne changent pas pendant la consultation. Personne ne devrait vendre une simple suite de pages comme une photographie figée.

Deux chemins d’écriture créent enfin un devoir de cohérence. Si le fournisseur accepte encore les modifications de Group.members, il devra répercuter tout ajout et toute suppression dans les nouvelles ressources, et inversement. Une suppression visible d’un côté mais pas de l’autre laisserait à l’opérateur deux versions de sa révocation. Le registre IETF classe ce texte comme projet individuel, sans adoption par un groupe de travail. Une adoption formelle et des essais d’interopérabilité seraient les prochains faits décisifs.

Sources : projet original ; état IETF ; RFC 7643 ; RFC 7644 ; RFC 9865.