# Publisher trust, keys, provenance and revocation

**Normative.** Protocol version `wisp/0`. Canonical location:
`https://wisp.intelgic.ai/protocol/v0/PUBLISHER-TRUST.md`

This document defines how a receiving AI establishes who published one exact
Wisp release. It does not decide whether the Wisp is useful, correct or safe.
Those are separate facts.

## 1. The split that must never collapse

- The **private key** signs canonical `WISP.json` bytes. It never appears on
  this website, in a Wisp, in source control, in telemetry or in a creation
  receipt. Production keys belong in a hardened signer controlled by the
  publisher.
- The **public key** verifies signatures. It is safe to publish and is served
  from the publisher directory at
  `/protocol/v0/publishers/<publisher-id>.json`.
- The **key ID** is
  `sha256:<first 32 lowercase hex characters of SHA-256(public-key-bytes)>`.
  It selects a public key; it is not the public key and is not an identity.
- The **Wisp identity** remains SHA-256 of canonical `WISP.json`. It is not a
  key fingerprint and not the ZIP digest.

## 2. How an AI establishes a publisher

Before it begins the offline inspection of a received Wisp, an AI MAY obtain
the current protocol release and publisher trust record from
`wisp.intelgic.ai`. This is protocol acquisition, not Wisp execution.

It then snapshots the trust record, makes no further network requests during
inspection or unfolding, and:

1. verifies the Wisp container and canonical manifest;
2. reads the signature file only;
3. obtains the claimed `publisher_id` and `key_id`;
4. finds that key in the independently obtained publisher record;
5. checks the publisher and key status, validity window and usage;
6. checks the publisher's revocation record;
7. verifies the Ed25519 signature over the canonical manifest bytes.

Only if every step succeeds is the signature state `signed-trusted` and
`publisher_established: true`. A public key bundled inside the Wisp is never an
independent anchor. A key fetched after payload instructions asked for it is
also not an independent anchor.

If the site is unavailable, a previously cached publisher record may be used
if its digest and age are disclosed. Otherwise the honest state is
`signed-unverified-publisher`, not a best guess.

The public reference kit performs this check without network access after the
AI has saved the two directory documents:

```text
python3 -B wisp-kit-v0/wisp.py verify received.wisp \
  --publisher-record publisher.json \
  --revocations revocations.json
```

The `--allow-test-publisher` flag exists only to exercise the public test
fixture. It MUST NOT be used to make a production trust decision.

## 3. What the directory establishes

A publisher record states the basis on which the directory associated a
publisher ID with an entity: Intelgic control, domain control, manual review,
test-only or unverified. The receiving AI MUST repeat that basis. “Listed” is
not the same claim as “legally identified,” and neither means “endorsed.”

The directory establishes at most:

- this exact manifest was signed by the private key corresponding to this
  independently obtained public key;
- the directory associated that key with this publisher ID under the stated
  identity basis;
- neither the key nor the release appeared in the revocation snapshot used.

It does **not** establish correctness, safety, competence, licensing,
non-maliciousness, fitness for a recipient's environment or permission to
perform an external effect.

## 4. Rotation and revocation

Keys have `active`, `retired`, `revoked` or `test-only` status and optional
validity bounds. Rotation adds a new key; it never rewrites an old Wisp.

Revocation is append-only by subject:

- a **key revocation** means no release verified only by that key may be
  treated as publisher-established after the revocation time;
- a **release revocation** names one Wisp manifest digest and leaves every
  other release unchanged.

A revoked artifact remains byte-identifiable. Revocation changes whether it
should be trusted or used; it does not pretend the artifact never existed.

## 5. Private-key operating rule

The public protocol repository intentionally contains no production private
key and no command that creates one silently. The first production publisher
requires a founder-controlled ceremony that records:

- signer technology and custody;
- backup and recovery;
- who may request a signature and who approves it;
- rotation and emergency revocation;
- the initial public key and fingerprint;
- a signed test vector checked by an independent verifier.

Until that ceremony occurs, production publisher identity is not established.
Test keys must be labelled `test-only` at every surface.

## 6. Trust bootstrap and directory authenticity

For v0, TLS control of `wisp.intelgic.ai` is the bootstrap trust source for
the directory snapshot. This is an explicit limitation, not a cryptographic
claim: a key and a self-signature downloaded from the same compromised origin
cannot repair that origin.

Before production, the directory release MUST also be signed by an offline
Intelgic trust-root key and its public fingerprint pinned through at least two
independently controlled channels. Directory releases SHOULD be submitted to
an append-only transparency log. The website remains the single discovery
entry point; the independent pins make a silent rewrite detectable.