Summary
- L'IESG a lancé le 23 septembre une dernière consultation sur l'architecture SATP et ses cas d'usage, en vue de deux RFC de statut informatif. Les observations sont attendues avant le 7 octobre ; aucune approbation finale n'en découle encore.
- Dans l'architecture, la passerelle réceptrice s'appuie sur une attestation signée de blocage de l'actif, car l'état du réseau d'origine peut lui être invisible. La garde de l'actif et la responsabilité des opérateurs sont posées comme conditions préalables.
- L'historique signé peut aider à départager un litige. Il ne remplace ni la vérification d'un registre privé ni les accords juridiques que le groupe de travail situe hors du protocole.
Une passerelle reçoit une attestation : l'actif serait désormais immobilisé dans le réseau de départ. Elle ne peut pourtant pas ouvrir le registre privé de son homologue pour le constater. C'est le point de départ politique, autant que technique, du projet d'architecture SATP. L'interopérabilité repose sur une preuve transmissible entre deux systèmes qui ne se donnent pas une visibilité réciproque complète.
Le texte de septembre décrit des réseaux dont les ressources internes restent opaques. Avant tout échange, les applications sont censées avoir identifié l'actif, l'expéditeur et le bénéficiaire et obtenu leur consentement. Les propriétaires des passerelles doivent eux aussi être identifiés ; le projet suppose qu'ils assument les conséquences de leurs messages signés et que la passerelle exerce un contrôle transitoire sur l'actif. Ce sont des hypothèses de conception, non le résultat d'une inspection d'opérateurs réels.
Le transfert prévu comporte plusieurs moments distincts. La passerelle d'origine bloque l'actif et en signe l'attestation ; l'autre en accuse réception. Une phase d'engagement coordonne ensuite l'extinction de l'inscription initiale et la création de son équivalent sur le réseau destinataire. Les messages enchaînés et signés peuvent former un dossier vérifiable par un tiers autorisé lors d'un différend. Leur authenticité ne révèle toutefois pas, à elle seule, si le registre dissimulé disait vrai.
Le 23 septembre, l'Internet Engineering Steering Group a demandé des commentaires sur les versions 10 de l'architecture et des cas d'usage, avec échéance au 7 octobre. Les deux textes visent des RFC informatives. Le projet distinct décrivant le cœur du protocole vise, lui, le statut de norme proposée ; il n'est pas devenu une norme par le seul lancement de cette consultation. Les exemples de finance, de commerce ou de chaînes logistiques contenus dans le second texte n'attestent aucun déploiement.
La charte du groupe SATP reconnaît une limite supplémentaire : les réseaux participants auront probablement besoin d'accords juridiques ou autres préalables, dont le contenu et la mise en œuvre ne relèvent pas de SATP. Dans la perspective de Lu Heng, la valeur d'une trace ne lui confère pas l'autorité de trancher la propriété. La consultation doit permettre d'expliciter les responsabilités que les signatures rendent visibles sans les créer.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-satp-architecture/history/
- https://datatracker.ietf.org/doc/draft-ietf-satp-usecases/history/
- https://datatracker.ietf.org/doc/html/draft-ietf-satp-architecture-10
- https://datatracker.ietf.org/doc/html/draft-ietf-satp-usecases-10
- https://datatracker.ietf.org/wg/satp/about/
- https://datatracker.ietf.org/wg/satp/documents/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

