Evidence Token format — structural shape and the two profiles

1. Wire shape

Three base64url-encoded parts joined by dots:

base64url(header) "." base64url(payload) "." base64url(signature)

The header is a JOSE Header per RFC 7515 [1] §4 naming the algorithm and the key reference. The payload is a JSON object whose contents depend on the profile (Section 3). The signature is computed over the encoded header and encoded payload — the JWS Signing Input is the on-the-wire bytes base64url(header) "." base64url(payload) per RFC 7515 §5.1; verifiers MUST verify against those bytes and MUST NOT decode and re-serialise the payload before verification.

The shape is JWS-compact serialisation per RFC 7515 [1]. Any JOSE-aware tool decodes the structure, even before any EEI-specific knowledge enters the picture. That is deliberate: operator integration tooling, regulator audit tooling, and generic JWS libraries all see the wire shape correctly.

2. Algorithm and signing

ES256 — ECDSA on the NIST P-256 curve with SHA-256, listed as Recommended+ in the JWS algorithm registry [2, §3.1]. (The JWS MUST-implement asymmetric algorithm per RFC 7518 §3.1 is RS256; we selected ES256 for compactness and for hardware support across Android Keystore, Apple Secure Enclave, and PCI PTS-listed terminal cryptoprocessors.) The signer’s nonce-generation policy depends on the platform’s secure-element implementation: where the platform exposes RFC 6979 [3] deterministic ECDSA, the reference signer uses it; where the hardware-backed signer uses CSPRNG-sourced k (the common case for Android Keystore and Apple Secure Enclave), the signature remains valid and verifiable, with CSPRNG quality covered by the platform’s own attestation chain. The detailed signing contract lives in the normative spec body.

The device’s private key is non-exportable from the platform key store. The operator’s verifier needs only the device’s public key (registered once at bootstrap) and the payload. See self-signing-devices and local-key-custody for the custody story.

3. Two profiles

Two payload profiles cover the operational range. The wire format is the same; what changes is the field set the payload carries.

Minimal profile

The chain-only profile. Carries the fields a verifier needs to check signature validity and chain coherence — the structural checks any verifier runs first. Used by privacy-strict regimes and by submission paths where the operator wants a small wire envelope.

The categories the Minimal payload includes:

• Chain header — the fields the verifier checks for ledger continuity (predecessor link, sequence position, boot epoch).
• Transaction context (tctx) — the operator-supplied join key the host application set when initialising the runtime. Integrator note: tctx is operator-defined and travels in the public side of the wire format; it MUST NOT carry PII (PAN, account number, name, email, phone) — use an opaque identifier the operator can resolve back to a transaction internally.
• Signal class summary — a single category marker indicating what kind of observation the record represents.

A Minimal-profile token carries no PII, no credential material, no operator telemetry, no vendor identifiers. Field-level schema (names, types, constraints) is in the YEI-001 spec.

Standard profile

Standard carries everything Minimal does plus the structured signal payload — the categories of observation an operator reads to build risk decisions, fraud features, AML inputs, and dispute records.

The categories the Standard payload adds:

• Device-state observations — verified-boot posture, security patch level, attestation reference.
• Runtime-environment observations — root, debugger, hook framework, emulator presence.
• Code-integrity observations — page-hash invariants and runtime-patching indicators. The applicable observation set is platform-asymmetric: on Android, dex-and-native-section hashing detects ART method-table rewrites and .text patching; on iOS, most of this surface is covered by code-signing enforcement and the substrate’s contribution narrows to the small set of observations that survive that layer.
• Binding observations — registered-device match, install-id continuity.
• Surface-state observations — overlay activity, accessibility service registration during the host-app surface.

Each category is a structured object whose internal schema — field names, value enums, validation rules — is defined by YEI-001 §4. The public surface is the category set; the field-level definitions are in the normative spec.

4. What the schema is for

The full Evidence Token JSON Schema is part of the YEI-001 specification body. It serves three audiences:

• Integrators building host applications use it as the authoritative wire-shape reference for their TRP integration.
• Operators deploying a verifier use it as the parser contract.
• Regulators auditing a deployment use it as the abstract reference against which they replay corpora.

The detailed field schema, validation rules, and verifier failure-constant enum are maintained in the YEI-001 normative specification separately from this explanatory article. This article is non-normative: it describes the structural shape and the two profiles at the level an architect or auditor can pre-qualify against. The normative artefact — field schema, conformance harness, test corpus — will be publicly linked from this Knowledge Center once versioning and public documentation are finalised.

To request the YEI-001 specification, contact us at /contact?subject=spec-access.

5. What this article is

A pre-qualifier. A buyer-side architect reading this should be able to confirm that EEI uses a recognised cryptographic envelope (JWS-compact / ES256), that the privacy posture is profile-controlled (Minimal vs Standard), and that there is a defined boundary between what the wire format publishes and what sits in the operator’s deployment. Specifics — the field schema, the validation rules, the test corpus — are in the normative specification.

6. Cross-references

• Sibling articles: verification-pseudocode, cross-language-test-vectors, regulator-readable-format
• Architecture: /architecture/evidence-token, /architecture/sovereign-verification
• Theme 5: append-only-ledger-structure, forward-chaining
• Specification: /specification

7. External references

[1] IETF. RFC 7515 — JSON Web Signature. datatracker.ietf.org/doc/html/rfc7515. Cited 2026-04-15.

[2] IETF. RFC 7518 — JSON Web Algorithms. datatracker.ietf.org/doc/html/rfc7518. Cited 2026-04-15.

[3] IETF. RFC 6979 — Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). datatracker.ietf.org/doc/html/rfc6979. Cited 2026-04-15.