catégorie · page de référence
Execution Evidence Infrastructure.
Une nouvelle catégorie dans la confiance des paiements.
Le réseau a l'idempotence. Le backend a l'event sourcing. Le rail carte a EMV. L'exécution sur appareil est la seule couche de l'infrastructure de paiement qui n'avait pas d'équivalent. Nous avons nommé la propriété manquante runtime coherence et spécifié le substrat qui l'implémente. Cette page est la référence.
Execution Evidence Infrastructure (EEI) est la couche de preuve liée au terminal pour les paiements numériques. Elle signe ce que le runtime a fait à l'instant de l'action, contre un ledger append-only résident sur l'appareil, et est vérifiable avec une clé publique seule. Aucun backend fournisseur dans le chemin de vérification.
primitive
Trusted Runtime Primitive — enveloppe les syscalls, libc, et appels framework ; signe ce que le runtime fait.
artefact
Evidence Token — JWS compact, ES256, ~200 octets, voyage avec la transaction.
propriété
Sovereign verification — toute partie disposant de la clé publique vérifie indépendamment.
Toute autre couche de partition a été nommée — sauf celle-ci.
L'infrastructure de paiement est un système distribué. Chaque transaction traverse plusieurs nœuds informatiques indépendants échangeant des messages à travers des réseaux non-fiables. Chaque couche qui gère la partition a un nom et une implémentation :
- Le réseau gère la partition avec l'idempotence — la même requête rejouée en sécurité produit un seul effet.
- Le backend gère la partition avec l'event sourcing — l'état divergent se réconcilie contre le log.
- Le rail carte gère la validation de credential avec EMV — authenticité cryptographique au niveau du rail.
La couche d'exécution sur appareil — l'intervalle entre utilisation de credential et réception réseau, là où vivent les ghost transactions et l'ambiguïté de litige — n'avait pas d'équivalent. Pas de nom, pas de spec, pas d'infrastructure. EEI est le substrat qui comble ce gap. La propriété s'appelle runtime coherence. L'implémentation de référence est en production depuis 2019.
Compose avec ce que vous opérez. Ne remplace rien.
Chaque catégorie existante fait quelque chose bien. EEI se place là où elles n'atteignent pas — à la couche d'exécution côté appareil — et produit l'enregistrement signé qu'elles consomment.
| Catégorie | Ce qu'elle fait | Ce qu'elle ne prouve pas | Où EEI se place |
|---|---|---|---|
| Logs backend | Prouvent la réception côté serveur d'une requête transactionnelle. | Ne prouvent pas ce que l'appareil a fait pour produire cette requête, ni dans quel état runtime. | EEI signe l'exécution côté appareil ; l'opérateur combine les deux. |
| RASP | Détecte les menaces runtime sur l'appareil et agit dessus localement. | Ne produit pas par défaut d'evidence transactionnelle portable et vérifiable. | EEI fournit l'enregistrement signé que les parties downstream vérifient ; RASP peut appliquer inline. |
| Device fingerprinting | Identification probabiliste d'un appareil entre sessions. | Ne produit pas un enregistrement déterministe et cryptographiquement signé de l'exécution. | EEI signe l'événement avec une clé liée au matériel ; le fingerprinting peut compléter l'identité. |
| Fraud scoring | Décisions de risque probabilistes basées sur des patterns et signaux. | Ne produit pas d'evidence déterministe utilisable en litige ou audit réglementaire. | EEI fournit un input signé que le score consomme ; le score reste celui de l'opérateur. |
| Attestation plateforme | Prouve l'état de l'appareil ou de l'app au moment d'un appel d'attestation. | Ne prouve pas ce qui s'est passé entre les appels d'attestation — utilisation de credential, biométrie, assemblage de payload. | EEI couvre l'intervalle ; les deux composent en une posture de trust continue. |
| APM / observabilité | Observe la performance, latence, et taux d'erreur des systèmes distribués. | Pas conçu pour la preuve cryptographique de litige ou l'intégrité d'exécution côté appareil. | EEI roule sur la pipeline OpenTelemetry ; APM consomme l'evidence signée comme attribut de span. |
Approfondir : EEI vs RASP · EEI vs Attestation · EEI vs Fingerprinting
Cinq couches. Deux nous appartiennent. Sept primitives entre elles.
-
layer 02
Trusted Runtime Primitive
In-process, in-app. Enveloppe syscalls, libc, appels framework. Signe la runtime coherence avec une clé liée au matériel.
-
layer 03
Evidence Token
JWS compact, ES256, ~200 octets. Voyage inline avec la transaction. Deux profils — Minimal et Standard.
-
layer 03
Local Evidence Ledger
Append-only, hash-linked, sur l'appareil. L'opérateur y accède via le canal forensique Commander — sans tiers dans la boucle.
-
gestion de clés
Zero Trust Bootstrap
Paire de clés générée dans le TEE à la première init. Clé privée ne quitte jamais. Clé publique enregistrée chez l'opérateur.
-
vérification
Sovereign verification
Pipeline en huit étapes. Quatre vérificateurs de référence — Python, JavaScript, Go, Java. Aucun YinkoShield dans le chemin.
-
frontière
Threat model
Quatre classes de menaces in-scope. Quatre out-of-scope, déclarées et pas silencieusement ignorées. Aligné STRIDE.
Architecture complète : /fr/architecture →
EEI n'est pas un moteur de fraud-scoring. Il fournit des signaux signés ; le risk engine de l'opérateur les combine avec le contexte métier.
EEI n'est pas un substitut aux contrôles backend. L'autorisation côté serveur, les systèmes de litiges, et les pipelines de réconciliation restent là où ils sont. EEI ajoute l'enregistrement côté appareil qu'ils n'avaient pas.
EEI n'est pas un dashboard SaaS. Le runtime est livré embarqué dans l'application de l'opérateur. Le vérificateur tourne dans la stack de l'opérateur. Aucun control plane hébergé par YinkoShield dans le chemin de trust.
EEI n'est pas un substitut à la certification scheme. PCI DSS, SOC 2, ISO 27001, programmes scheme (Mastercard, Visa) sont hors-périmètre par construction — déclaré dans CONFORMANCE.md §8 de la spec, pas silencieusement ignoré.
EEI n'est pas un programme de certification. Nous ne certifions pas les opérateurs, processeurs, ou schemes. La spec, les quatre vérificateurs de référence, et les test vectors cross-langage suffisent. L'adoption est une décision d'achat, pas un titre que nous délivrons.
Six parcours opérateur. Un seul substrat signé.
Banques tier-1, réseaux de paiement, schemes, processeurs, et acquéreurs dont les décisions dépendent de l'état d'exécution côté appareil. Choisissez le parcours que vos clients, votre équipe fraude, ou votre équipe ops nommeront à voix haute.
Réseau
Les paiements survivent à la partition. Retries dédupliqués par tctx, orphelins surfacés en temps réel.
Fraude
Comportement adversarial observable à l'exécution. Overlay, repackaging, downgrade — signaux signés.
Expérience
Les faux refus arrêtent d'être l'option par défaut. Le contexte d'auth arrive avec la transaction.
Intégrité
Attribution par appareil. Motifs de rejet de qualité audit, pas d'échec anonyme.
Opérations
Récupération de ledger à la demande, patterns prédictifs, détection de panne de cohorte.
Autonomous
Flows d'agent hash-linked : propose → consent → initiate → confirm. La chaîne casse visiblement.
Dix questions, dix réponses.
Les mêmes questions que les architectes Mastercard, les analystes scheme, et les équipes achats tier-1 ont posées en briefing.
- ·01
Qu'est-ce que l'Execution Evidence Infrastructure ?
- Execution Evidence Infrastructure (EEI) est la couche de preuve liée au terminal pour les paiements numériques. Elle signe ce que le runtime a fait à l'instant de l'action, contre un ledger append-only résident sur l'appareil, et est vérifiable avec une clé publique seule. Aucun backend fournisseur dans le chemin de vérification.
- ·02
Pourquoi cette catégorie existe maintenant ?
- Le réseau a l'idempotence. Le backend a l'event sourcing. Le rail carte a EMV. L'exécution sur appareil est la seule couche de l'infrastructure de paiement qui n'avait pas d'équivalent — jusqu'à ce que la propriété runtime coherence soit nommée et que le substrat qui l'implémente soit spécifié. EEI est ce substrat.
- ·03
Que produit-il ?
- Un Evidence Token — un enregistrement JWS-compact, signé ES256 (~200 octets) qui voyage avec la transaction. Il porte l'identifiant d'appareil, la séquence, le contexte transaction, le nom d'événement, le timestamp, et une référence à l'enregistrement du ledger côté appareil. Toute partie disposant de la clé publique enregistrée par l'opérateur peut le vérifier indépendamment.
- ·04
Quelle est la différence entre EEI et RASP ?
- RASP fournit des interrupteurs binaires par contrôle (activer, désactiver, observer) et décide sur l'appareil. EEI fournit des signaux signés que votre moteur de policy combine avec le contexte métier, et décide côté opérateur. Même surface de menace, point de décision différent — RASP applique, EEI témoigne. Ils composent.
- ·05
Quelle est la différence avec le device fingerprinting ?
- Le fingerprinting est un identifiant probabiliste dérivé des traits de l'appareil. EEI est un enregistrement déterministe et cryptographiquement signé de l'exécution. Le fingerprinting répond à 'est-ce probablement le même appareil ?' ; EEI répond à 'qu'a effectivement fait cet appareil, dans quel ordre, dans quel état runtime ?'.
- ·06
Quelle est la différence avec l'attestation plateforme ?
- L'attestation plateforme (Play Integrity, App Attest) établit que l'appareil était dans un état de trust à un point de contrôle. EEI établit ce qui s'est passé entre les points de contrôle — chaque utilisation de credential, biométrie, assemblage de payload, soumission de requête. L'attestation est ponctuelle ; EEI est continue et ordonnée.
- ·07
La vérification nécessite-t-elle un backend YinkoShield ?
- Non. Le vérificateur de référence tourne dans la stack de l'opérateur contre les clés publiques stockées par l'opérateur. Aucun endpoint YinkoShield dans le chemin de vérification, pas de licence check au runtime, pas de télémétrie que l'opérateur n'a pas demandée. Une panne YinkoShield n'interrompt pas la vérification. Une fin de contrat YinkoShield n'interrompt pas la vérification.
- ·08
Où se déploie-t-il ?
- Mobile (banque, fintech, néobanque, superapp), POS / mPOS / SoftPOS, et terminaux libre-service (SST). Le même Trusted Runtime Primitive est livré sur chaque écosystème ; l'Evidence Token sort dans la même forme sur ~13 000 configurations matérielles.
- ·09
Qui en a besoin ?
- Banques tier-1, réseaux de paiement, schemes, processeurs, et acquéreurs — tout opérateur dont les décisions dépendent de l'état d'exécution côté appareil. Le substrat est en production depuis 2019 sur 30M+ endpoints, référence d'ancrage chez une banque tier-1 sud-africaine.
- ·10
Quel est son rapport avec YEI-001 ?
- YEI-001 est la spécification publiée du substrat EEI. Elle définit le format de l'Evidence Token, le pipeline de vérification en huit étapes, les profils d'intégration (ISO 8583 DE 48 minimal, mobile-wallet-retail, agent-assisted-channel), la frontière du threat model, et la checklist de conformance. Les vérificateurs de référence sont livrés en Python, JavaScript, Go, et Java. La spec est actuellement partagée avec les régulateurs et partenaires qualifiés sous NDA.
YEI-001 est le contrat. Pas une roadmap.
Douze sections, deux annexes, pipeline de vérification en huit étapes, quatre vérificateurs de référence (Python, JavaScript, Go, Java), trois profils d'intégration (ISO 8583 DE 48 minimal, mobile-wallet-retail, agent-assisted-channel), threat model formel, checklist de conformance. Actuellement partagée avec les régulateurs et partenaires qualifiés sous NDA.
Nous briefons les réseaux de paiement, schemes, processeurs, et banques tier-1 sur EEI sur demande.
Pas de pitch commercial. Une conversation technique claire sur la question de savoir si l'execution evidence est le bon substrat pour le problème que vous cherchez à résoudre.
Demander un briefing