PIC — Cross-Domain Federation
A PIC transaction crosses an organizational trust boundary. Domain A (e.g., Partner) holds a PCA whose chain of trust ends at CAT_A's keys, which Domain B (e.g., Enterprise) does not natively trust. The Ingress Bridge at the boundary validates the incoming PCA against an inter-domain trust agreement, applies a domain-B policy that further restricts ops (a typical 'partners get read-only' rule), and re-anchors the transaction by minting PCA_int_0 against Domain B's CAT_B. Three invariants MUST hold: origin preservation (p_0 unchanged), monotonicity (ops_int ⊆ ops_external), and no expansion (the bridge cannot grant authority not justified by the incoming PCA). References pic-spec.md §6.5.2 (Federation Bridges).
Domain A's egress executor E_A sends its request to Domain B's Ingress Bridge, attaching PCA_A_n. The PCA shows p_0=alice@partner-a.com, ops=(read:orders/*, write:orders/*), and signing CAT is CAT_A (kid=cat-a-kid-01). Domain B has no native trust relationship with CAT_A — the Ingress Bridge will validate and re-anchor before forwarding internally.
• The Ingress Bridge is THE policy enforcement point for incoming partner traffic. Nothing passes into Domain B until re-anchored.
• E_A also includes X-PIC-Request-Sig — the body signed by E_A's key. The bridge verifies this to confirm the sender matches PCA_A_n.executor.binding before doing any policy work.
• If the Ingress Bridge is unavailable, the partner cannot enter Domain B at all. This is a deliberate choke point — the natural place to apply rate limiting, threat detection, and DLP.
Step 1: POST /v1/orders + PCA_A_n
application/json
eyJhbGciOiJFZERTQSIs...PCA_A_CAT_A_SIG
EA_BODY_SIG
ingress.enterprise.example.com
{
"order_id": "ord-998877",
"operation": "fetch_status"
}{"alg":"EdDSA","kid":"cat-a-kid-01","typ"?:"pca+cose"}{"hop":3,"p_0":"alice@partner-a.com","ops":["read:orders/*","write:orders/*"],"executor":{"binding":"spiffe://partner-a.com/svc/egress"},"provenance":{"cat":},"constraints":{"temporal":}}