Framework

A trust graph over signed artifacts — not a hierarchy over identities

Traditional PKI binds a key to an identity. Signatif binds an artifact to the real-world conditions under which it was produced, and makes those bindings verifiable by anyone, offline, years later.

The problem it solves

Regulated industries issue conformity certificates, test results, calibration records, and compliance attestations whose trustworthiness carries legal, economic, and safety consequences. These artifacts must be verifiable by inspectors, customs authorities, and trading partners across organizational and jurisdictional boundaries — often years or decades after issuance.

A pharmaceutical batch release must demonstrate not just that a signing key was valid, but that the batch came from an authorized manufacturer, was inspected by a certified operator, was made under compliant conditions, and was released at a verifiable time. No existing infrastructure asserts all of that in one verifiable object.

PKI binds keys to identities — not artifacts to production conditions.
Blockchain systems give immutability without scope enforcement or revocation propagation.
Code-signing transparency covers provenance, not multi-dimensional convergence.

Authorities and the trust graph

Authority flows through signed delegations. The result is a directed acyclic trust graph — not a single mandated hierarchy — admitting hierarchical, federated, cross-recognized, and mesh topologies as first-class profiles.

Root trust authority: The top of a trust hierarchy. Its public key is a trust anchor, distributed in verifiers’ trust anchor bundles. Root keys are exercised by threshold quorum, never by a single holder.
Delegated trust authority: An authority that receives signing power from another authority through a signed delegation carrying a narrowed authorization scope. Delegation chains may be many levels deep.
Federated trust authority: A threshold group of independent organizations sharing one aggregate key, so that no single organization controls the authority. Cross-organizational recognition happens here, not only at the top.
End certificate: The credential that binds a concrete signing key to the narrowest scope in the chain — for example, a laboratory, an instrument model, or an individual instrument.
Trusted artifact: The signed object being verified: a certificate, report, calibration record, or attestation. It carries co-signatures and is the convergence point of the whole model.
The invariant: At every delegation link, the authorization scope narrows monotonically. Widening any scope dimension at any point is a hard verification failure — checkable from the signatures alone, with no external policy documents.

Illustration — legal metrology

root (3-of-5)→nmi→lab→model→instrument→measurement

Five delegation tiers from the threshold root through the national metrology institute and accredited laboratory down to the instrument model and the individual instrument — and the digital artifact being attested is the measurement itself. Scope narrows at every arrow: country, then laboratory accreditation, then instrument class, then the individual device.

Authorization scope

The scope of a trust authority is a first-class signed field: a multi-dimensional boundary of what the authority may sign, carried in every certificate and enforced at every link.

Scope — illustrative

{
  "dimensions": {
    "activity": ["calibration"],
    "instrument_class": ["class_m"],
    "geography": ["eu"]
  },
  "conditions": [
    "lab.temperature_c within [18, 26]",
    "operator.certificate not expired"
  ]
}

Conditions are predicates evaluated at verification time against the artifact’s content and context.

Authority: Who is entitled to issue — proven by the delegation chain from a root anchor.
Person: Which certified human operated or attested — a co-signature from a person-level key.
Time: When it was produced — anchored to an independent time source, not the signer’s clock.
Location: Where it was produced — backed by its own attestation tree.
Environment: Under what conditions — temperature, process state, or other scheme-defined context.
Extensible: The set of dimensions is registry-driven and open: eight are registered — authority, person, time, location, environment, authorization, identity, oracle — and schemes register more. Every dimension, built-in or added, is the same thing: a co-signature over the canonical payload, verified by the same pipeline. Registered dimensions are never redefined.

The trusted artifact

An artifact is signed over a canonical payload — a deterministic byte serialization — so that every verifier hashes exactly the same bytes. On that payload, independent signers leave co-signatures: one per trust dimension, each backed by its own attestation tree.

Trustworthiness emerges from convergence: multiple independent attestations of authority, person, time, location, and environment meeting on one verifiable record — not from the authority of a single signer.

Five attestations shown — the registry defines the set, and schemes may register further dimensions; each is the same co-signature mechanism.

the co-signature model

Artifacts can carry their delegation chain inline for network-free verification, or transparency-log references that a connected verifier resolves and caches on first encounter. The same artifact can be presented as a compact barcode passport with the key fingerprint and validity period for scanning environments.

Threshold signing applies at every level: a quorum of key holders exercises a root or delegated authority, eliminating single points of cryptographic compromise.

Anchors and offline verification

Every verification path terminates at a root anchor — a public key the verifier has chosen to trust, distributed as a trust anchor bundle. Verification requires no phone-home to any issuer and no proprietary component.

A verifier works offline using the anchor bundle, cached revocation lists within their validity or grace period, cached transparency tree heads with inclusion proofs, and embedded or hybrid chains. Offline verification produces the same classification label as online verification, except where freshness-dependent checks cannot be satisfied.

The standard itself specifies this as fourteen requirements classes across architecture, artifact format, algorithms, threshold signing, scope, revocation, transparency, verification, key lifecycle, delivery, ceremonies, deployment manifests, governance, and algorithm agility — each with a matching conformance class.

Source: Clauses 7–8 of the standard —CalConnect/cc-signatif