Skip to content
Signatif

For schemes

Build your domain on Signatif

Signatif is deliberately unfinished: the standard fixes the machinery — chains, scope, verification, transparency — while each scheme defines the domain. Here is what a scheme owns and the path from concept to claimed conformance.

What a scheme owns

A scheme is the organization — a sector consortium, a regulator, an industry body — that instantiates Signatif for its domain. The standard prescribes the requirements classes; the scheme decides every domain-specific value, and mutual recognition between schemes is itself standardized.

  • Registries — algorithms by class, format profiles, dimension tags, ceremony types
  • Scope dimensions and live conditions for the domain
  • The set of trust dimensions and their attestation sources
  • Classification policy and acceptance thresholds
  • Deployment manifest — tiers, thresholds, logs, migration phase
  • Topology and conformance claims (/conf classes)

The development path

From concept to a conforming deployment — each step lands in an artifact the standard already defines.

  1. 1authorities

    Map your hierarchy

    Map your real-world tiers onto root, delegated, and federated trust authorities down to end certificates. Choose a topology profile — hierarchical, federated, cross-recognized, or mesh — and set thresholds (for example 3-of-5 at the root).

  2. 2scope

    Define the authorization boundary

    Declare the scope dimensions that matter in your domain — sector, product class, geography, lot — and the live conditions evaluated at verification time. Scope narrows monotonically at every delegation; that invariant is enforced for you.

  3. 3registries

    Populate your registries

    A scheme owns its registries: algorithm identifiers (by class — classical, composite, post-quantum), format profiles, dimension tags, ceremony types. National and regulatory algorithm choices fit here, not in the standard.

  4. 4dimensions

    Choose your trust dimensions

    Pick which aspects of reality become cryptographic co-signatures. Eight dimensions are registered — authority, person, time, location, environment, authorization, identity, oracle — and your scheme registers its own through the dimension-tag registry: the set is open for extension, closed for modification. Each claimed dimension is a conformance class with tests.

  5. 5classification

    Publish your policies

    Define the classification policy that maps coverage reports to your labels, and the acceptance thresholds per decision context. Both are pure functions, published in the deployment manifest.

  6. 6manifest

    Declare and claim conformance

    Write the deployment manifest — tiers, thresholds, transparency logs, migration phase — claim your /conf classes, and validate against the abstract test suite.

Two schemes, sketched

Illustrative profiles in the style of the standard’s supply-chain annex — every value here is a scheme decision, not a standard requirement.

Fresh food traceability

illustrative profile

Hierarchy and thresholds

Food-safety authority consortium (root)3-of-5Defines sector scope: fresh food, hazard classes
National food authority2-of-3Narrows to geography and product category
Certification body1-of-1 / 2-of-3Accredits producers; narrows to certification type
Producer / packer key1-of-1End certificate; signs lot records
Lot record—The trusted artifact — measurement of the batch

Scope dimensions

sector: fresh food · hazard class: cold-chain, allergen · geography: origin and processing · lot identifier

Trust dimensions

Authority
delegation chain from the consortium root
Person
certified inspector co-signs the lot
Time
time authority anchors harvest and packing events
Location
origin and processing site attestations
Environment
cold-chain sensor co-signs transit temperatures

Electronic components

illustrative profile

Hierarchy and thresholds

Industry consortium (root)4-of-7Defines component sector scope and classes
Brand / ODM authority3-of-5Narrows to product family and process
Fab or line authority2-of-3Narrows to line and process step
Line batch key1-of-1End certificate; signs batch records
Batch record—The trusted artifact — the component lot

Scope dimensions

component family · process node / line · lot identifier · customer: OEM / distribution

Trust dimensions

Authority
chain from the consortium root
Person
line quality engineer co-signs
Time
time authority anchors production time
Environment
handling conditions attested for the lot

EU Digital Product Passport

The verifiable substrate under a DPP scheme

The EU Ecodesign for Sustainable Products Regulation establishes the Digital Product Passport: structured product data, a QR data carrier, and a decentralized registry, with product-group requirements arriving through delegated acts. A DPP scheme needs exactly what Signatif specifies — and a Signatif scheme can carry DPP records without waiting for the data model to stabilize.

DPP conceptSignatif mechanism
DPP record (structured product data)Trusted artifact payload — versioned, canonically serialized
QR data carrier on the productBarcode and passport delivery: self-contained encoding with error correction, or a compact reference for connected verifiers
Decentralized DPP registryTransparency logs with mirrors and gossip — M-of-K multi-log attestation, no single operator
Verifiable-credential representationsComposition annex: a VC becomes the payload; its single proof is replaced by dimensional co-signatures
Economic operators, notified bodies, authoritiesTrust authorities with scoped delegation — registration withdrawal propagates to their artifacts
Market surveillance and border checksOffline verification from the trust anchor bundle, with graded evidence for risk-based targeting
Product lifecycle updatesLiving artifacts accumulate attestations; successive versions carry explicit compatibility rules
Decade-plus product lifetimesAlgorithm agility with a published classical → composite → post-quantum migration path

Why it fits

  • No single registry operator: M-of-K multi-log transparency mirrors the decentralized-registry intent
  • Graded evidence lets market surveillance risk-target instead of accept-or-reject blindly
  • Offline verification at borders and inspection posts, from the anchor bundle alone
  • Revocation of an economic operator’s registration propagates to every bound passport artifact
  • A classical → composite → post-quantum migration path for decade-plus product lifetimes

Positioning

Signatif does not compete with DPP standardization: it is the trust layer a DPP scheme claims conformance to. A DPP deployment is a Signatif scheme — registries, scope, dimensions, policies — whose payload schema is the DPP data model for its product group, and whose carrier is the DPP QR code. As delegated acts and credential formats evolve, the substrate underneath stays conforming and testable.

The standard specifies this composition in informative Annex H, with the full concept mapping, composition patterns, and adoption paths.

Annex H in the standard

Source: Annexes C and D of the standard —CalConnect/cc-signatif