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

1. Retrieve verifier receipt
2. Construct canonical signed object
3. Apply RFC8785 JCS canonicalization
4. Compute SHA-256 digest
5. Verify receipt_id matches derived digest
6. Retrieve verifier public key from JWKS or registry
7. 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

• defaultverifier.com
• Explorer
• SAR Key Registry
• Attestation Endpoint

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.