# Open Print 1.0

Open Print 1.0 is the point where certificates stop being an experiment and
become a format other projects can depend on.

The current package version is `1.0.0`. The schemas, signed inputs, conformance
fixtures, and public API contract are frozen for downstream use. The package
passed adversarial review and every confirmed finding was remediated.

## The promises v1 makes

A conforming certificate has one stable ID and one sequence number within an
edition. Its claims are serialized predictably, hashed, and signed by the
issuer. Verification checks each of those facts separately and explains the
result.

Issuance is recorded as an event. Cancellation and replacement are later
events; they never rewrite the certificate or remove its original issuance
from the registry.

None of this turns a certificate into a token. The artwork can still be copied.
The certificate is simply a specific, signed statement made by a named issuer.

Every v1 certificate carries one canonical notice distinguishing that signed
statement from authorship, copyright, possession, legal ownership, transfer of
rights, and financial value. The schema rejects substituted wording.

## Certificate envelope

A v1 certificate has three parts:

- `claims` contains the human and edition data;
- `integrity` identifies the exact claims with SHA-256;
- `signature` binds those claims to a key published by the issuer.

The signature covers `claims`, `integrity`, and its own metadata: algorithm,
key ID, creation time, and scope. Only the signature value itself is excluded.
Changing any covered field causes verification to fail.

Collector claims contain only `displayName`, which may be a short public label
or `null`. Private local labels are prepared separately with
`prepareV1Collector` and never enter a signed certificate. The full policy is
in [PRIVACY_AND_CLAIMS.md](PRIVACY_AND_CLAIMS.md).

## Issuer records

An issuer record publishes the keys that may sign certificates. Each key has
its own ID, lifecycle status, and validity period. Active keys may create new
records. Retired keys keep signatures from their earlier validity window
verifiable. Revoked keys are never trusted.

Private keys do not belong in Open Print records or Git repositories. A gallery
or artist must keep signing keys in a protected local or institutional system.

## Registry events

The v1 registry understands three events:

- `issued` reserves a certificate ID and edition sequence;
- `cancelled` records why an issuance should no longer be treated as active;
- `superseded` points from an earlier certificate to its replacement.

Every event contains the digest of the event before it. Reordering, removing,
or editing an event breaks the chain. Each event also carries an issuer
signature, so an intact chain written by an unknown party is not treated as a
trusted registry.

## Registry checkpoints

A checkpoint signs the length and last event digest of one exact registry
prefix. Checkpoints point to their predecessor, forming a much smaller history
of observations alongside the full event registry.

Once a verifier has saved a trusted checkpoint, a shorter registry is a
rollback and another checkpoint with the same predecessor is a fork. A longer
registry remains acceptable when its next checkpoint extends the one already
observed.

## Compatibility

The `0.1` functions remain available during the v1 migration. They are not
v1-conforming because they do not carry issuer signatures.

`verifyCompatibleOpenPrintCertificate` recognizes both generations without
converting either one. A valid 0.1 record is labelled `integrity-only`; a v1
record is only labelled `issuer-signed` after its signature passes.

The `1.0.0` release keeps the complete v1 record shape stable. The
schemas reject unknown fields, so adding even an optional field would make a
new record unreadable to an older verifier. Adding, removing, or changing a
field—or changing canonicalization, digest scopes, or signature inputs—requires
a new record version and a new major package release.

The proposed v1 contract is recorded in
`compatibility/v1-baseline.json`. The compatibility check also watches the
signed fixtures, package exports, TypeScript declarations, command names, and
minimum Node.js version. The review rules are in
[COMPATIBILITY_POLICY.md](COMPATIBILITY_POLICY.md).

## Reading records you did not create

The exported validators apply the same JSON Schemas that are published with
the package. They reject unknown fields as well as missing or malformed ones.
Each problem includes a JSON Pointer such as `/claims/id`, which makes it
possible for a command-line tool or interface to point to the exact field.

Verification also starts with this validation step. A broken JSON document
therefore produces an ordinary invalid report instead of a property-access
error.

## Release status

The v1 contract is released and ready for downstream adoption. Future 1.x
changes must preserve the frozen record shape and compatibility baseline.

The complete set of release gates and their exit tests is maintained in
[PRODUCTION_ROADMAP.md](PRODUCTION_ROADMAP.md).