# Universal Document Witness Protocol 1.0

Status: public interoperability profile. Witnessing is optional additional transparency evidence. Core UDS integrity and applicable signatures remain independently verifiable offline without this protocol, a network, UniversalDocument.org, consensus, or blockchain.

## Privacy boundary

Witness inputs contain only privacy-safe trust metadata: deterministic leaf hashes, checkpoint ID/version, tree size, Merkle root, log key identifier, issue time, and signatures. Never send document contents, filenames, titles, PHI, legal-matter details, or document-conversation questions.

## Checkpoint observation

1. Obtain a `UD-TRANSPARENCY-CHECKPOINT-1.0` checkpoint.
2. Validate it against `checkpoint.schema.json` and reject unsupported versions.
3. Verify the log operator's Ed25519 signature where a public key is supplied.
4. Recompute the Merkle root from the privacy-safe leaf hashes supplied in the consistency material. For a later checkpoint, verify the earlier leaf sequence is an exact prefix and both roots recompute correctly.
5. Construct a `UD-WITNESS-STATEMENT-1.0` without `signature`, canonicalize it as compact JSON with lexicographically sorted NFC keys, and sign the UTF-8 bytes with the witness Ed25519 key.
6. Return or publish the completed statement.

## Witness statement

Required: witness ID, witness public key, protocol version, observed checkpoint ID, observed Merkle root, observed tree size, observation time, identity-assurance state, controlled flag, signature algorithm, and witness signature.

A valid signature proves only that the corresponding witness key signed the statement. Legal or organizational identity assurance is separate: `UNVERIFIED`, `SELF_DECLARED`, or `VERIFIED_ORGANIZATION`.

## Fork detection

Normal growth requires the prior leaf-hash sequence to be an exact prefix of the later sequence, its recomputed root to equal the earlier checkpoint root, and the later recomputed root to equal the later checkpoint root. A same-size checkpoint with another root, a non-prefix sequence, or a root mismatch is `INCONSISTENT_HISTORY`. This makes conflicting observed history detectable when sufficient evidence is retained; it does not make malicious behavior impossible.

## Multiple witnesses

Consumers report separately: inclusion verified; witness count 0/1/N; each witness signature valid/invalid; each witness identity trusted/unverified; consistency valid/inconsistent/not checked. Never collapse these into a generic “trusted” result.

Several statements may attach to one checkpoint. A statement count is not an
independence count: several keys controlled by one operator remain one operator.
For each checkpoint, report valid signatures, distinct independently verified
operators, and verified organizational identities as separate values.

Zero witnesses never blocks ordinary offline UDS verification. One witness means
one external observation exists. Multiple witnesses means multiple parties
observed compatible state. Use “quorum” only when an explicit relying-party
policy defines a threshold; protocol 1.0 defines no default quorum and does not
make witness consensus a condition of document validity.

Real plurality requires repeated, overlapping observations of several
checkpoints. A registration or one-time statement is insufficient. For a given
checkpoint, statements must align on checkpoint ID, tree size, protocol version,
and Merkle root. Retain every validly signed conflicting statement and classify
the condition as `WITNESS_OBSERVATION_CONFLICT` or
`POSSIBLE_SPLIT_VIEW_INCONSISTENT_CHECKPOINT`; never discard the outlier or claim
unanimity. Detectability does not make equivocation impossible.

## Independence

Registration does not establish independence. Genuine independent status requires a separately controlled operator, independently controlled infrastructure and private key, and no Universal Document operational access to that signing key. UD-controlled Workers, HIVE/Empire systems, test accounts, Codex-created witnesses, and renamed internal infrastructure are controlled references.

Operator independence and software diversity are separate. Different languages,
runtimes, or implementations strengthen ecosystem evidence but do not prove
independent control, and identical software does not invalidate an otherwise
valid signature. Availability is also separate: stale or offline status affects
current health, not the validity of retained historic signatures.