Plongée Approfondie : L'Intention Vérifiable de Mastercard vs le Protocole d'Agent de Confiance de Visa

Agentic Le commerce remet en question une hypothèse fondamentale des paiements en ligne, à savoir qu’un humain clique directement sur « acheter » sur une surface de confiance. Une fois que le logiciel peut naviguer, décider et effectuer des transactions, les commerçants et les réseaux perdent le plus simple des primitives de sécurité : « le client était ici. »

Cela crée trois défaillances de confiance concrètes qui se manifestent par des coûts opérationnels :

Les commerçants ont besoin d’un moyen de distinguer un agent légitime, autorisé par l’utilisateur, d’une automatisation malveillante et du trafic de bots, sans réécrire leur infrastructure ni bloquer accidentellement des sessions précieuses.

Les réseaux de paiement et les émetteurs ont besoin d’une piste d’audit déterministe de ce que l’utilisateur a autorisé, de ce que l’agent a fait, et de ce que le commerçant a facturé, afin que les litiges et décisions de fraude puissent s’appuyer sur des preuves plutôt que sur des inférences.

Les agents ont besoin d’un moyen portable de transporter la preuve d’autorité à travers les commerçants, appareils et protocoles, dans des modes d’exécution avec ou sans présence humaine.

Les deux, Mastercard Verifiable Intent et Visa Trusted Agent Protocol, sont des « couches de confiance », mais elles se situent à différentes parties de la pile et optimisent pour différents vérificateurs.

Différences dans la position dans la pile et le modèle de preuve

I Je vois le contraste comme étant « preuve de chaîne de crédentiels » versus « attestation en bordure HTTP ».

Mastercard Verifiable Intent est structuré comme un objet de preuve multi-parties destiné à survivre au-delà de la session de navigation. La chaîne lie l’assurance de l’identité de l’émetteur, l’autorisation de l’utilisateur, et l’exécution par l’agent, avec des liens explicites d’intégrité entre le processus de paiement et les artefacts de paiement.

Visa Trusted Agent Protocol est structuré comme un signal d’interaction en temps réel pour les commerçants et leurs couches de protection. L’artefact principal est un contexte de requête HTTP signé, plus des objets liés pour la reconnaissance du consommateur et les données du conteneur de paiement. Il optimise pour « s’agit-il d’un agent de confiance interagissant avec ma propriété web en ce moment », et non « un émetteur peut-il juger une intention déléguée ultérieurement ».

Les ancrages de confiance sont différents.

Verifiable Intent s’ancre sur un émetteur de crédentiels de paiement (institution financière ou réseau dans le rôle d’émetteur) délivrant la couche 1, puis l’utilisateur signant la couche 2, puis l’agent signant la couche 3 avec des clés liées via la sémantique cnf. C’est une preuve de délégation sous forme de chaîne cryptographique.

Trusted Agent Protocol s’ancre sur la participation au programme et les registres de clés au niveau web, l’agent prouvant la possession d’une clé via des signatures RFC 9421, et le commerçant récupérant la clé publique dans un magasin de confiance. Par ailleurs, Visa signe le jeton d’identité utilisé pour la reconnaissance du consommateur dans l’implémentation de Visa.

Le positionnement en matière de confidentialité est également structurellement différent.

Verifiable Intent utilise la divulgation sélective SD-JWT pour faire de la moindre divulgation une propriété centrale : le commerçant voit les divulgations de mandat de paiement ; le réseau voit celles du mandat de paiement ; la séparation de la liaison L3 est explicitement conçue pour préserver cette frontière.

Trusted Agent Protocol utilise l’obfuscation et la partition de charge utile, mais il n’est pas construit autour d’engagements de divulgation sélective dans une seule chaîne de crédentiels. Il suppose que les commerçants peuvent avoir besoin de tables de correspondance pour réconcilier des champs d’identité obfusqués, et il permet au contenu du conteneur de paiement de varier selon la méthode de paiement.

Si je résume en une ligne : Verifiable Intent est conçu pour l’auditabilité à travers les rôles et le temps ; Trusted Agent Protocol est conçu pour une interaction sûre et une reconnaissance à la frontière du commerçant.

Réalités d’intégration pour les constructeurs de fintech

Ces solutions ne sont pas mutuellement exclusives. Elles abordent différents modes de défaillance qui coexisteront en production.

Si je construis une infrastructure pour commerçants, Trusted Agent Protocol correspond aux artefacts d’ingénierie immédiats : vérification en bordure des signatures de requêtes RFC 9421, récupération et mise en cache des clés, suivi des rejets de nonce, et un gestionnaire interne qui décide si une session entrante doit être traitée comme « intention de commerce par agent » en fonction du tag.

C’est le bon périmètre si mon problème concerne la mitigation des bots, les faux positifs, et le trafic automatisé inconnu. Visa encadre explicitement le protocole comme un moyen d’éviter de bloquer des agents légitimes et de les distinguer des bots malveillants, avec peu de modifications pour le commerçant.

Si je construis un portefeuille, un émetteur, une orchestration de paiements ou une infrastructure adjacente au réseau, Verifiable Intent est la primitive la plus pertinente car elle définit ce que le vérificateur peut conserver comme preuve de litige et comment la chaîne d’autorisation se lie aux clés et contraintes. Le format de crédentiel est normatif, le vocabulaire des contraintes est normatif, et l’analyse des menaces est construite autour des frontières de délégation.

Le coût d’intégration non évident concerne la garde des clés et les surfaces de signature.

Verifiable Intent suppose une clé de signature utilisateur liée à la couche 1, utilisée pour signer la couche 2. La spécification évoque explicitement des modèles de déploiement où « l’utilisateur crée la L2 » peut signifier un système autorisé détenant la clé privée de l’utilisateur, et considère la compromission de la clé utilisateur comme une prise de contrôle complète du compte pour toute la durée de la crédentiale de la couche 1.

Trusted Agent Protocol suppose une paire de clés d’agent utilisée pour signer les signatures de messages HTTP et les objets liés. La découverte et la mise en cache des clés sont considérées comme une responsabilité du commerçant, avec des directives opérationnelles explicites concernant les horodatages, l’expiration et la rejoue.

Si je construis une plateforme d’agents, je prévois les deux, car je dois encore traverser en toute sécurité les propriétés du commerçant avant d’atteindre un événement d’autorisation de paiement.

L’attestation de type TAP résout le problème de « navigation et interaction sans blocage » et fournit un canal pour que les commerçants demandent des informations supplémentaires ou un paiement pour accéder à des ressources comme des avis.

La preuve de délégation de type VI résout le problème de « l’autorisation autonome dans des contraintes définies par l’utilisateur et la conservation de la preuve pour le réseau et le litige », avec un lien explicite entre les mandats de paiement et de paiement.

La posture des standards est convergente même si les artefacts diffèrent. Mastercard indique explicitement que Verifiable Intent s’appuie sur des standards largement adoptés, notamment FIDO Alliance, EMVCo, IETF, et W3C.

Visa indique explicitement son alignement avec des organismes de normalisation comme l’IETF, la OpenID Foundation, et EMVCo, et présente Trusted Agent Protocol comme basé sur la norme HTTP Message Signatures et aligné avec Web Bot Auth.