YinkoShield
Brief

Platform / Modules / otel bridge

Spans you already emit become signed evidence.

The SDK auto-attaches the Evidence Token to your OpenTelemetry spans as the execution_evidence attribute. The same crypto, the same eight-step verifier pipeline, the same trust-level resolution — riding the observability pipeline you already operate. No new transit channel, no new collector, no new failure mode.

how it ships

One SDK call. Every span carries evidence.

Enable the bridge once at SDK initialisation. The SDK attaches an Evidence Token to every span it sees on the active OpenTelemetry tracer — payment, auth, POS, threat — without changing the surface of your existing instrumentation. The token is JWS-compact, ES256, and signed by the device's hardware-bound key.

sdk · enable once
// Kotlin / Swift / equivalent
YinkoShield.init(
  ctx = appContext,
  modules = listOf(
    YksModule.OtelBridge,   // auto-attach to OTel spans
    // ... other modules
  ),
)

// elsewhere — your existing OTel code, unchanged:
val span = tracer.spanBuilder("payment.authorize").startSpan()
try {
  // ... your business logic
} finally {
  span.end()
}
// span carries execution_evidence attribute automatically
what the module gives you

  • instruments

    Auto-attaches to existing spans

    The SDK observes OpenTelemetry spans you already emit — payment.authorize, login.confirm, pos.txn.initiate — and attaches the Evidence Token as a span attribute. No new transit channel; no new instrumentation surface.

  • carries

    execution_evidence span attribute

    The signed JWS-compact token is set on the active span as the `execution_evidence` attribute. Verifiers downstream pick it up alongside the rest of the trace context — same crypto, same eight-step pipeline, same trust level resolution.

  • respects

    Sampling, redaction, and budget

    Honours your existing OTel sampler decisions; never re-emits if the span is dropped. Token is opaque to the OTel pipeline — no PII in evidence, nothing to redact at the collector.

  • interoperates

    OTel Collector → any backend

    Token surfaces in any OTel-compatible backend — Honeycomb, Grafana Tempo, AWS X-Ray, Datadog APM, Splunk Observability — as a regular span attribute. Verification runs in your stack, not in the observability vendor's.

on the wire

What the verifier sees on the other end.

Once the span reaches your OTel Collector and lands in your observability backend, the Evidence Token is just another span attribute — addressable, queryable, replayable. Verification runs against the operator's stored public keys; nothing in the trust path involves YinkoShield at runtime.

otel span · attribute view
{
  "name": "payment.authorize",
  "trace_id": "9f3b...c012",
  "span_id":  "4e6a...8d11",
  "attributes": {
    "merchant_id":         "m_4e8...",
    "amount":              "4200.00",
    "currency":            "ZAR",
    "execution_evidence":  "eyJhbGciOiJFUzI1NiIs...",
    "yks.profile":         "minimal",
    "yks.event_name":      "payment.initiated",
    "yks.tctx":            "tctx-3e9a1f2b..."
  }
}
operational outcome

  • zero

    additional integration layer beyond your existing OTel pipeline

  • single

    SDK call to wire up — `enableOtelBridge()` at SDK init

  • every

    OTel-instrumented payment, auth, and POS event carries signed evidence automatically

Your platform team already operates an observability pipeline. The OTel bridge makes that pipeline carry trust evidence as a side-effect of the spans it already moves.

turn it on

Existing customers — update the SDK. New deployments — show us your OTel pipeline.

Brief us on your observability stack Read the Evidence Token deep article