Verifier Interface v0.1

A minimal interoperable interface for cryptographic verification receipts.

Status

Draft v0.1

Goals

Verifier-independent receipt validation
Deterministic canonicalization
Detached cryptographic verification
Transport-independent interoperability
Composable verification infrastructure

Overview

The verifier interface defines a minimal interoperable model for issuing, transporting, and independently verifying cryptographic verification receipts.

The interface is intentionally small:

JSON-native
transport-independent
implementation-independent
deterministically canonicalized
cryptographically verifiable

The interface does not define:

authorization semantics
identity systems
governance policy
execution orchestration
economic settlement

Those layers may compose above or alongside verifier receipts.

Receipt Model

A verifier receipt is a detached cryptographic assertion describing the outcome of a verification event.

Receipts are:

Canonicalized using RFC 8785 JSON Canonicalization Scheme (JCS)
Hashed using SHA-256
Signed using Ed25519
Verifier-independent
Transport-independent

Canonical Signed Object

The canonical signed object consists of:

{
  "task_id_hash": "string",
  "verdict": "PASS | FAIL | INDETERMINATE",
  "confidence": 0.0,
  "reason_code": "string",
  "ts": "ISO8601 timestamp",
  "verifier_kid": "string"
}

Optional:

{
  "counterparty": "string"
}

The canonical signed object excludes:

receipt_id
signature fields
display metadata
UI state
transport wrappers

Receipt Identity Derivation

Receipt identity is derived from:

SHA-256(
  UTF8(
    JCS(canonical_signed_object)
  )
)

The resulting identifier format is:

sha256:<hex_digest>

Verification Process

Retrieve verifier receipt
Construct canonical signed object
Apply RFC8785 JCS canonicalization
Compute SHA-256 digest
Verify receipt_id matches derived digest
Retrieve verifier public key from JWKS or registry
Verify Ed25519 signature

Public Key Discovery

Verifier public keys SHOULD be exposed through:

/.well-known/jwks.json

Alternative verifier-specific registries MAY also be supported.

Example Receipt

{
  "receipt_id": "sha256:9e2d7b...",
  "task_id_hash": "sha256:2fbc91...",
  "verdict": "PASS",
  "confidence": 0.98,
  "reason_code": "MATCHED_SPEC",
  "ts": "2026-05-24T17:42:11Z",
  "verifier_kid": "sar-prod-ed25519-03",
  "counterparty": "example-agent",
  "sig": "base64url_signature"
}

Design Principles

Independent verification
Deterministic validation
Composable evidence layers
Minimal implementation surface
Verifier interoperability
Detached trust semantics

Continuity Composition

Verifier receipts MAY compose into higher-order continuity systems.

Such systems may:

link receipts temporally
evaluate governance continuity
detect execution-boundary failures
construct append-only operational history
compose multi-verifier evidence chains

This specification intentionally does not constrain those higher-order composition models.

Reference Implementation

Browser Verification

The reference explorer supports:

browser-side receipt verification
local SHA-256 receipt derivation
client-side Ed25519 verification
public JWKS retrieval
deep-linkable receipt inspection

Verification occurs independently in-browser without requiring trust in the explorer frontend.

License

This specification is provided under Apache 2.0.