specification · YEI-001 v1.0
The specification is the artefact. The shape is open.
YEI-001 is the published specification of the Execution Evidence Infrastructure. The section bodies are shared with regulators and qualifying partners under NDA. The shape — table of contents, the eight-step verifier contract, the four reference implementations, and the standards we sit beside — is open. Read it before you request the body.
Twelve sections, two annexes. The category, the architecture, the verifier contract, the threat boundary.
Each row links to the public deep article where one exists, or declares the section as under NDA when its content would constitute blueprint. There is no third option.
- §1
Scope and audience
Audience: payment-network architects, platform engineers, authorization infrastructure owners.
public outline - §2
Terminology
Canonical definitions: TRP, Runtime Coherence, Evidence Token, Local Evidence Ledger, ZTBP, Sovereign Verification.
public outline - §3
The category — runtime coherence
The structural argument. Partition handling across the stack. Why device execution is the last unresolved partition layer.
READ → - §4
Architectural model
Five layers, seven primitives, two profiles, three integration channels.
READ → - §5
Trusted Runtime Primitive
Call-wrapping interface, runtime measurement, syscall observation, trust-basis declaration.
READ → - §6
The Execution Evidence Layer
Evidence Token (§6.5), Local Evidence Ledger and Commander (§6.6), Zero Trust Bootstrap Protocol (§6.6).
READ → - §6 · CONFORMANCE
Sovereign verification — eight-step pipeline
Operator-side verifier contract. Cross-language test vectors. Diagnosable rejection codes.
READ → - §7
Applications
Seven worked applications: arbitration, analytical substrate, dispute defence, fraud, continuous trust, zero-trust execution, autonomous execution.
READ → - §8 · THREAT_MODEL
Threat model
Four in-scope classes, four out-of-scope classes. Adversarial validation methodology.
READ → - §9
Production characteristics
Edge cases solved at scale: clock skew, dual-SIM swap, ledger reconstruction, retry storms, offline POS continuity.
under NDA - §10
Design principles
Six trade-offs declared explicitly: evidence-without-enforcement, what-not-how, additive, scheme-agnostic, offline-first, privacy-by-design.
READ → - Annex A
Agentic-payments extension
Delegation chain claims, agent-identity attestation, intent-vs-execution split, multi-step attribution.
under NDA
The eight-step verification pipeline.
What an Evidence Token verifier does, in the operator's stack, against the operator's stored public keys. No YinkoShield endpoint in the path. Every reject reason is specific.
- ·1
Parse JWS
Split the compact JWS on `.` into header / payload / signature. Decode the header; require `alg = ES256` and `kid` present. Reject `alg = none` and any other algorithm.
- ·2
Resolve key
Look up `kid` in the operator's key store. If unknown, attempt at most one re-fetch over a mutually-authenticated channel. Reject if still missing.
- ·3
Verify signature
ES256 over `BASE64URL(header).BASE64URL(payload)` using the resolved public key. Reject on any cryptographic failure.
- ·4
Validate claims
Decode the payload. Require `eid`, `did`, `kid`, `ts`, `seq`, `event_name`, `tctx`, `sig_ref`. Header `kid` MUST equal payload `kid`. Reject on missing or malformed fields.
- ·5
Enforce freshness
Reject if `ts` falls outside the operator-defined freshness window (recommended ±5 minutes). Window is policy; the bound is operator-configurable.
- ·6
Replay check
Reject if `(did, tctx, event_name, seq)` is already present in the dedup store. Store MUST be shared and atomic across all verifier instances.
- ·7
Sequence regression
For retry events (`payment.retry`, `pos.txn.retry`, `login.retry`, `auth.retry`), require `seq` greater than every prior `seq` for the same `tctx`. Reject otherwise.
- ·8
Trust level
Resolve trust level from the linked Evidence Record when fetched (`hardware_backed` / `hardware_bound` / `execution_proof` / `compromised_device`); otherwise return `software_layer`. Trust is declared, never inferred.
The four reference verifiers — Python, JavaScript, Go, Java — cross-check each other against a shared corpus of 23 test vectors: 3 valid (Minimal Profile, Standard Profile, retry event) and 20 invalid across signature-forged (4), algorithm-confusion (2), expired-token (2), replay-attack (1), missing-fields (8), sequence-regression (1), and broken-chain (2) categories. The same token verifies the same way in every language, or one of them is broken. Read the deep article →
Four independent implementations of the same contract.
Each verifier ships with the spec. Each is small enough that an operator can read it end-to-end before adopting it. None of them call home.
The lineage we sit beside, not above.
EEI is a new category at the device-execution layer. It is not an extension of these standards — but it is in their lineage. Where the spec uses an envelope, a vocabulary, or a model, the original is named.
- RFC 2119
Key words for use in RFCs
Normative MUST / SHOULD / MAY discipline used throughout the spec.
- RFC 7515
JSON Web Signature (JWS)
Evidence Token envelope — JWS compact, three base64url segments, ES256 only.
- RFC 4648 §5
Base64url (no padding)
Encoding for the JWS signature value and the ES256 record signature.
- RFC 6979
Deterministic ECDSA
Producer requirement: ECDSA signing MUST use a CSPRNG nonce or RFC 6979 deterministic generation.
- ISO 8583
Card-originated message format
DE 48 / DE 124 / DE 125 carry the Evidence Token via the 0xF0 BER-TLV envelope. Tag 0xF0 is private-class, constructed — non-conflicting with defined Mastercard or Visa subelement ranges.
- EMV / EMV 3DS
Credential authentication and rail validation
Adjacent and orthogonal. Scheme authentication outcomes are linked to EEI events only when an operator's program explicitly says so.
- STRIDE
Threat-modelling discipline
The spec's `THREAT_MODEL.md` is a STRIDE-oriented analysis with explicit residual-risk declarations.
- POPIA §11
South African data protection
Producer conformance for SA consumers requires the strict privacy profile; no raw `(device_id, tctx)` logging without lawful processing basis.
What the spec is — and what it deliberately is not.
The spec is a contract between the runtime and the verifier. An operator who can read the spec can stand up a verifier. Conformance is self-checkable against the shared test-vector corpus the four reference verifiers already use against each other.
There is no YinkoShield-issued certification programme. We do not certify operators, processors, or schemes. The spec, the verifiers, and the test vectors are sufficient. Adoption is a choice, not a credential.
There is no vendor backend in the trust path. The TRP runs in the operator's application. The verifier runs in the operator's stack. The keys are registered to the operator's backend. A YinkoShield outage does not interrupt verification; YinkoShield is not in the verification path.
Section bodies under NDA are bounded. Production characteristics (§9) and the agentic-payments extension (Annex A) are the parts not in this site. Their shape is published; their content is shared with regulators and qualifying partners.
The spec is shared with regulators and qualifying partners.
Reach out with your context — scheme, processor, tier-1 bank, regulator, or scheme-architect role. We respond within two business days. There is no sales pitch; there is also no sandbox link, because what is gated is the body of the spec, not a service.
Request access to YEI-001