Architecture / architecture · 03
L'Evidence Token : deux profils
JWS compact, ES256, inline avec chaque requête. Deux profils — Minimal (~200 octets) pour les canaux à budget d'octets serré, Standard (~300 octets) pour la richesse forensique. Mêmes sémantiques cryptographiques, même chemin de code vérificateur, enveloppe différente.
Ce qui voyage avec la transaction
L’Evidence Token est le porteur. Chaque événement signé du TRP est encodé comme un token JWS-compact-encoded ES256 et embarqué avec la transaction à laquelle il se rapporte. Les propriétés cryptographiques sont les mêmes quel que soit le canal qui le porte — HTTP header, OpenTelemetry span attribute, ISO 8583 DE 48, ou accès direct par SDK.
outcomes
Ce que cela vous permet de faire aujourd'hui que vous ne pouviez pas avant
-
Appliquer une policy d'evidence signée à l'intérieur des chemins d'autorisation existants
Pas de nouveau canal de transit à onboarder. Votre flow d'auth reste le même ; le token roule le long de la requête que vous faites déjà.
-
Dédupliquer les retries déterministiquement
Le champ de corrélation tctx identifie les retries du même contexte d'exécution — la suppression de doublons arrête d'être une heuristique et devient un output du vérificateur.
-
Vérifier le même enregistrement à plusieurs points de contrôle
Gateway en bord, émetteur backend, plateforme de litiges post-auth — chacun consomme le même token sans le ré-émettre. Aucune duplication de génération d'evidence.
-
Traverser schemes, géographies, plateformes avec une seule forme de token
Aucun champ scheme-spécifique, aucun encodage scheme-spécifique requis. Le même token opère à travers les réseaux sur lesquels l'opérateur tourne déjà.
-
Adopter incrémentalement sans coordination
Un backend qui ne consomme pas encore l'evidence l'ignore sans impact. Vous pouvez livrer le token avant que chaque consommateur soit prêt.
Deux profils
Minimal Profile · ~200 octets
Par défaut. Porte les claims minimales requises pour vérifier l’étape d’exécution, corréler les retries déterministiquement via tctx, 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 Minimal Profile rentre dans ISO 8583 DE 48 avec une enveloppe BER-TLV à ~216 octets au total — le rendant déployable à travers les chemins acquéreurs et schemes sans changement de format de message scheme.
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. Le choix naturel quand le canal consommateur a un budget d’octets — HTTP authorization, le bridge OpenTelemetry, ou consommation in-process via le SDK.
{
"schema_v": 1,
"eid": "8f1e3a90-2b4c-4f81-b6d7-1c9c3a1f4d12",
"did": "b262eacf9d58d9f3...a46e6",
"kid": "b262eacf9d58d9f3...a46e6.sign.v1",
"ts": 1714323105421,
"seq": 1044,
"event_name":"payment.initiated",
"tctx": "tctx-3e9a1f2b7c4d8e56a0b3c6d9",
"boot_id": "01J0T7K3M2-3a8c4f9e",
"scope": "payment",
"net": {
"connected": true,
"type": "cellular"
},
"sig_ref": {
"ledger_seq": 1044,
"segment_id": 7
}
}L’output du vérificateur pour ce token, contre la clé publique stockée par l’opérateur, avec l’Evidence Record correspondant fetché et hash-bound :
·1 parse JWS ✓ alg=ES256 · kid present
·2 resolve key ✓ kid hit in operator store
·3 verify signature ✓ ES256 over header.payload
·4 validate claims ✓ required fields present · header kid = payload kid
·5 enforce freshness ✓ ts within ±5 min window
·6 replay check ✓ (did, tctx, event_name, seq) atomic-insert OK
·7 sequence regression — not a retry event (skipped per spec)
·8 trust level = hardware_bound
verdict: VALID
trust: hardware_bound
binding: token ↔ record OK (eid, did/device_id, tctx, seq, ledger_seq match)properties
Ce que vous obtenez quand vous le câblez
-
·01 Carriage inline
Le token voyage avec la requête à laquelle il se rapporte. Pas de second appel, pas de fetch out-of-band.
-
·02 Schéma stable et additif
Rétrocompatible. De nouvelles claims peuvent être ajoutées ; les anciens vérificateurs les ignorent gracieusement.
-
·03 Parité de profil
Minimal et Standard sont lus par le même chemin de code vérificateur. Le budget d'octets change ; la logique non.
-
·04 Agnosticisme de canal
HTTP header, OpenTelemetry span attribute, ISO 8583 DE 48 / DE 124 / DE 125, ou consommation SDK directe — choisissez-en un, choisissez les quatre.
-
·05 Structure identifiable
eid (event id), seq (séquence par appareil), tctx (transaction context), kid (key id) — chaque claim est ciblable en policy.
-
·06 Vérification déterministe
ES256 sur la structure JWS-compact-encoded. Même input, même verdict, à chaque fois.
Chemin de vérification
Les deux profils se vérifient identiquement. Le vérificateur — Python, JavaScript, Go, ou Java — vérifie la signature ES256, le key binding, la continuité de la hash-chain contre le hash du token précédent, la fenêtre de fraîcheur, et la déclaration de trust-basis. Le même pipeline en huit étapes quel que soit le profil.
Où en lire plus
La structure complète de l’Evidence Token — définitions de claims, signal model, enveloppe cryptographique — vit dans YEI-001 §6.5, partagée avec les régulateurs et partenaires qualifiés sous NDA.