Résumé

  • RFC 9967 peut relier une réponse SCIM asynchrone et son résultat ultérieur : Set-Txn dans une réponse 202 doit correspondre au champ txn d’un Security Event Token.
  • Cette continuité établit une piste de corrélation, non une équivalence d’identité, une instruction de provisioning ou un droit d’accès dans le domaine récepteur.
  • La gouvernance solide sépare acceptation de la demande, validation de l’événement, rapprochement, décision locale, effet constaté et annulation.

Le ticket de fin répond à une question limitée

Lorsqu’un client demande respond-async, un fournisseur SCIM peut répondre normalement ou renvoyer 202 sans corps. Dans ce second cas, la réponse porte Set-Txn. Le SET de résultat emploie le même txn. L’équipe qui suit l’opération peut ainsi relier un résultat à la transaction sous-jacente plutôt qu’à une simple livraison de jeton. Le jti distingue un jeton; le txn peut survivre à une retransmission ou à l’envoi vers plusieurs récepteurs.

Cette précision est opérationnellement importante. Elle rend détectables les doublons, les résultats absents et les réponses arrivées hors ordre. Elle ne transforme toutefois pas un identifiant bien tenu en conclusion générale. Le lien dit que deux enregistrements concernent le même travail déclaré par le fournisseur. Il ne dit pas que le destinataire accepte le sujet, l’interprétation, la règle de rôle ou le changement de service qui pourrait suivre.

L’événement informe; le récepteur choisit la conséquence

Le texte du RFC est sobre : un SET décrit un changement survenu chez un fournisseur SCIM et le récepteur détermine la meilleure action locale dans son propre contexte. Ce n’est pas une réserve facultative. Deux domaines peuvent employer des schémas différents, conserver des identifiants différents, avoir des motifs distincts de suspension ou supporter des obligations de conservation incompatibles. Un message commun ne peut pas choisir à leur place.

Le choix entre les formes full et notice rend cette limite concrète. Une forme complète transporte la représentation finale de la ressource dans data. Une notification ne fournit que les attributs modifiés; le récepteur peut alors récupérer des détails selon une relation SCIM déjà convenue. La première augmente les données disponibles; la seconde laisse davantage de contrôle à la récupération. Aucune n’ordonne une modification locale.

Le même raisonnement vaut pour sub_id, obligatoire pour identifier le sujet de l’événement SCIM. Il exprime le sujet que l’émetteur entend désigner, pas la résolution finale dans une base locale. Le compte local peut avoir été fusionné, réattribué, écarté du flux ou soumis à une règle que l’émetteur ne connaît pas. La syntaxe aide à rapprocher; elle ne juge pas l’équivalence.

Ne pas confondre acceptation asynchrone et clôture opérationnelle

Une réponse 202 annonce l’acceptation d’un traitement asynchrone. Le résultat ultérieur peut être un succès ou une erreur. Un client peut aussi ignorer Set-Txn s’il n’a pas besoin de confirmation, et l’annonce des capacités d’événements est optionnelle. L’absence de capacité peut donc signifier absence de prise en charge ou absence de configuration actuelle; elle ne prouve pas qu’un flux est défaillant.

Une chaîne exploitable garde au moins six pièces : la demande autorisée; la réponse du fournisseur et le Set-Txn; le SET reçu et validé; la règle de rapprochement du récepteur; la décision locale sur le droit; l’effet réel et son annulation. Une pièce peut être correcte alors que la suivante est refusée. Un SET valide peut mener à un refus de groupe local. Cette divergence est parfois la protection attendue, non l’échec de l’intégration.

Les modes push et poll de livraison SET organisent la connectivité et les conditions d’échange; ils ne désignent pas le responsable d’une autorisation. De même, l’interdiction de modifier Set-Txn protège la traçabilité du passage de relais. Elle ne fait ni de l’intermédiaire ni du fournisseur l’autorité finale sur les accès du récepteur.

La doctrine de Heng Lu éclaire ce dessin sans devenir une exigence IETF : partager le fait minimal — une transaction acceptée et un résultat corrélé — tout en laissant à chaque partie la décision future qu’elle doit pouvoir justifier et réparer.