CPS-0002cps-hsa-0.1-draftPROTOCOL CORE: FROZEN AS PROTOTYPE DRAFT ARTIFACTTRUST FRAMEWORK: NOT FROZEN

CPS-0002 — Human Signal Assertion

An attestation layer built on the CPS-0001 Continuity Receipt. CPS-0002 defines how an attester-signed assertion can cryptographically bind to a receipt and be independently verified.

Status

Protocol CoreFROZEN AS PROTOTYPE DRAFT ARTIFACTfrozen as cps-hsa-0.1-draft; spec prose DRAFT / NOT FROZEN

Protocol typecps-hsa-0.1-draftassertion protocolType

Trust FrameworkNOT FROZEN / OUT OF SCOPEtrust policy, registry, revocation, aggregation remain outside the core

Freeze commitd06b907CPS-0002: freeze protocol core

Freeze tagcps-hsa-0.1-draftannotated tag

CPS-0002 Protocol Core is frozen as cps-hsa-0.1-draft. The Trust Framework remains outside the frozen core and is not yet frozen. Frozen here means the protocol-core semantics (payload, signature, verification, VALID meaning) are fixed; it does not mean the broader trust system is complete.

Relationship to CPS-0001

CPS-0001 establishes the Continuity Receipt — an engine-independent, signed statement that an observer collected sufficient evidence supporting the continuity of a subject over a bounded interval.

CPS-0002 defines a Human Signal Assertion on top of that receipt: an attester-signed statement that cryptographically references the receipt, the subject, the attester, the evidence payload digest, and the validity period. Any conforming verifier can check the assertion independently — without trusting the underlying evidence as true.

The Protocol Chain

CPS-0001

Defines the Continuity Receipt — a signed, engine-independent statement of continuity over a bounded interval.

Continuity Receipt

The receipt object that CPS-0002 assertions cryptographically reference by hash, id, and subject.

CPS-0002

An attester-signed assertion bound to that receipt, to a subject, to an evidence payload digest, and to a validity period.

Cryptographic Verification

A conforming verifier checks structure, Ed25519 signature, payload digest, receipt binding, and expiry.

VALID / INVALID

The cryptographic verdict. VALID means the assertion verifies; it does not grant trust.

Trust Policy

The deployment layer that maps a VALID assertion to a trust decision (which attesters, which keys, which policy).

TRUSTED / UNKNOWN / NOT TRUSTED

The policy outcome. A VALID assertion may still be UNKNOWN or NOT TRUSTED in a given deployment.

Application Decision

The relying application decides whether to accept the assertion for its specific purpose.

What VALID Means

A CPS-0002 assertion is VALID when a conforming verifier confirms it is:

▸Structurally conformant with the CPS-0002 assertion schema (unknown root properties are rejected)
▸Cryptographically valid — the Ed25519 signature verifies against the 12-field canonical payload
▸Internally consistent — the evidence payload digest recomputes to the signed value
▸Correctly bound to the referenced Continuity Receipt (receipt hash, receipt id, subject id)
▸Within its assertion validity period

What VALID Does Not Mean

VALID is a cryptographic verdict, not a trust verdict. It does NOT establish:

✕Attester authorization or trust
✕Evidence truth
✕Human presence
✕Biological humanity
✕Liveness
✕Single-use
✕Universal replay protection
✕Application acceptance

A Human Signal Assertion ≠ Proof of Human. Whether a VALID assertion is trusted, accepted, or acted upon is a trust policy and deployment decision made by the relying application.

Technical Artifacts

Source artifacts are published in the repository under continuity-protocol/.

ConceptProblem boundary, why CPS-0002 exists Verifier ContractNormative verification algorithm and VALID semantics Trust PolicyAttester / deployment / application boundaries Threat ModelSecurity boundary and residual risks Trust AuditWhat VALID does and does not establish Interoperability AuditCross-implementation findings Assertion SchemaJSON Schema (required fields, root closure)Reference VerifierReference implementation Independent Second VerifierIndependent implementation, interop proof Conformance Suite52 conformance tests Interoperability Suite39 cross-verifier tests Release Notes0.1-draft release documentation

← All Protocols

Status

Protocol CoreFROZEN AS PROTOTYPE DRAFT ARTIFACTfrozen as cps-hsa-0.1-draft; spec prose DRAFT / NOT FROZEN

Protocol typecps-hsa-0.1-draftassertion protocolType

Trust FrameworkNOT FROZEN / OUT OF SCOPEtrust policy, registry, revocation, aggregation remain outside the core

Freeze commitd06b907CPS-0002: freeze protocol core

Freeze tagcps-hsa-0.1-draftannotated tag

Relationship to CPS-0001

The Protocol Chain

CPS-0001

Defines the Continuity Receipt — a signed, engine-independent statement of continuity over a bounded interval.

Continuity Receipt

The receipt object that CPS-0002 assertions cryptographically reference by hash, id, and subject.

CPS-0002

An attester-signed assertion bound to that receipt, to a subject, to an evidence payload digest, and to a validity period.

Cryptographic Verification

A conforming verifier checks structure, Ed25519 signature, payload digest, receipt binding, and expiry.

VALID / INVALID

The cryptographic verdict. VALID means the assertion verifies; it does not grant trust.

Trust Policy

The deployment layer that maps a VALID assertion to a trust decision (which attesters, which keys, which policy).

TRUSTED / UNKNOWN / NOT TRUSTED

The policy outcome. A VALID assertion may still be UNKNOWN or NOT TRUSTED in a given deployment.

Application Decision

The relying application decides whether to accept the assertion for its specific purpose.

What VALID Means

A CPS-0002 assertion is VALID when a conforming verifier confirms it is:

▸Structurally conformant with the CPS-0002 assertion schema (unknown root properties are rejected)

▸Cryptographically valid — the Ed25519 signature verifies against the 12-field canonical payload

▸Internally consistent — the evidence payload digest recomputes to the signed value

▸Correctly bound to the referenced Continuity Receipt (receipt hash, receipt id, subject id)

▸Within its assertion validity period

What VALID Does Not Mean

VALID is a cryptographic verdict, not a trust verdict. It does NOT establish:

✕Attester authorization or trust

✕Evidence truth

✕Human presence

✕Biological humanity

✕Liveness

✕Single-use

✕Universal replay protection

✕Application acceptance

A Human Signal Assertion ≠ Proof of Human. Whether a VALID assertion is trusted, accepted, or acted upon is a trust policy and deployment decision made by the relying application.