PIC — Causal Authority Transition
The core PIC protocol. An executor E_i holding PCA_i wants to delegate restricted authority to the next executor E_{i+1}. It cannot simply forward PCA_i — PCA is bound to E_i and non-transferable. Instead, E_i requests a freshness challenge (PCC) from the Trust Plane (CAT), constructs a Proof of Continuity (PoC) demonstrating both authority over the predecessor PCA and possession of an attested executor identity, and the CAT mints a new PCA_{i+1} that strictly restricts ops (ops_{i+1} ⊆ ops_i) and is bound to E_{i+1}. p_0 is preserved verbatim. This single mechanism repeats at every hop in a PIC transaction, building the causal chain. References pic-spec.md §4.3 (CAT verification), §5.4 (request binding).
E_i is about to delegate to E_{i+1}. Before signing a PoC, it asks the CAT for a fresh challenge (PCC). The challenge prevents replay: a PoC bound to PCC_{i+1} cannot be reused at any other hop or against any other CAT. E_i declares (informationally) the predecessor hop number and the intended successor executor — these will be re-verified inside the PoC itself.
• The challenge is the freshness mechanism. Without it, a captured PoC could be replayed by an adversary who later compromised E_i's key.
• PCC issuance is cheap (random nonce + bookkeeping). It is the validation work in step 3 that is load-bearing.
• Some embedded-CAT deployments skip the round-trip and use a deterministic challenge derived from a shared monotonic counter. The security property (one-time-use) must still hold.
Step 1: GET /pcc (request challenge)
cat.example.com
application/pcc+json
5
spiffe://example.com/svc/order-processor