Developers

Two verifiers, written separately, check the same bundle offline.

JSON Schemas define the canonical objects. The verifiers, one in Python and one in TypeScript, check a bundle against its registry entry and the trust registry with no network access. Both run over a shared conformance corpus and are compared on structure, integrity and the schema contract.

See the reading orderRead the protocol

Rules

What every implementation must get right.

  • A registry entry carries no evidence content. Hashes and identifiers are its only link to the bundle.

  • A verification report lists the levels it checked. A report that stops at L2 has not failed L3; that check was not requested.

  • Without a pinned trust root, a verifier reports REVIEW at best, never PASS.

Repositories

One repository per component.

Each carries a release label; the implementation status page lists them. None is on a package registry yet, and there is no hosted API yet.

Protocol

The specification: the object model, the verification levels and the rules for what may appear in a public entry.

Schemas

The JSON Schemas, packaged with the reason-code catalog, canonicalization helpers and generated TypeScript declarations.

Python verifier

The Python offline verifier: it reads a bundle and reports what it could and could not confirm, with no network.

API contract

An OpenAPI draft of the endpoints a hosted service would expose.

Conformance corpus

The adversarial vectors and bundle cases both verifiers run against, and the gate that compares their reports.

TypeScript verifier

The second offline verifier, written separately in TypeScript and compared with the Python verifier by the conformance gate.

Public registry

The registry that would publish entries in the format the specification defines.

Before integrating

An integration would rest on closed schemas and offline checks.

Contract. Each object is defined field by field. The schemas and the specification define the bundle, the receipt, the summaries, the registry entry and the trust registry. The schemas fix fields and types; the rule that ties a status to its reason codes is in the specification.
Verification. Offline verification stops at issuer authorization (L3). Before it, the verifiers check bundle structure (L0), file and manifest integrity (L1) and the link to the registry entry (L2). Transparency-log inclusion (L4), anchor finality (L5) and the issuer's legal identity are not checked.

Engineering

Share the first workflow you would integrate.

Tell us which policy it applies and what evidence it needs, and name any optional registry-entry fields it would use.

Bring us one figure