Sovereign verification

What sovereign verification means

Verification of an Evidence Token requires three things: the token itself, the registered public key for the device that produced it, and a verifier implementation. None of those three things has to involve YinkoShield. The operator stores the public keys. The operator runs the verifier. The operator applies the policy.

This is not a deployment option. It is an architectural property. There is no fallback path where verification quietly calls a YinkoShield endpoint when the operator’s verifier is unavailable. There is no licence check at runtime. There is no telemetry the operator did not ask for.

outcomes

What this lets you do today that you couldn't before

• Verify in the auth path without depending on a vendor service

  No remote call to YinkoShield, no licence check, no runtime dependency. A vendor outage does not break your payment flow.

• Pass regulatory audits without YinkoShield in scope

  Regulators verify evidence with the operator's own infrastructure. Our presence in the audit narrative is structural, not operational.

• Scale verification capacity inside your own infrastructure

  Throughput is a function of your CPU, not a third-party's quota. Verifier performance is yours to tune.

• Substitute verifier implementations without breaking the substrate

  The spec is the contract. The operator is free to fork the reference verifier, harden it, or run it on a different stack — the protocol is unchanged.

• Diagnose rejections specifically

  Each failure has a structured reject reason. Disputes get answered, fraud alerts get categorised, integrity failures get attributed — none of it is 'verification failed.'

The verification pipeline

The reference verifier implements an eight-step pipeline. Steps fail closed — a failure at any step rejects without proceeding. Every reject reason is diagnosable, not anonymous.

• ·1 Parse JWS — split the compact token on . into three segments. 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. Attempt at most one re-fetch over a mutually-authenticated channel if unknown. 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).
• ·6 Replay check — reject if (did, tctx, event_name, seq) is already present in the dedup store. The 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 resolution — 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.

Reference verifiers

• Python — ≥3.9, cryptography, 96 tests
• JavaScript — Node ≥18, zero dependencies, 87 tests
• Go — ≥1.21, zero dependencies, full package
• Java — ≥17, zero dependencies, 53 tests

Each verifier is an independent implementation of the same spec. Cross-verifier conformance is part of YEI-001’s CONFORMANCE.md checklist — the same token verifies the same way in every language, or one of them is broken.

properties

What you get when the verifier runs in your stack

• ·01 No vendor-in-the-path

  Verification is the operator with their own copy of the public key. We are not consulted.

• ·02 Reference verifiers in four languages

  Python, JavaScript, Go, Java. Each is an independent implementation; cross-conformance is part of CONFORMANCE.md.

• ·03 Diagnosable rejection reasons

  Each step of the pipeline emits a specific failure code — never a generic 'invalid token.'

• ·04 PKI-pattern operation

  Familiar to any SecOps team. The mental model is signature verification against a stored public key; not bespoke protocol.

• ·05 Zero-telemetry

  The verifier emits no telemetry the operator did not ask for. No usage counter, no licence beacon, no anonymous-stats stream.

• ·06 Fork-tolerant

  The spec, conformance suite, and reference implementations are sufficient for an operator to run their own verifier indefinitely without coordinating with us.

• ·07 Composable with policy

  The verifier produces a structured verdict; the operator's policy engine consumes it. Trust-basis weighting, freshness window, and reject-reason routing are all operator-defined.

Where to read more

The verification spec lives in YEI-001 §6 and CONFORMANCE.md, shared with regulators and qualifying partners under NDA. The reference verifiers ship with the spec.

Request the YEI-001 specification →