Continuity Proof Protocol
The Continuity Protocol Core — how continuity assertions are represented, exchanged, and verified.
Normative Definition
A Continuity Receipt is a cryptographically verifiable statement that an observer collected sufficient evidence supporting the continuity of a subject over a bounded interval of time.
Protocol Overview
A Continuity Protocol does not standardize how continuity is measured — it standardizes how continuity assertions are represented, exchanged, and verified. This specification is implementation-independent: it does not reference specific sensors, algorithms, or evidence engines. Those are defined in subordinate specifications (RFC-0001, RFC-0002) and engine-specific documents (EE-001, EE-002, EE-003).
The receipt does not claim “this is Alice.” It claims only that the subject at time t₁ is the same subject as at time t₀ — within the confidence bounds of the observing evidence engines. Identity binding is a separate concern, outside the protocol. A system can verify continuity without knowing — or storing — the subject's identity.
Protocol Flow
The Continuity Receipt
Every field in the schema, every rule in the trust model, and every composability constraint exists to make the normative definition machine-verifiable. A receipt is a self-contained object carrying assertions about observation, continuity, and confidence — with a cryptographic signature over the canonical serialization of those fields.
- ▸Assertions: observation occurred, continuity maintained, confidence bounds — internally consistent (V₃).
- ▸Temporal model: a bounded interval [start, end] with signedAt ≥ end (V₄).
- ▸Evidence references: payloadDigest = SHA-256(payload) per evidence item (V₅).
- ▸Composability: receipts link into a chain via previousReceiptHash (V₇).
Cryptographic Integrity
Receipts are serialized in canonical JSON (RFC 8259). The signing payload covers all receipt fields except signature itself, serialized in lexicographic key order, then hashed with SHA-256, then signed with the issuer's private key. The RECOMMENDED signature algorithm is Ed25519.
Since v1.0-RC1 the private key is a non-extractable WebCrypto CryptoKey stored in IndexedDB (never readable from JavaScript), and interval.coverageMs is part of the signing payload — preventing receipt tampering without invalidating the signature.
canonical fields (lexicographic key order) → SHA-256 → sign with Ed25519 private key → signature field (excluded from payload)
Verification Contract
A conforming verifier validates a receipt against seven checks, producing either VALID or INVALID with a failure code. Passing these checks means the receipt is authentic, internally consistent, temporally sound, and its evidence references are intact — it does not, by itself, attest to the meaning of the evidence or the trustworthiness of the issuer.
| Step | Check | Failure |
|---|---|---|
| V₁ | Schema validity. The receipt MUST conform to the schema defined in §6.1. All REQUIRED fields must be present. Field types must match. interval.coverageMs MUST equal end − start. | INVALID_SCHEMA |
| V₂ | Signature validity. The cryptographic signature MUST verify against the issuer's public key. The signature covers all receipt fields except signature itself, serialized in lexicographic key order (§6.4). | INVALID_SIGNATURE |
| V₃ | Assertion consistency. The three assertions (§1.1) MUST be internally consistent: if continuityMaintained.value is true, then observationOccurred.value MUST also be true. | INCONSISTENT_ASSERTIONS |
| V₄ | Temporal consistency. interval.start MUST be strictly before interval.end. signature.signedAt MUST be ≥ interval.end. expiresAt, if present, MUST be after signature.signedAt. | TEMPORAL_INCONSISTENCY |
| V₅ | Evidence reference integrity. For each evidence[i], payloadDigest MUST equal SHA-256(payload). The verifier does not need to inspect payload itself. | EVIDENCE_TAMPERED |
| V₆ | Freshness. If expiresAt is present, the current time MUST be before expiresAt. Expired receipts remain verifiable (V₁–V₅) but SHOULD NOT be accepted for live authorization. | EXPIRED |
| V₇ | Predecessor reference. If previousReceiptHash is non-null, the verifier MAY traverse the chain to verify longitudinal continuity (§5.1). | CHAIN_BROKEN |
What verification does NOT check
- ▸Evidence content validity. V₅ checks that payloadDigest matches payload, but does not check whether the evidence means what the issuer claims it means.
- ▸Issuer trustworthiness. The contract verifies that the issuer signed the receipt (V₂). It does not verify whether the issuer should be trusted.
- ▸Subject identity. The contract verifies the subject reference is stable within a chain (§5.1). It does not map the subject to a real-world identity.
- ▸Revocation status. V₁–V₇ verify the receipt itself. Revocation checking (§4.4) consults an external revocation list.
V₁–V₇ define the abstraction boundary between the protocol and its implementations: a verifier that passes V₁–V₅ is conforming — it can process any receipt, from any evidence engine, without knowing how the engine works.
Protocol Specification
Authoritative specification (unchanged canonical source): Continuity Protocol Core — /research/notes/008. Release notes: RELEASE-v1.0-RC1 (external GitHub).
Research Evidence
The following are research artifacts — empirical and experimental evidence that informs and examines the protocol. They are labeled as research evidence, not protocol guarantees.
Limitations
- ▸Dev-mode CSP temporarily allows unsafe-inline for debugging (disabled in production).
- ▸The published npm package @thecontinuitylab/myshape@0.3.0 predates the Batch-2D hardening; the registry version does not yet carry the non-extractable key regime.
- ▸Historical receipts signed with the old hex-key format cannot be verified under the new non-extractable key regime.
- ▸CPS-0001 verifies receipt integrity and continuity assertions — it does not prove a subject is a specific human, guarantee identity, or attest to issuer trustworthiness.