Résumé

  • La RFC 9865 définit un curseur opaque qui permet de reprendre la même requête SCIM, au même point de service et avec les mêmes paramètres.
  • La reprise ne survit pas à la règle d’autorisation : chaque ressource renvoyée doit rester accessible à l’identité actuelle de l’acteur.

Le moment le plus trompeur arrive souvent après un changement de droit. Une équipe conserve un nextCursor, modifie un groupe, suspend un compte, puis suppose que la page suivante représente encore le même monde qu’au premier appel. La RFC 9865 ne permet pas ce raccourci. Elle ajoute une manière d’avancer dans un résultat ; elle ne fige ni l’identité, ni la politique, ni le périmètre de visibilité.

La grammaire de reprise est volontairement étroite. Pour commencer une requête paginée, le paramètre cursor est vide ou absent. Le client reprend ensuite avec le même endpoint et les mêmes paramètres, à l’exception de la valeur de curseur obtenue dans une réponse précédente. Cette valeur est opaque au client. Hors de la dernière page, le fournisseur doit livrer nextCursor; previousCursor est facultatif et ne peut figurer sur la première page. Ces exigences donnent un chemin technique vérifiable. Elles ne transforment pas ce chemin en permission transmissible.

Le volume affiché n’élargit pas davantage la preuve. count exprime une taille maximale souhaitée : le fournisseur ne peut pas la dépasser, mais peut retourner moins. Avec count=0, il ne retourne aucune ressource, sauf l’éventuel totalResults. Celui-ci peut manquer lorsque le fournisseur ne sait pas l’estimer. Une liste reçue ne certifie donc ni exhaustivité ni stabilité. Le fournisseur peut même imposer la méthode par curseur; s’il propose aussi l’indexation, il choisit une méthode par défaut et peut révéler ses capacités dans /ServiceProviderConfig.

La limite décisive est formulée dans les considérations de confidentialité. Les pages doivent être strictement limitées aux données que l’identité actuelle de l’acteur est autorisée à consulter, même lorsqu’il détient un curseur créé pour un autre acteur. Les contrôles d’autorisation doivent continuer tout au long du parcours. La possession du curseur ne doit, en aucun cas, ajouter un privilège. Il s’agit d’une règle d’architecture de contrôle : le serveur ne peut déléguer sa décision courante au simple fait qu’il a émis un état de pagination hier.

Après une évolution de permissions, le fournisseur devrait, lorsque possible, invalider immédiatement les curseurs concernés. S’il les conserve, les métadonnées du jeu de résultats doivent refléter le nouveau périmètre. De même, un curseur doit rester difficile à interpréter ou à forger, et les erreurs ne doivent pas révéler la différence entre une page inexistante et une page interdite. Une réponse réussie avec un ancien curseur ne suffit donc pas à conclure que l’accès antérieur demeure légitime.

La disponibilité impose une autre lecture prudente. Conserver beaucoup d’état pour chaque curseur peut devenir une surface de déni de service. La RFC recommande l’authentification pour les ensembles importants, la limitation de débit, un plafond de curseurs ou de taille de page et une invalidation économe en ressources. Elle précise aussi qu’une configuration de taille ou de durée non publiée ne signifie pas qu’aucune limite n’existe. Un écran sans valeur de timeout ne décrit pas la politique effective.

La distinction de Heng Lu évite de donner à la spécification plus d’autorité qu’elle n’en réclame. La RFC produit une convention commune de reprise, testable par les participants. La décision de visibilité reste localisée : elle dépend de la politique active, du code qui l’applique et de la responsabilité de l’organisation qui utilise ensuite les résultats. Le curseur poursuit une liste; le droit doit être établi à nouveau.

Sources