spécification · YEI-001 v1.0
La spécification est l'artefact. La forme est ouverte.
YEI-001 est la spécification publiée de l'Execution Evidence Infrastructure. Le corps des sections est partagé sous NDA avec les régulateurs et partenaires qualifiés. La forme — sommaire, contrat de vérificateur en huit étapes, quatre implémentations de référence, et les standards à côté desquels elle se situe — est ouverte. À lire avant de demander le corps.
Douze sections, deux annexes. La catégorie, l'architecture, le contrat de vérificateur, la frontière du threat model.
Chaque ligne renvoie à l'article de fond public quand il existe, ou déclare la section comme sous NDA quand son contenu constituerait du blueprint. Pas de troisième option.
- §1
Périmètre et public
Public visé : architectes de réseaux de paiement, ingénieurs de plateforme, responsables d'infrastructure d'autorisation.
outline public - §2
Terminologie
Définitions canoniques : TRP, Runtime Coherence, Evidence Token, Local Evidence Ledger, ZTBP, Sovereign Verification.
outline public - §3
La catégorie — runtime coherence
L'argument structurel. Gestion de partition à travers la pile. Pourquoi l'exécution sur l'appareil est la dernière couche de partition non résolue.
LIRE → - §4
Modèle architectural
Cinq couches, sept primitives, deux profils, trois canaux d'intégration.
LIRE → - §5
Trusted Runtime Primitive
Interface de wrapping d'appels, mesure du runtime, observation des syscalls, déclaration de la base de confiance.
LIRE → - §6
L'Execution Evidence Layer
Evidence Token (§6.5), Local Evidence Ledger et Commander (§6.6), Zero Trust Bootstrap Protocol (§6.6).
LIRE → - §6 · CONFORMANCE
Sovereign verification — pipeline en huit étapes
Contrat du vérificateur côté opérateur. Vecteurs de tests cross-langage. Codes de rejet diagnosticables.
LIRE → - §7
Applications
Sept applications travaillées : arbitration, substrat analytique, défense de litiges, fraude, confiance continue, exécution zero-trust, exécution autonome.
LIRE → - §8 · THREAT_MODEL
Threat model
Quatre classes in-scope, quatre classes out-of-scope. Méthodologie de validation adversariale.
LIRE → - §9
Caractéristiques de production
Cas-limites résolus à l'échelle : clock skew, dual-SIM swap, reconstruction de ledger, retry storms, continuité POS hors-ligne.
sous NDA - §10
Principes de design
Six trade-offs déclarés explicitement : evidence-without-enforcement, what-not-how, additive, scheme-agnostic, offline-first, privacy-by-design.
LIRE → - Annexe A
Extension agentic-payments
Claims de chaîne de délégation, attestation d'agent, séparation intent-vs-execution, attribution multi-étapes.
sous NDA
Le pipeline de vérification en huit étapes.
Ce que fait un vérificateur d'Evidence Token, dans la stack de l'opérateur, contre les clés publiques stockées par l'opérateur. Aucun endpoint YinkoShield dans le chemin. Chaque raison de rejet est spécifique.
- ·1
Parser le JWS
Couper le JWS compact sur `.` en header / payload / signature. Décoder le header ; exiger `alg = ES256` et `kid` présent. Rejeter `alg = none` et tout autre algorithme.
- ·2
Résoudre la clé
Chercher `kid` dans le key store de l'opérateur. Si inconnu, tenter au plus un re-fetch via un canal mutually-authenticated. Rejeter sinon.
- ·3
Vérifier la signature
ES256 sur `BASE64URL(header).BASE64URL(payload)` avec la clé publique résolue. Rejeter sur tout échec cryptographique.
- ·4
Valider les claims
Décoder le payload. Exiger `eid`, `did`, `kid`, `ts`, `seq`, `event_name`, `tctx`, `sig_ref`. Le `kid` du header DOIT correspondre au `kid` du payload. Rejeter si manquant ou mal formé.
- ·5
Vérifier la fraîcheur
Rejeter si `ts` est hors de la fenêtre de fraîcheur définie par l'opérateur (recommandé ±5 minutes). La fenêtre est une politique ; la borne est configurable par l'opérateur.
- ·6
Contrôle de replay
Rejeter si `(did, tctx, event_name, seq)` est déjà présent dans le dedup store. Le store DOIT être partagé et atomique sur toutes les instances de vérificateur.
- ·7
Sequence regression
Pour les événements de retry (`payment.retry`, `pos.txn.retry`, `login.retry`, `auth.retry`), exiger `seq` strictement supérieur à tous les `seq` antérieurs pour le même `tctx`. Rejeter sinon.
- ·8
Niveau de confiance
Résoudre le niveau de confiance depuis l'Evidence Record lié quand il est récupéré (`hardware_backed` / `hardware_bound` / `execution_proof` / `compromised_device`) ; sinon retourner `software_layer`. La confiance est déclarée, jamais inférée.
Les quatre vérificateurs de référence — Python, JavaScript, Go, Java — se contre-vérifient mutuellement contre un corpus partagé de 23 vecteurs de test : 3 valides (Minimal Profile, Standard Profile, retry event) et 20 invalides répartis en signature-forged (4), algorithm-confusion (2), expired-token (2), replay-attack (1), missing-fields (8), sequence-regression (1), broken-chain (2). Le même token se vérifie de la même façon dans chaque langage, sinon l'un d'eux est cassé. Lire l'article de fond · EN →
Quatre implémentations indépendantes du même contrat.
Chaque vérificateur est livré avec la spec. Chacun est assez petit pour qu'un opérateur puisse le lire de bout en bout avant de l'adopter. Aucun ne fait d'appel sortant.
La filiation à côté de laquelle on se place — pas au-dessus.
EEI est une nouvelle catégorie au niveau de la couche d'exécution sur l'appareil. Ce n'est pas une extension de ces standards — mais ça en est la filiation. Quand la spec utilise une enveloppe, un vocabulaire, ou un modèle, l'original est nommé.
- RFC 2119
Key words for use in RFCs
Discipline normative MUST / SHOULD / MAY utilisée dans toute la spec.
- RFC 7515
JSON Web Signature (JWS)
Enveloppe de l'Evidence Token — JWS compact, trois segments base64url, ES256 uniquement.
- RFC 4648 §5
Base64url (sans padding)
Encodage utilisé pour la valeur de signature JWS et la signature ES256 du record.
- RFC 6979
ECDSA déterministe
Exigence côté producteur : la signature ECDSA DOIT utiliser un nonce CSPRNG ou la génération déterministe RFC 6979.
- ISO 8583
Format de message orienté carte
DE 48 / DE 124 / DE 125 portent l'Evidence Token via l'enveloppe BER-TLV 0xF0. Le tag 0xF0 est private-class, constructed — non-conflictuel avec les ranges de subelements définis Mastercard ou Visa.
- EMV / EMV 3DS
Authentification de credential et validation rail
Adjacent et orthogonal. Les outcomes d'authentification scheme sont liés aux événements EEI uniquement quand le programme de l'opérateur le précise explicitement.
- STRIDE
Discipline de threat modelling
Le `THREAT_MODEL.md` de la spec est une analyse STRIDE-oriented avec déclarations explicites de risques résiduels.
- POPIA §11
Protection des données sud-africaine
Pour la conformance côté producteur sur consommateurs SA, le profil de privacy `strict` est requis ; pas de logging brut de `(device_id, tctx)` sans base de traitement légale documentée.
Ce que la spec est — et ce qu'elle n'est délibérément pas.
La spec est un contrat entre le runtime et le vérificateur. Un opérateur capable de lire la spec peut implémenter un vérificateur. La conformance est auto-vérifiable contre le corpus partagé de vecteurs de tests que les quatre vérificateurs de référence utilisent déjà entre eux.
Il n'y a pas de programme de certification émis par YinkoShield. Nous ne certifions pas les opérateurs, processeurs, ou schemes. La spec, les vérificateurs, et les vecteurs de test sont suffisants. L'adoption est un choix, pas un titre que nous délivrons.
Il n'y a pas de backend vendor dans le chemin de confiance. Le TRP tourne dans l'application de l'opérateur. Le vérificateur tourne dans la stack de l'opérateur. Les clés sont enregistrées sur le backend de l'opérateur. Une panne YinkoShield n'interrompt pas la vérification ; YinkoShield n'est pas dans le chemin de vérification.
Le contenu sous NDA est borné. Les caractéristiques de production (§9) et l'extension agentic-payments (Annexe A) sont les parties qui ne sont pas sur ce site. Leur forme est publiée ; leur contenu est partagé avec les régulateurs et partenaires qualifiés.
La spec est partagée avec les régulateurs et partenaires qualifiés.
Écrivez-nous votre contexte — rôle scheme, processeur, banque tier-1, régulateur, ou architecte scheme. Nous répondons sous deux jours ouvrés. Pas de pitch commercial ; pas de sandbox publique non plus, parce que ce qui est gated, c'est le corps de la spec, pas un service.
Demander l'accès à YEI-001