Runtime coherence : la couche de partition manquante

Les systèmes de paiement sont des systèmes distribués

L’infrastructure de paiement est typiquement décrite en termes de ses participants — émetteurs, acquéreurs, réseaux, processeurs — et de ses mécanismes de sécurité : credentials cryptographiques, attestation d’appareil, scoring de fraude, surveillance réseau. Ce sont les bonnes dimensions à sécuriser. Ce ne sont cependant pas le bon cadre pour comprendre le problème structurel que ce document adresse.

Le bon cadre est la théorie des systèmes distribués. Chaque transaction de paiement implique plusieurs nœuds informatiques indépendants échangeant des messages à travers des réseaux non-fiables. L’appareil est l’un de ces nœuds : il détient un état local, effectue un calcul local, et peut subir des défaillances, des partitions, et des divergences d’état indépendamment du reste du système.

Dans les systèmes distribués, un nœud qui perd la connectivité ne s’arrête pas de calculer. Il continue à exécuter, accumule un état local, et opère sous information partielle. Quand la connectivité est restaurée, le système doit réconcilier l’état divergent. C’est le problème structurel au cœur de chaque ghost transaction.

Ce que les standards existants observent — et ce qu’ils n’observent pas

L’industrie du paiement a construit une infrastructure sophistiquée pour sécuriser le credential carte et le rail de transaction. Les spécifications EMV chip et contactless définissent comment les credentials sont authentifiés et comment les transactions sont validées au niveau réseau. EMV 3DS collecte des données d’environnement appareil au moment de l’authentification : empreinte navigateur, attributs d’appareil collectés par le SDK, fournissant un instantané de l’état appareil à un moment du flow.

Ce qu’aucun de ces standards n’instrumente, c’est l’état d’exécution de l’appareil sur l’ensemble du flow transactionnel. Les données EMV répondent : un credential valide a-t-il autorisé cette transaction sur ce rail ? Elles ne répondent pas : quel était l’état runtime de l’appareil quand ce credential a été utilisé, dans quelle séquence d’exécution, et cette séquence était-elle cohérente ?

Les mécanismes d’attestation de plateforme — y compris ceux fournis par les fournisseurs d’OS mobiles — adressent l’intégrité de l’appareil au moment de l’appel d’attestation. Ils établissent si l’appareil est dans un état de trust à un point de contrôle. Ils n’établissent pas ce que l’appareil a fait entre les points de contrôle, dans quelle séquence, ou si le chemin d’exécution entre le résultat d’attestation et la requête réseau était cohérent. C’est l’intervalle que runtime coherence instrumente. Les deux sont complémentaires : l’attestation établit le point de contrôle ; runtime coherence établit ce qui s’est passé entre les points de contrôle.

EMV 3DS et EEI — où l’un s’arrête et l’autre commence

EMV 3DS 2.x et EEI sont adjacents, pas chevauchants. 3DS collecte un instantané descriptif de l’appareil au moment de l’authentification et le remet à l’ACS de l’émetteur. EEI signe la trajectoire runtime entre cet instantané et la réception réseau. La forme du delta :

Les deux sont conçus pour composer. 3DS répond : ce credential peut-il autoriser cette transaction à ce moment ? EEI répond : qu’a fait le runtime entre ce moment et la réception réseau, et la séquence était-elle cohérente ? Les opérateurs qui consomment les deux ont une boucle fermée entre l’identité du credential et l’execution evidence.

L’état de la gestion de partition à travers la stack

La gestion de partition au niveau réseau a un nom : idempotence. La réconciliation d’état du backend a un nom : event sourcing. La validation de credential du rail carte a un nom : EMV. Ces noms existent parce qu’ils correspondent à une infrastructure spécifiée qui implémente une propriété bien définie — une propriété qui a été identifiée, nommée, puis construite.

La cohérence d’exécution sur appareil — la capacité d’établir ce qu’un appareil a fait, dans quel ordre, dans quel état runtime, entre une utilisation de credential et une réception réseau — n’a pas d’équivalent nommé dans les standards d’infrastructure de paiement. Elle n’a pas de nom parce qu’elle n’a pas d’implémentation. Ce document la nomme runtime coherence et spécifie l’infrastructure qui l’implémente.

Runtime coherence est une nouvelle catégorie d’infrastructure, pas une extension d’une existante. Elle adresse la couche d’exécution sur appareil : l’intervalle entre utilisation de credential et réception réseau qu’aucun standard existant n’instrumente, ne nomme, ou ne spécifie. EEI est l’implémentation de référence de cette catégorie.

Les quatre propriétés de runtime coherence

Pourquoi ce gap n’a pas été comblé

La couche d’exécution sur appareil est le dernier problème de partition non-résolu dans l’infrastructure de paiement. Il est raisonnable de demander pourquoi, si le gap est aussi clair, il n’a pas déjà été adressé par les participants majeurs de l’écosystème.

La réponse est le coût d’ingénierie, pas la conscience du problème. Combler ce gap exige d’opérer une infrastructure qui n’existe pas dans les organisations standards d’ingénierie paiement :

• Couverture de population d’appareils à l’échelle de production. Des garanties d’evidence cohérentes sur des dizaines de millions d’endpoints exigent une couche d’abstraction matérielle validée contre la distribution complète des configurations d’appareils réelles — pas un échantillon représentatif. La queue de la distribution est l’endroit où les défaillances de production arrivent.
• Régression continue à travers la fragmentation matérielle. La disponibilité du TEE, le comportement du Keystore, et la couverture des APIs plateforme changent à chaque cycle de release des fabricants. Maintenir des garanties d’evidence cohérentes exige des fermes d’appareils, des pipelines de régression continue, et une capacité d’ingénierie dédiée à suivre la variance matérielle, pas le comportement applicatif.
• Chaos engineering pour les scénarios de partition. Ghost transactions, file offline, dual-SIM swap, environnements RTC-only, et tempêtes de retry sous réseaux dégradés ne sont pas reproductibles dans des environnements de test standards. Valider la cohérence du ledger sous ces conditions exige une simulation réseau et une infrastructure d’interruption d’exécution conçues spécifiquement.
• Validation runtime adversariale. L’intégrité de l’evidence sous compromission active — pas la simple présence statique d’une menace, mais une attaque triggered, dormante, ou par injection contre la couche de génération d’evidence — exige une automatisation de tests adversariaux qui dépasse l’outillage standard de tests de sécurité.

Ce coût d’infrastructure est la raison pour laquelle l’execution evidence n’existe pas comme capacité native dans les stacks de paiement. Le problème opérationnel d’ambiguïté côté appareil a été observé en production — dans les taux de faux refus, le coût de réconciliation, et le coût de résolution de litiges — mais l’investissement d’ingénierie nécessaire pour le résoudre à la couche infrastructure n’a pas été fait, parce qu’il se trouve hors du cœur de compétence des organisations d’infrastructure de paiement, dont l’ingénierie est optimisée pour le traitement de messages, la gestion de credentials, et le scoring de risque, pas l’observation d’exécution au niveau appareil.

Le déploiement de production de YinkoShield représente la résolution de ce coût d’infrastructure, pas son évitement. Les cas limites documentés dans les caractéristiques de production de la spec ne sont pas théoriques. Ce sont les cas qui apparaissent quand l’infrastructure d’execution evidence tourne à l’échelle sur des populations d’appareils hétérogènes sous conditions réseau réelles. Les résoudre est la barrière à l’entrée.

Ce que runtime coherence rend possible, en termes concrets

L’Evidence Token, en deux profils

L’evidence est livrée comme un token JWS-compact-encoded ES256, embarqué avec chaque événement transactionnel significatif. Deux profils sont définis.

Le Minimal Profile (~200 octets) est par défaut. Il porte les claims minimales requises pour vérifier l’étape d’exécution, corréler les retries déterministiquement, et évaluer l’état appareil, sans avoir à fetch l’Evidence Record complet depuis le ledger appareil.

{
"eid": "8f1e3a90-2b4c-4f81-b6d7-1c9c3a1f4d12",
"seq": 1044,
"tctx": "01J0T8VQ4F",
"event": "payment.initiated",
"ts": 1714323105421,
"did": "did:yks:Z2gXf...",
"kid": "k.2025-Q2.r3",
"sig_ref": { "url": "yks-ledger://...", "hash": "0x9c4a..." }
}

Le Standard Profile (~300 octets) ajoute le contexte d’état de connectivité inline — boot_id, net.connected, net.type, scope — pour que la gateway puisse absorber la logique de retry, l’exécution offline-queued, et les décisions de continuité SIM dans la même requête, sans aller-retour supplémentaire.

Où l’opérateur place le contrôle

Parce que l’evidence est portable et vérifiable avec une clé publique seule, l’opérateur choisit où dans sa stack l’évaluer. C’est une propriété architecturale d’EEI, pas une option de déploiement.

La même evidence peut être consommée à plusieurs points de contrôle simultanément. Une gateway en bord verifie le token inline ; l’émetteur applique la policy de risque dans le chemin d’autorisation ; la plateforme de litiges récupère l’enregistrement complet du ledger asynchrone. Aucune duplication de génération d’evidence n’est requise.

En une phrase

Tant que les appareils mobiles auront été des endpoints de paiement, l’intervalle d’exécution entre l’action de l’appareil et la réception réseau aura été l’angle mort structurel de l’infrastructure de paiement. Le Trusted Runtime Primitive le rend observable. Runtime coherence le rend vérifiable. Le découplage policy-exécution le rend opérationnellement flexible. L’evidence voyage avec la transaction, ou attend dans le ledger jusqu’à ce qu’on en ait besoin.

Références et alignement standards

EEI est une nouvelle catégorie architecturale à la couche d’exécution sur appareil, pas une extension d’un standard existant. La filiation que la spec cite ou avec laquelle elle compose réellement :

• RFC 2119 — Discipline des mots-clés utilisée à travers la spec normative.
• RFC 7515 — JWS — Enveloppe Evidence Token : JWS compact, ES256, trois segments base64url.
• RFC 4648 §5 — Encodage Base64url-without-padding utilisé pour les signatures.
• RFC 6979 — Option ECDSA déterministe pour la discipline de signing-nonce du producteur (CSPRNG également accepté).
• ISO 8583 — DE 48 / DE 124 / DE 125 portent l’Evidence Token via l’enveloppe BER-TLV 0xF0 — un tag de classe privée, constructed, choisi spécifiquement parce qu’il ne conflicte pas avec les sous-éléments définis Mastercard ou Visa.
• EMV / EMV 3DS — Authentification de credential et validation de rail. Adjacent et orthogonal à EEI ; les résultats d’authentification scheme se lient aux événements EEI seulement quand le programme d’un opérateur le dit explicitement.
• STRIDE — Méthodologie utilisée dans le THREAT_MODEL.md de la spec pour le tableau in-scope-vs-residual-risk.
• POPIA §11 — La conformance producteur pour les consommateurs sud-africains exige le profil de privacy strict ; pas de logging brut (device_id, tctx) sans une base de traitement légale documentée.

Voir la table complète d’alignement standards sur la page spécification →