YinkoShield

glossary · reference

Every term, defined once.

Brand-canonical vocabulary for the Execution Evidence Infrastructure category. Same definitions across the website, the YEI-001 specification, partner briefings, and customer documentation. If a term appears here, it appears here only.

Category

Execution Evidence Infrastructure · EEI

deep article →
The category. The device-bound evidence layer for digital payments — signs what the runtime did at the moment of action, against an append-only ledger that resides on the device, verifiable with a public key alone.

Runtime coherence

deep article →
The property the substrate implements: the device's execution path is observable, ordered, and signed between credential use and network receipt. The missing partition layer of payment infrastructure.

Witness layer

Plain-language synonym used in customer briefings. EEI testifies; the operator decides. The substrate is the witness, the Evidence Token is the testimony, the ledger is the deposition.
Primitives

Trusted Runtime Primitive · TRP

deep article →
The foundation of the EEI substrate. An infrastructure module embedded in the operator's app user-land that wraps syscalls, libc, and framework calls; observes runtime coherence; signs the result with a hardware-bound key.

Local Evidence Ledger

deep article →
The device-resident append-only, hash-linked record of every signed event. Tampering at any link breaks the chain visibly. The ledger does not stream off-device.

Commander

deep article →
The operator-controlled forensic channel into the ledger. PGP-analogous: operator key signs encrypted commands; device key receives, executes the query, signs the response. No third party in the loop.

Zero Trust Bootstrap Protocol · ZTBP

deep article →
The key-generation protocol. At first init the device generates a keypair inside its TEE. The private key never leaves; the public key is registered to the operator backend over a channel that does not include YinkoShield.
Artefacts

Evidence Token

deep article →
The signed, hash-linked record of an execution event. JWS-compact, ES256, ~200 bytes (Minimal Profile) or ~300 bytes (Standard Profile). Travels inline with the transaction; verifiable with a public key alone.

Evidence Record

The fuller record stored in the device ledger that the Evidence Token's `sig_ref` points to. Retrieved via the Commander channel for forensic investigation; not required for inline verification.
Properties

Sovereign verification

deep article →
Verification of an Evidence Token requires three things: the token, the registered public key, and a verifier implementation. None of those involves YinkoShield. A YinkoShield outage does not interrupt verification.

Trust basis

Declared-not-inferred property of every Evidence Token. One of `hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, or `software_layer`. The operator weights policy against the declared basis.
Token fields

tctx

Transaction context. Correlates retries of the same execution context — duplicate-suppression stops being a heuristic and becomes a verifier output.

did

Device identifier. Pseudonymous (SHA-256 of the device public key); never PII.

kid

Key identifier. Resolves which operator-stored public key verifies this token.

boot_id

Boot-session identifier. Detects restart-interrupted flows and lifecycle discontinuities.

eid · seq

Event identifier and per-device sequence number. Together with `did, tctx, event_name` form the atomic dedup key for replay protection.

sig_ref

Reference to the corresponding Evidence Record in the device ledger — `ledger_seq` plus segment id, or a `yks-ledger://` URI plus content hash.
Signal classes

device.integrity

Boot-integrity state. Re-flashed device fails verification at first transaction.

runtime.environment

Execution environment. Emulator detected, debugger attached, instrumentation framework — declared in evidence.

code.integrity

Application code signature. Repackaged APK surfaces as `software_measured`.

binding.status

Whether the signing key is bound to hardware — TEE-backed vs. software-bound, declared.

network.identity

SIM and network identity continuity. SIM swap mid-transaction visible in retry.
Standards

JWS · ES256

RFC 7515 JWS Compact Serialization with ECDSA P-256 + SHA-256 signature. The Evidence Token envelope.

ISO 8583 DE 48

Card-rail private-use data element. Carries the Evidence Token via a `0xF0` BER-TLV envelope — chosen specifically because it does not conflict with Mastercard or Visa subelement ranges.

EMV / EMV 3DS

Adjacent and orthogonal to EEI. Scheme authentication outcomes (CAVV / 3DS results) link to EEI events only when an operator's program explicitly says so.

STRIDE

Threat-modelling methodology used in YEI-001's `THREAT_MODEL.md` for the in-scope-vs-residual-risk table.

POPIA §11

South African data-protection regime. Producer conformance for SA consumers requires the *strict* privacy profile — no raw `(device_id, tctx)` logging without a documented lawful processing basis.
Operating model

Integration profile

One of three: `iso8583-de48-minimal` (card rails, tight DE 48 budget), `mobile-wallet-retail` (richer Standard Profile when bandwidth allows), `agent-assisted-channel` (distinct events for customer vs agent).

Reference verifier

One of four independent implementations of YEI-001 §6 — Python, JavaScript, Go, Java. Cross-conformance is part of CONFORMANCE.md; the same token verifies the same way in every language, or one of them is broken.

Eight-step pipeline

deep article →
The verification contract: parse JWS · resolve key · verify signature · validate claims · enforce freshness · replay check · sequence regression · trust level. Each step fails closed; rejections are diagnosable, not anonymous.

Privacy profile

`strict` or `default`. `strict` is required for South African consumers under POPIA §11 — pseudonymous device identifiers, no quasi-identifier accumulation, no raw `(device_id, tctx)` logging.

For the full normative vocabulary, request the YEI-001 specification.

Currently shared with regulators and qualifying partners under NDA.

Request access to YEI-001