Architecture / architecture · 03
The Evidence Token: two profiles
JWS compact, ES256, inline with each request. Two profiles — Minimal (~200 bytes) for byte-budget channels, Standard (~300 bytes) for forensic richness. Same cryptographic semantics, same verifier code path, different envelope.
What travels with the transaction
The Evidence Token is the carrier. Every signed event from the TRP is encoded as a JWS-compact-encoded ES256 token and embedded with the transaction it relates to. The cryptographic properties are the same regardless of which channel carries it — HTTP header, OpenTelemetry span attribute, ISO 8583 DE 48, or direct SDK access.
outcomes
What this lets you do today that you couldn't before
-
Apply signed-evidence policy inside existing authorization paths
No new transit channel to onboard. Your auth flow stays the same; the token rides along the request you already make.
-
Deduplicate retries deterministically
The tctx correlation field identifies retries of the same execution context — duplicate-suppression stops being a heuristic and becomes a verifier output.
-
Verify the same record at multiple control points
Edge gateway, backend issuer, post-auth dispute platform — each consumes the same token without re-issuing it. No duplication of evidence generation.
-
Cross schemes, geographies, platforms with one token shape
No scheme-specific fields, no scheme-specific encoding required. The same token operates across networks the operator already runs on.
-
Adopt incrementally without coordination
A backend that does not yet consume evidence ignores it without impact. You can ship the token before every consumer is ready.
Two profiles
Minimal Profile · ~200 bytes
The default. Carries the minimal claims required to verify the
execution step, correlate retries deterministically via tctx,
and assess device state — without fetching the full Evidence
Record from the device ledger.
{
"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..." }
}The Minimal Profile fits ISO 8583 DE 48 with a BER-TLV envelope at ~216 bytes total — making it deployable across acquirer and scheme paths without scheme-message-format changes.
Standard Profile · ~300 bytes
Adds connectivity-state context inline — boot_id, net.connected,
net.type, scope — so the gateway can absorb retry logic,
offline-queued execution, and SIM continuity decisions in the same
request, with no additional roundtrip. The natural choice when the
consuming channel has byte budget — HTTP authorization, the
OpenTelemetry bridge, or in-process
consumption via the 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
}
}The verifier output for this token, against the operator’s stored public key, with the corresponding Evidence Record fetched and 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
What you get when you wire it up
-
·01 Inline carriage
The token travels with the request it relates to. There is no second call, no out-of-band fetch.
-
·02 Stable, additive schema
Backwards-compatible. New claims can be added; old verifiers ignore them gracefully.
-
·03 Profile parity
Minimal and Standard are read by the same verifier code path. The byte budget changes; the logic doesn't.
-
·04 Channel agnosticism
HTTP header, OpenTelemetry span attribute, ISO 8583 DE 48 / DE 124 / DE 125, or direct SDK consumption — choose one, choose all four.
-
·05 Identifiable structure
eid (event id), seq (per-device sequence), tctx (transaction context), kid (key id) — every claim is targetable in policy.
-
·06 Deterministic verification
ES256 over the JWS-compact-encoded structure. Same input, same verdict, every time.
Verification path
Both profiles verify identically. The verifier — Python, JavaScript, Go, or Java — checks ES256 signature, key binding, hash-chain continuity against the previous token’s hash, freshness window, and the trust-basis declaration. The same eight-step pipeline regardless of profile.
Where to read more
The full structure of the Evidence Token — claim definitions, signal model, cryptographic envelope — lives in YEI-001 §6.5, shared with regulators and qualifying partners under NDA.