Résumé

  • La révision 02 de VCAP a été archivée le 4 septembre comme Internet-Draft individuel, sans approbation de l’IETF, flux RFC, Area Director responsable ni statut normatif.
  • Une nouvelle section reconnaît qu’une place de marché influence le règlement lorsqu’elle choisit les vérificateurs et impose des registres de clés, de capacités et de recours.
  • Le message de livraison émis par le prestataire contient néanmoins auto_approve, présenté comme un moyen de sauter la vérification automatique sur la seule attestation du prestataire.
  • Le texte ne précise ni qui consent à cette dispense, ni quelle clause la permet, ni qui signe ensuite le callback, ni quels contrôles et plafonds survivent.
  • Un reçu de dispense devrait relier proposition, acceptation, base contractuelle, portée, expiration, signataire, contradiction, recours et état final des fonds.

Une amélioration qui révèle le trou restant

L’annonce des Internet-Drafts date du 4 septembre la publication d’un document de trente pages intitulé VCAP: Verified Commerce for Agent Protocols. La fiche Datatracker interdit de lui prêter une autorité qu’il n’a pas : c’est une soumission individuelle active, sans flux RFC, sans Area Director responsable et sans position formelle dans le processus de normalisation. N’importe qui peut déposer un tel projet et l’IETF ne l’endosse pas. « Informational » reste un objectif écrit dans l’en-tête.

La proposition décrit néanmoins une chaîne assez précise pour mériter un examen de gouvernance. Un demandeur et un prestataire négocient une tâche et un prix. Une place de marché immobilise les fonds. Le prestataire livre. Un moteur examine le résultat et envoie un verification_callback. Le booléen passed conduit l’état de vérification vers VERIFIED ou FAILED, puis le séquestre vers RELEASED ou REFUNDED. La révision 02 qualifie ce callback de message le plus critique du protocole.

Le diff officiel montre une avancée par rapport à la révision 01. Une section entière sur la responsabilité du vérificateur a été ajoutée. Elle dit sans détour que la place de marché contrôle effectivement les résultats du règlement lorsqu’elle choisit les vérificateurs. Avant d’accepter leurs conclusions, elle doit enregistrer et approuver leur clé ou méthode Ed25519, conserver leurs capacités déclarées et prévoir une voie d’escalade. Les inscriptions, rotations de clés et radiations doivent rester horodatées auprès des dossiers de règlement.

Lorsque le marché possède aussi le vérificateur, le projet recommande de permettre un tiers choisi d’un commun accord par le demandeur et le prestataire. Il recommande aussi de publier la politique d’affectation : type de contrôle par catégorie de service, traitement des conflits et procédure de contestation. Ce sont des SHOULD, tandis que l’enregistrement de la clé et du recours relève du MUST. Le texte admet donc des choix locaux tout en créant un minimum de visibilité.

Cette réparation est importante parce qu’elle identifie enfin le pouvoir dans le chemin ordinaire. Elle rend plus visible, par contraste, le chemin où le vérificateur disparaît.

Le bénéficiaire propose lui-même la dispense

Le message service_delivery part du prestataire qui affirme avoir terminé. Il contient la description, les artefacts et des indications de contrôle : URL, sélecteur, contenu attendu, comparaison d’empreintes. Il peut aussi contenir auto_approve. La définition tient en une phrase : si la valeur est vraie, la vérification automatique est ignorée et le prestataire s’auto-atteste.

Le schéma JSON de livraison, auquel le projet renvoie, ajoute un détail décisif. Il dit que les indications du prestataire peuvent remplacer ou compléter celles du demandeur. auto_approve vaut faux par défaut. Or un défaut technique ne dit rien du mandat : il évite une activation accidentelle en l’absence du champ, mais ne répond pas à la question « qui peut rendre vrai ce choix et contre qui produit-il effet ? ».

Dans chacune des versions fixes -00, -01 et -02, le nom auto_approve n’apparaît que deux fois : dans l’exemple de message et dans la table des indications. Aucune règle ne désigne le proposant éligible, l’accepteur, la clause d’accord, la limite de valeur, les catégories exclues, l’expiration, la révocation ou le journal de décision. On ignore si un marché doit refuser la valeur, demander une confirmation au client, conserver certains tests déterministes ou ouvrir une revue humaine.

Il faut résister à une conclusion trop grande. Le texte ne prouve pas qu’un logiciel public ou privé applique ce champ. Il ne montre aucun paiement indu, aucun incident et aucune exploitation. Un opérateur prudent peut très bien l’ignorer. Un autre peut exiger un consentement préalable signé. Un troisième peut l’accepter pour des montants minimes. Le problème est que ces comportements incompatibles ne peuvent pas être départagés par la spécification disponible.

Le raccord au callback manque aussi. Le chemin normal exige un résultat passed, une empreinte, une signature, un identifiant de clé et un journal d’actions. Si le moteur automatique a été écarté, qui remplit le rôle de vérificateur ? Le prestataire signe-t-il son propre constat, la place de marché signe-t-elle l’acceptation d’un risque, ou une personne produit-elle le callback ? Une action volontairement non effectuée ne peut pas être reconstruite à partir d’un journal d’actions ordinaire.

L’intégrité du verdict n’est pas l’autorité de la dispense

VCAP-02 apporte un mécanisme cryptographique réel. L’empreinte SHA-256 porte sur un paquet canonique. La signature Ed25519 couvre les identifiants de vérification, de négociation et de séquestre, le verdict, l’empreinte, l’identifiant de clé et l’heure. RFC 8032 permet à un tiers possédant la clé publique de contrôler la signature.

Ce contrôle répond à « cette clé a-t-elle signé ces octets ? ». Il ne répond pas à « le demandeur a-t-il autorisé l’abandon du contrôle ? ». Le projet limite correctement ses propres conclusions : l’empreinte détecte une altération du contenu et la signature rattache la preuve à un vérificateur autorisé. Ni l’une ni l’autre ne contient la clause qui permet l’auto-attestation ou l’identité de la personne qui l’a acceptée.

Les garanties d’atomicité ne créent pas davantage ce mandat. Un compare-and-swap évite qu’un même séquestre soit à la fois libéré et remboursé. L’idempotence évite qu’un callback répété déplace l’argent deux fois. Le système peut donc être irréprochable sur l’unicité de la transition et muet sur l’autorité qui a choisi sa prémisse.

La procédure de délai fournit un contre-exemple utile. Si le contrôle dépasse 1 800 secondes par défaut, les fonds restent HELD. Une entrée de revue manuelle devrait être créée et un humain doit décider. Cette personne émet le callback habituel, avec une ligne de journal qui consigne la décision, puis l’empreinte et la signature normales. Le chemin exceptionnel garde ainsi un décideur, un message et une trace.

Une auto-attestation peut être rationnelle. Un client fidèle peut préférer un coût réduit pour une petite tâche répétée. Rien n’oblige un protocole minimal à imposer le même niveau de contrôle partout. Mais un accord préalable du payeur n’est pas équivalent à un indice envoyé au moment de la livraison par celui qui reçoit l’argent.

Les artefacts exécutables ne racontent déjà pas la même version

Le schéma JSON du callback illustre le risque de laisser le sens hors du contrat exécutable. Au moment de l’observation, il exige encore un HMAC-SHA256 hexadécimal, n’accepte que vcap_version 1.0 et ne contient pas verifier_key_id. Le texte -02 exige au contraire Ed25519, un encodage Base64 et l’identifiant de clé. L’historique du dépôt montre que ces schémas liés n’ont pas suivi la soumission de septembre.

Ce décalage ne démontre pas une panne en production. Il démontre qu’un lecteur de prose et un validateur de schéma peuvent recevoir deux instructions. La règle de dispense présente le même risque tant qu’aucun artefact ne permet de rejeter une acceptation dépourvue de mandat.

La révision corrige également sa relation avec AP2. AP2 organise des mandats et des preuves de paiement ; VCAP ne suppose plus qu’il définit le séquestre, la capture, le remboursement ou le règlement. On ne peut donc pas attribuer silencieusement à AP2 l’autorité manquante sur auto_approve.

Produire un reçu de dispense avant le règlement

Le remède n’est pas un comité mondial. Un petit reçu commun suffit : identifiants de transaction, de négociation et de séquestre ; versions et empreintes du texte et du schéma ; prestataire qui propose la dispense ; clause contractuelle ; personnes ou agents du demandeur et du marché qui l’acceptent ; règle de sélection remplacée ; contrôles abandonnés et conservés ; motif ; plafond de valeur et de risque ; prise d’effet, expiration et révocation ; mode de callback et signataire ; éléments contradictoires ; recours ; état final des fonds.

Le reçu doit précéder le mouvement d’argent. Si l’accord ou l’autorité d’acceptation ne peut pas être résolu, le marché refuse le champ ou conserve le séquestre. Il ne déduit pas un consentement actuel d’une acceptation générale intervenue plus tôt.

Chaque opérateur reste libre d’établir son seuil. Le fait partagé est plus mince : qui a pu choisir l’exception, dans quelles limites et avec quelle conséquence. C’est assez pour que deux systèmes puissent contester le même règlement sans leur imposer le même modèle commercial.

Sources

  1. Annonce IETF de VCAP révision 02
  2. État dans l’IETF Datatracker
  3. VCAP révision 02
  4. VCAP révision 01
  5. Diff officiel entre les révisions 01 et 02
  6. Schéma JSON de service_delivery
  7. Schéma JSON de verification_callback
  8. Historique du dépôt VCAP
  9. RFC 8032 — EdDSA
  10. Spécification Google Agent Payments Protocol
  11. Heng Lu sur la primauté du running code
  12. Heng Lu sur le minimum commun et la décision locale