N. Gallo Nitro Agility S.r.l. 15 July 2026 PIC Prover and Verifier pic-prover-verifier-02 Abstract This document is the *PIC Prover and Verifier Specification*, a subordinate specification of the PIC Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md). It defines the normative requirements for the two complementary components of Proof of Continuity handling: * *PIC Provers*: the components that construct Proofs of Continuity for an execution hop; * *PIC Verifiers*: the trusted components that validate Proofs of Continuity and enforce the invariants of the *Provenance Identity Continuity (PIC) Model* at verification time. At every hop, a node acts in both roles: it *verifies* the continuity state received from its predecessor and *proves* continuity to its successor by producing the next continuity advancement required by the selected profile. It specifies the per-hop *Proof of Relationship* and continuity- advancement requirements (Section 2), the ordered *Verifier checks* - including profile-conditional request/execution binding - that validate a hop before authority is exercised (Section 3), authority as an abstract *attenuation domain* with a Policy Decision Point boundary (Section 4), and profile-selected *continuity representations* (Section 5). This document does not redefine, extend, or alter the PIC Model or the normative semantics defined by the PIC Specification. In case of conflict, the *PIC Specification* is authoritative. Document Status *Project:* PIC Protocol *Project Website:* www.pic-protocol.org (https://www.pic-protocol.org/) *Document:* pic-prover-verifier-02 *Version:* 0.2 (Draft) *Document Status:* Public Draft *Intended Use:* Informational and Experimental *Published:* 2026-07-15 *Editor(s):* Nicola Gallo (Nitro Agility S.r.l.) *Steward:* Nitro Gallo Informational [Page 1] PIC Prover and Verifier July 2026 Agility S.r.l. *Source:* github.com/pic-protocol/pic-spec/draft/0.2/ pic-prover-verifier-spec.md (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-prover-verifier-spec.md) About This Document *Public Draft — Not a Standard* This document is an independently developed specification published as part of the PIC Protocol and maintained by Nitro Agility S.r.l. in its role as Specification Steward. It has not been adopted, endorsed, approved, or published by the IETF, IRTF, IAB, RFC Editor, ISO, IEC, W3C, CNCF, OpenID Foundation, or any other standards-development organization, unless a later version explicitly states otherwise. It is not an RFC, an Internet Standard, or an official work item of any working group or standards body. This document is published for public review, research, experimentation, implementation feedback, and possible future standardization work. It may be revised, replaced, or withdrawn at any time. Implementers use this draft at their own risk. Any implementation, interoperability statement, or conformance claim applies only to the exact document version identified above. Publication of this draft does not constitute certification, endorsement, security approval, interoperability assurance, regulatory approval, or standards-body recognition. Current project information and published specifications are available at https://www.pic-protocol.org/. Editors * *Nicola Gallo* (Nitro Agility S.r.l.) Lead Editor * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 9)._ Contributors * _Add your name via pull request (individual or organization) — listing is subject to editor approval (see Section 9)._ Gallo Informational [Page 2] PIC Prover and Verifier July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Security Guarantees of the Model . . . . . . . . . . . . 5 1.2. Delegating the Future . . . . . . . . . . . . . . . . . . 6 1.3. The N+1 Executor Problem (Canonical Execution Model) . . 7 1.4. Cross-Lineage Authority Composition . . . . . . . . . . . 7 1.5. The Execution Flow as Part of the Security Model . . . . 8 1.6. Attribute Attestations . . . . . . . . . . . . . . . . . 9 1.7. Requirements Notation . . . . . . . . . . . . . . . . . . 10 1.8. Origin Authority Context . . . . . . . . . . . . . . . . 11 2. Prover Requirements . . . . . . . . . . . . . . . . . . . . . 13 2.1. Prover Procedure . . . . . . . . . . . . . . . . . . . . 14 2.2. Predecessor Validation . . . . . . . . . . . . . . . . . 15 2.3. Proof of Relationship . . . . . . . . . . . . . . . . . . 15 2.4. Invariant Monotonicity . . . . . . . . . . . . . . . . . 17 2.5. Continuity Advancement Construction . . . . . . . . . . . 20 3. Verifier Requirements . . . . . . . . . . . . . . . . . . . . 21 3.1. Verifier Procedure . . . . . . . . . . . . . . . . . . . 22 3.2. Root Validation . . . . . . . . . . . . . . . . . . . . . 24 3.3. Advancement Validation . . . . . . . . . . . . . . . . . 25 4. Authority Domains and Attenuation Profiles . . . . . . . . . 26 4.1. Authority as an Abstract Domain . . . . . . . . . . . . . 26 4.2. Attenuation Profiles . . . . . . . . . . . . . . . . . . 27 4.3. Policy Decision Point (PDP) Integration . . . . . . . . . 27 5. Continuity Representations . . . . . . . . . . . . . . . . . 28 5.1. Current Profile 0.2 Representation . . . . . . . . . . . 29 5.2. Profile 0.2 Artifact Semantics . . . . . . . . . . . . . 30 5.2.1. PIC Token JWT . . . . . . . . . . . . . . . . . . . . 31 5.2.2. PIC PCA COSE . . . . . . . . . . . . . . . . . . . . 31 5.2.3. PIC Continuity COSE . . . . . . . . . . . . . . . . . 31 5.2.4. PIC Continuity Transition COSE . . . . . . . . . . . 32 5.3. Profile 0.2 OAuth Token Exchange Binding . . . . . . . . 33 5.4. Self-Contained Transition Graphs . . . . . . . . . . . . 35 5.5. Incremental, Checkpointed, or Referenced History . . . . 35 5.6. Succinct Proofs . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.1. Freshness, Replay, and Fan-out . . . . . . . . . . . . . 35 6.2. Origin Trust Boundary . . . . . . . . . . . . . . . . . . 37 6.3. Temporal Rules and Per-Hop Expiry . . . . . . . . . . . . 38 6.4. Canonicalization and Cryptographic Agility . . . . . . . 38 6.5. Formal Scope . . . . . . . . . . . . . . . . . . . . . . 39 6.6. Proof of Possession (Optional) . . . . . . . . . . . . . 39 6.7. Transport Separation and Confidentiality . . . . . . . . 39 6.8. Incremental Verification and Trusted Hops . . . . . . . . 40 7. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 40 8. Zero Trust . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43 Gallo Informational [Page 3] PIC Prover and Verifier July 2026 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43 11. Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 12.1. Normative References . . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 45 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction This section is non-normative. It describes the problem this specification addresses and is independent of any concrete implementation. Normative requirements are defined in Sections 2, 3, 4, and 6, together with the requirement explicitly marked normative in Section 5 (Section 1.7). Current authorization models lack a formal execution continuity model: they define who may hold authority, but not how authority remains valid across the steps of a distributed execution. This specification defines how the *Provenance Identity Continuity (PIC) Model* is implemented at each execution hop to close that gap. The model, including *Proof of Relationship (PoR)*, *Proof of Continuity (PoC)*, and the resulting safety guarantees, is formally defined in the companion paper [1] (Section 12) and formally verified with the Lean theorem prover [2] (Section 12). The paper treats PoR as an abstract, unforgeable primitive. This document specifies the two components that realize it: * The *PIC Prover* constructs the relationship evidence required by the selected profile to witness the PoR relation binding the current execution step to its causal predecessor, and uses the resulting valid advancement to construct the PoC handed to the next hop. A PoC is valid only if it satisfies the PIC invariants: causal linkage witnessed by PoR at every hop, and a non-expansive authority context. * The *PIC Verifier* validates both proofs at the receiving hop: the PoR, which establishes that the incoming step is a genuine continuation of its predecessor, and the PoC, which establishes that the invariants hold along the entire received lineage. If either proof is invalid, the hop is rejected before any authority is exercised. Gallo Informational [Page 4] PIC Prover and Verifier July 2026 PIC *does not require a central server*. Depending on deployment topology and selected profile, a chain can be validated _fully decentralized_ — each hop carrying everything the next needs to verify it — or with the help of a trusted component such as a snapshot server. Section 5 describes these representations; the PIC _invariants_ are the same in every case, but the concrete assurance and trust assumptions differ by profile (Sections 6.8, 7) — the profiles are not equivalent. This statement concerns the abstract PIC model and profile space. The current PIC Profile 0.2 uses centralized advancement and settlement by a trusted settlement authority. PIC-X is one conforming realization of that profile, not a required component of the abstract PIC model. PIC also draws a *clean line between the security model and transport*. The guarantees come from the signed continuity chain, not from how it travels: an implementation must not rely on the transport — a TLS session, a network perimeter, a message bus — to obtain them (the normative requirement is stated in Section 6.7). Transport is only transport. A compromised channel can read or drop messages but cannot forge a valid PCA; confidentiality and attack-surface concerns belong to transport and are addressed in Section 6.7. This separation is what lets the same model run unchanged over HTTP, over messaging systems such as Apache Kafka, or over any other carrier. 1.1. Security Guarantees of the Model An authority-propagation protocol guarantees the validity of authority states, not the physical behavior of executors. PIC guarantees that no actor can cause a conforming executor to accept or propagate an invalid authority state as valid PIC state: an operation is accepted only if it can be represented as a valid continuation of the authority carried by the request. Physical behavior is outside this guarantee, for PIC as for any security protocol. No authorization model can guarantee that an application is free of bugs or that an executor behaves correctly: an executor that receives authority to READ, ignores it, and physically performs DELETE fails as an implementation, locally. What the protocol guarantees is that such a fault remains local: executor n+1 cannot continue, as valid, an authority state that the model defines as invalid. The same applies to the cryptographic assumptions. Capability and token systems, such as OAuth, rest on the unforgeability of their credentials: if the underlying cryptography is broken, none of their properties survive. PIC rests on the same cryptographic assumptions, Gallo Informational [Page 5] PIC Prover and Verifier July 2026 and so does the Proof of Relationship: the relationship evidence is assumed unforgeable, and a break of the underlying cryptography is outside the model, as it is for every protocol in this space. This boundary is what distinguishes PIC. If authority from two independent lineages can be composed into a new state that remains valid under a model, that model relies on correct executor behavior to avoid the composition. Under PIC such a mixed state is invalid by construction: the damage of a buggy or compromised executor is confined to its local step and cannot propagate as valid authority at the next hop. 1.2. Delegating the Future Software that must support implementations that do not exist yet does not hard-code future components. It defines an interface. The interface specifies the contract, and any future implementation can participate, provided it proves that it satisfies the contract. PIC applies the same principle to distributed execution. A continuation does not name or preselect its successor. It defines the execution contract instead: * the authority that may continue; * the constraints that must remain non-expansive; * the execution characteristics the successor must satisfy; * the causal relationship with the previous execution state. When a successor materializes, it proves that it satisfies those conditions and may continue the execution. No identity needs to be known in advance, and nothing binds the contract to a single successor: a continuation may be taken up by zero, one, or many executors, possibly in parallel. The future being delegated ranges from no continuation at all to an unbounded number of them. Identity may still support authentication, audit, and accountability, but it is not the primitive that preserves authority across execution. The contract defines the continuation. The executor proves conformance. Continuity, not identity, delegates the future. Gallo Informational [Page 6] PIC Prover and Verifier July 2026 1.3. The N+1 Executor Problem (Canonical Execution Model) The N+1 Executor Problem is future delegation made concrete. This specification is explained and defined around this single canonical execution model. Execution is a chain of discrete steps performed by executors, such as services, workloads, functions, tools, or agents. Each executor receives a request, processes it, and may cause a further step: +----------------+ | +----------------+ | +----------------+ | EXECUTOR n-1 |------|----->| EXECUTOR n |------|----->| EXECUTOR n+1 | +----------------+ | +----------------+ | +----------------+ time x time x + y Each | marks a hop boundary: the point where the predecessor's Prover emits its proofs and the successor's Verifier validates them. Each boundary is an act of future delegation, and the linear chain is the minimal case: a step may delegate to several successors in parallel. The problem is the executor at position n+1. Executor n acts at time x. Executor n+1 acts at a later time x + y, and at time x it does not yet exist as a known party: it need not be known, selected, instantiated, or provisioned when executor n completes its step. Consequently, no security mechanism that requires pre-binding authority to a concrete successor (its identity, its key, or its channel) can be applied at time x: there is no holder yet to bind to. The problem does not require a long chain: it already holds for n = 0. The first hop, from the origin that expresses an intent to the first executor that serves it, crosses the same temporal gap, since that executor too may not exist or be known at the time the intent is expressed. A single-hop execution is the smallest instance of the N+1 Executor Problem. Multi-hop chains repeat it at every boundary, where its consequences become most visible. 1.4. Cross-Lineage Authority Composition An executor may serve more than one lineage at the same time. Each lineage carries its own authority context, attenuated along its own chain. A bug, or an adversarially influenced agent, can compose authority across those lineages: a privilege carried by one lineage is attached to the continuation of another. Gallo Informational [Page 7] PIC Prover and Verifier July 2026 LINEAGE A: { READ-ALL, BACKUP } ----> { READ-ALL } | | cross-lineage composition (bug) v LINEAGE B: { READ-FOO, SHARE-FILES } ----> { SHARE-FILES } ----> { READ-ALL, SHARE-FILES } EXECUTOR n+1 In a possession-based model the resulting state is valid. Every privilege presented at executor n+1 is genuinely possessed and correctly signed; nothing in the model distinguishes them by origin. The bug has created a valid security state, and READ-ALL combined with SHARE-FILES is now exercisable in a lineage that was never granted it. Under PIC the same state cannot be represented as valid. READ-ALL is absent from the origin context of lineage B, and no valid continuation can expand an authority context: the composed proof does not satisfy the lineage, and the Verifier at executor n+1 rejects it. The bug can still execute locally, as stated in Section 1.1, but the state it produces is invalid and stops at that hop. This is a _structural_ elimination of cross-lineage confused-deputy authority composition from the PIC state model, and it is what PIC shares with the object-capability approach: a capability removes the mismatch by construction at a single hop, by fusing designation and authority at invocation; PIC extends the same by-construction guarantee across the whole lineage, so the mismatch is not a state a valid chain can represent at any hop. It is ruled out by construction, not caught by runtime vigilance — and this is exactly the property the Lean formalization verifies [2] (Section 12). 1.5. The Execution Flow as Part of the Security Model The PIC Model resolves the N+1 Executor Problem by bringing the execution flow itself, including the not-yet-existing executor n+1, into the security model, rather than leaving the gap between x and x + y to application logic. What must hold across that gap is not the identity of the successor, but that its authority is a valid continuation of the context that caused it. The temporal gap is therefore not an application concern to be patched with perimeter assumptions or out-of-band coordination: it is the object the security model is built around, and authority crosses it only as verified continuity, never as possession by a pre-existing holder. Gallo Informational [Page 8] PIC Prover and Verifier July 2026 1.6. Attribute Attestations To describe the model, this specification uses one illustrative construct: the signed attribute attestation. It is a document, signed by an issuer, that binds a subject to a set of attributes for a validity period. The examples in this document follow a single running scenario: a backup service operating in the European region under compliance constraints, authorized for the operations READ-ALL and BACKUP. { "subject": "did:example:workloads:eu:backup-service", "attributes": { "role": "backup-service", "compliance": ["GDPR"], "accountableParty": "Example Corp", "serviceAgreements": [ "https://legal.example.com/agreements/dpa-2026-001" ], "environment": "production", "region": "eu-1", "availabilityZone": "eu-1a", "executionModel": "deterministic" }, "issuedAt": "2026-07-17T10:00:00Z", "expiresAt": "2026-08-17T10:00:00Z", "issuer": "did:example:org-authority" } The scenario includes a second executor: a summary service implemented as an AI agent. It produces summaries of documents, and its execution is not deterministic. Its attestation differs in role, accountable party, network placement, and execution model: Gallo Informational [Page 9] PIC Prover and Verifier July 2026 { "subject": "did:example:workloads:eu:summary-service", "attributes": { "role": "summary-service", "compliance": ["GDPR"], "accountableParty": "Acme AI Ltd", "serviceAgreements": [ "https://legal.acme.example/agreements/asa-2026-042" ], "environment": "production", "region": "eu-1", "availabilityZone": "eu-1b", "executionModel": "agentic" }, "issuedAt": "2026-07-17T10:00:00Z", "expiresAt": "2026-08-17T10:00:00Z", "issuer": "did:example:org-authority" } The identifiers in the examples use DIDs, but this is a _presentational_ choice, not a requirement. *PIC does not depend on any identifier scheme; what it needs are the signed attestations themselves.* A bare public/private key pair, with no identifier at all, is enough to sign and verify them. An identifier such as a DID only makes the examples easier to read and to cross-reference: it _helps_ the specification, it is *not necessary* for the model. For the same reason, this document deliberately does not use Verifiable Credentials, X.509 certificates, or similar formats. They would work, but understanding them is not required to understand PIC, and depending on them would tie the model to a particular identity technology. The specification uses a plain signed attestation on purpose — a _minimalist approach_ that keeps it accessible and free of unnecessary prerequisites. 1.7. Requirements Notation The *normative* sections of this document are Sections 2, 3, 4, and 6, together with the requirement explicitly marked normative in Section 5. Sections 1, 7, and 8 are non-normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [3] (Section 12) [4] (Section 12) when, and only when, they appear in all capitals within normative text. Examples in this document are illustrative and non-normative. Gallo Informational [Page 10] PIC Prover and Verifier July 2026 1.8. Origin Authority Context A lineage begins when a principal expresses an intent within its privileges. The result is a *PIC Context of Authority (PCA)*: the logical authority context that establishes the upper bound for the lineage. The root PCA contains no Proof of Relationship: there is no predecessor to relate to. Every later continuity advancement continues, and may only attenuate, the authority established by the root. This specification does not require every hop to create a new signed PCA. A profile defines the concrete signed root representation and the concrete continuity-advancement representation. In PIC Profile 0.2, a PCA is serialized and signed as a native *PIC PCA COSE* checkpoint. A settled *PIC Token JWT* carries a settled *PIC Continuity COSE* in pic.root; the settled Continuity carries the exact signed PIC PCA COSE bytes for the current trusted checkpoint. A workload proposes one centralized advancement by signing a *PIC Continuity Transition COSE*, placing it in a workload-signed candidate *PIC Continuity COSE*, and carrying that candidate in a workload-signed candidate PIC Token JWT. The trusted settlement authority validates the candidate and issues the next settled PIC Token JWT. The examples represent authority as an operations set — the reference profile, matching the operation-resource privileges of the model [1] (Section 12). PIC does not require this representation, nor does it define the application's authorization vocabulary; Section 4 covers authority as an abstract domain (roles, labels, scopes, policy references) and its relationship to a Policy Decision Point. The following root-PCA examples are illustrative views of a generic example profile, not the PIC Profile 0.2 logical PCA or wire schema. In particular, the illustrative continuation.mode = "single-use" member is not a Profile 0.2 field or invariant. In the running scenario, Alice connects to the backup SaaS. The service agreement confirms that the service is operated in Europe by an accountable party and does not use agentic execution. On those terms she grants access to all her files for backup. Her client produces a root PCA, signed or otherwise authenticated by the selected origin profile: Gallo Informational [Page 11] PIC Prover and Verifier July 2026 { "issuer": "did:example:users:alice", "invariants": { "operations": ["READ-ALL", "BACKUP"], "executionContract": { "role": "backup-service", "compliance": ["GDPR"], "serviceAgreements": [ "https://legal.example.com/agreements/dpa-2026-001" ], "executionModel": "deterministic" } }, "continuation": { "challenge": "base64url-random-256-bit-value", "mode": "single-use", "expiresAt": "2026-07-17T10:05:00Z" }, "issuedAt": "2026-07-17T10:00:00Z", "expiresAt": "2026-07-18T10:00:00Z" } Later, Alice uses the same SaaS to summarize a document. The terms are different this time: the service runs in the United States and uses an AI agent. She accepts them, but only for the file foo. The resulting root PCA grants less and constrains differently: { "issuer": "did:example:users:alice", "invariants": { "operations": ["READ-FOO", "SHARE-FILES"], "executionContract": { "role": "summary-service", "serviceAgreements": [ "https://legal.acme.example/agreements/asa-2026-042" ], "executionModel": "agentic" } }, "continuation": { "challenge": "base64url-random-256-bit-value", "mode": "single-use", "expiresAt": "2026-07-17T10:05:00Z" }, "issuedAt": "2026-07-17T10:00:00Z", "expiresAt": "2026-07-18T10:00:00Z" } Gallo Informational [Page 12] PIC Prover and Verifier July 2026 Each root PCA starts a distinct lineage with its own authority bound, and no later continuity advancement can expand it. These are the two lineages of Section 1.4. The continuation block in these examples is the root bootstrap challenge consumed by the first Proof of Relationship (Section 2.3). PIC Profile 0.2 carries the corresponding root challenge as challenge.next_challenge inside the signed PIC PCA COSE checkpoint. A root PCA may be *minted directly* by an authenticated permissioned entity, or *derived from an existing credential* - for example from an OAuth access token through a profile-defined exchange. These derivations are out of scope for this specification, but they are in line with it, and one point must be clear: *PIC does not change authentication.* Identity and authentication mechanisms establish the origin; PIC governs only how authority propagates after that origin exists. 2. Prover Requirements A *PIC Prover* produces the next continuity advancement for a lineage. Except for the root establishment step, every continuity advancement produced by a Prover MUST: 1. identify *exactly one* predecessor continuity state; 2. include or bind a *cryptographic reference* to that predecessor; 3. include or bind the *Proof of Relationship* required by the selected profile; 4. yield authority equal to or more restrictive than the predecessor materialized authority; 5. bind the concrete execution or request as required by the selected profile; 6. be integrity-protected according to the selected profile. The first requirement is what keeps the cross-lineage composition of Section 1.4 out of the model: an advancement that combines authority from two lineages cannot be validated as a conforming continuation. An executor can always assemble arbitrary bytes locally; what it cannot do is have such a state accepted. Gallo Informational [Page 13] PIC Prover and Verifier July 2026 2.1. Prover Procedure Given a predecessor continuity state, the Prover MUST perform the following steps and MUST NOT emit a continuity advancement if any of them fails: 1. validate the predecessor continuity state (Section 2.2); 2. establish exactly one causal predecessor; 3. build the Proof of Relationship required by the selected profile (Section 2.3); 4. keep or attenuate the predecessor materialized authority (Section 2.4); 5. bind the concrete execution or request as required by the selected profile; 6. produce the next continuity advancement artifact (Section 2.5); 7. ensure the resulting authority is no greater than the predecessor authority. receive current continuity state | v validate predecessor continuity state | v build PoR and profile-required request/execution binding | v keep or attenuate materialized authority | v produce next continuity advancement | v emit updated continuity state Gallo Informational [Page 14] PIC Prover and Verifier July 2026 At the abstract level, the advancement is not required to be a PCA. The PIC Continuity Transition COSE is the proposed Profile 0.2 advancement artifact. It is carried as the single entry in transitions in a workload-signed candidate PIC Continuity COSE, which is carried by a workload-signed candidate PIC Token JWT. The trusted settlement authority validates that candidate and issues the next settled PIC Token JWT carrying a settled PIC Continuity COSE with transitions = null. 2.2. Predecessor Validation The Prover MUST validate the predecessor continuity state by applying the Verifier procedure of Section 3. If validation fails, the Prover MUST NOT emit a continuity advancement. The rest of this section assumes a valid predecessor. 2.3. Proof of Relationship The abstract *PoR* relation binds the current execution to exactly one predecessor. A non-root continuity advancement MUST carry or cryptographically bind the relationship evidence required by the selected profile. The selected profile MUST define the concrete checks that soundly witness the abstract single-hop PoR relation. A proof_of_relationship field, when defined by a profile, is relationship evidence. It is not by itself the complete Proof of Continuity and does not by itself establish semantic continuity. A transition is accepted as valid only when the required PoR relation holds and the separate non-expansion requirement, together with all other applicable profile checks such as predecessor binding, freshness, integrity, evidence or conformance, request/execution binding, revocation, and policy, also succeeds. Profile-defined concrete relationship validation may cover, as applicable: * a predecessor cryptographic reference; * challenge continuity or an equivalent profile-defined freshness mechanism; * holder, executor, or key relationship as required by the profile. Request/execution binding and executor or execution-contract conformance remain separate applicable advancement-validation checks; they are not, merely by being required for acceptance, part of the abstract PoR relation. Gallo Informational [Page 15] PIC Prover and Verifier July 2026 For PIC Profile 0.2, the PIC Continuity Transition COSE carries proof_of_relationship as a typed object: proof_of_relationship.type = "sd-jwt" proof_of_relationship.evidence = exact UTF-8 bytes of the textual issuer-signed Profile 0.2 SD-JWT presentation The type value controls parsing and validation of evidence. The selected Profile 0.2 PoR schema MUST bind or identify the workload verification key; this specification does not define a universal claim name and does not define a separate generic key_binding field. The predecessor reference for the current centralized Profile 0.2 realization is: predecessor.type = "pca" predecessor.hash = SHA-256(exact signed current root.pca PIC PCA COSE bytes) The first transition consumes the bootstrap challenge from the current PIC PCA COSE checkpoint's challenge.next_challenge. Later transitions use the challenge.next_challenge value carried by the current signed PIC PCA COSE checkpoint. The hash input is the exact signed PIC PCA COSE artifact bytes, not a decoded payload, diagnostic notation, JSON representation, Base64url text, or reserialized structure. The Prover MUST check its own PoR before proceeding: if the predecessor reference does not match the predecessor continuity state, or if the challenge or equivalent freshness evidence does not satisfy the selected relationship-validation rules, the required PoR relation is not established and the Prover MUST stop. If profile- required executor, contract, request/execution, or other required evidence is missing or invalid, the advancement is invalid and the Prover MUST stop. A continuity advancement carrying invalid required evidence is rejected at the next hop anyway. *What the PoR proves.* The PoR does not prove physical, counterfactual, or prior-designation causation. Taken in isolation, a challenge response or concrete relationship artifact proves only the relationship semantics defined by the selected profile. A hop is accepted as a valid PIC continuation only when the Verifier also applies the other required PIC and profile checks, including non- expansion and any applicable contract, request/execution, evidence, freshness, revocation, and policy checks. The selected concrete relationship checks are assumed to soundly witness the abstract single-hop PoR relation used by the model [1] (Section 12) and Lean formalization [2] (Section 12). Gallo Informational [Page 16] PIC Prover and Verifier July 2026 *Continuation is open by default.* The core model does not require a predecessor to preselect a concrete successor. A profile MAY constrain holder keys, recipients, or channels, but those constraints are profile-specific. When a selected profile defines a request or execution commitment, that binding fixes the concrete action accepted under that profile (Section 3.3). *Out of scope.* The canonical form of the request, digest construction, streaming and partial payloads, and request-binding construction are defined by the selected profile or by a separate specification. The core keeps only the profile-conditional requirement that authenticated request/execution commitments, when defined and relied upon, match the accepted or executed action (Section 3.3). *Note - proof mechanism agility.* Future or separate profiles may realize PoR and advancement integrity with mechanisms other than the current Profile 0.2 typed SD-JWT evidence, including signed hash chains, Merkle proofs, accumulators, recursive or zero- knowledge proofs, or hardware-backed attestations, provided they preserve the normative semantics: binding to exactly one predecessor, profile-defined freshness or challenge continuity, non-expansion of authority, and integrity of the concrete advancement. 2.4. Invariant Monotonicity Once the PoR holds, the Prover determines the resulting materialized authority. At each hop the authority is either kept unchanged or attenuated, *never expanded*: * every entry in *operations* MUST also be present in the predecessor operations; * every constraint of the predecessor *executionContract* MUST be preserved or strengthened. A Prover MAY drop operations, add constraints, or shorten the validity period. A Prover MUST NOT add operations, relax constraints, or extend the validity period. _What is dropped at a hop is lost:_ no later hop can reintroduce it. The root authority context (Section 1.8) granted READ-ALL and BACKUP. The backup service needs only read access downstream, so it drops BACKUP and sets the attenuated invariants: Gallo Informational [Page 17] PIC Prover and Verifier July 2026 { "operations": ["READ-ALL"], "executionContract": { "role": "backup-service", "compliance": ["GDPR"], "serviceAgreements": [ "https://legal.example.com/agreements/dpa-2026-001" ], "executionModel": "deterministic" } } The order that decides "more restrictive" is defined by the profile (Section 4): here operations uses subset inclusion and the executionContract fields use the reference profile's order. In PIC Profile 0.2, the PIC PCA COSE payload context_of_authority carries an Indexed Authority Map, not the normalized Logical Context of Authority directly. The logical authority shape contains optional identity_context and execution, where execution.invariants carries executable PIC authority and execution.contract carries constraints. The canonical Indexed Authority Map sections are identity_context, invariants, and execution_contract; logical execution.contract maps to execution_contract. identity_context is descriptive or contextual and does not itself grant execution authority. Section-local numeric indexes start at 0. Bitmap identity is (section, numeric index), for example identity_context/0 or invariants/1; JSON object member order has no protocol meaning. Indexed Authority Map entries use compact tuples. Tuple element order is normative: * identity_context: [key, value]; * execution_contract: [key, value]; * invariants: [scope, operation, resourceType, resourceId]. A logical Profile 0.2 execution.contract value MUST contain at least one attribute. Each logical attribute value MUST be either a non- empty string or a non-empty array of non-empty strings. Profile 0.2 implementations MUST reject logical execution.contract values containing a number, boolean, object, null, empty string, empty array, array containing an empty string, or array containing a non- string value. Gallo Informational [Page 18] PIC Prover and Verifier July 2026 Scalar logical values become one indexed tuple. Set or list membership is denormalized into independently indexed boolean membership tuples, for example ["roles:payment-approver", true]. That true is a canonical denormalized membership representation in the Indexed Authority Map; it is not permission for arbitrary boolean values in the logical execution.contract input domain. This document defines no false-valued membership semantics for Profile 0.2. Removal attenuation applies only to attenuations.identity_context.remove_bitmap and attenuations.invariants.remove_bitmap, each evaluated against the section-local numeric indexes of its own map section. Removal never adds authority, and a removed entry cannot reappear later in the same continuity. For Profile 0.2 removal bitmaps, byte_index = floor(i / 8), bit_index = i mod 8, and mask = 1 << bit_index; bits are interpreted least- significant-bit first. Thus index 0 is h'01', index 1 is h'02', index 2 is h'04', index 7 is h'80', and index 8 is h'0001'. A set bit referring to a nonexistent predecessor index MUST be rejected. Trailing zero bytes MUST be omitted. A no-op bitmap SHOULD be omitted together with its optional attenuation member. Execution-contract restriction does not use a removal bitmap. Accepted restrictions are carried as attenuations.execution_contract.additions. Each proposed addition is a [key, value] tuple for the execution_contract section; the workload MUST NOT assign its numeric index. The settlement verifier validates proposed additions and assigns the next section-local numeric indexes in the materialized/effective execution_contract section. Existing execution-contract constraints are not removed, replaced, or weakened; accepted constraints accumulate with logical AND. When one PIC Continuity Transition COSE proposes multiple execution- contract additions, the settlement verifier validates the proposed additions and denormalizes any collection-valued logical proposal material into individual canonical [key, value] additions when applicable. After denormalization, more than one accepted addition with the same canonical key MUST be rejected. The settlement verifier then sorts the remaining accepted additions lexicographically by canonical key using Unicode code point order, assigns the next section-local numeric indexes in that sorted order, and materializes the additions. Input array order MUST NOT determine materialized index assignment. The workload is not required to pre- sort the additions. Gallo Informational [Page 19] PIC Prover and Verifier July 2026 Initial PIC PCA COSE canonicalization for Profile 0.2 is deterministic. Implementations denormalize the Logical Context of Authority into canonical tuple candidates, sort candidates within each section, and then assign section-local numeric indexes starting at 0. For identity_context and execution_contract, candidates are sorted lexicographically by canonical key, using Unicode code point order. Collection memberships are denormalized before sorting; each member becomes its own [key, true] tuple, and the complete resulting canonical membership key determines ordering. For invariants, candidates are sorted lexicographically by tuple elements in this order: scope, operation, resourceType, resourceId, using Unicode code point order for each element. After sorting, indexes 0, 1, 2, and so on are assigned within each section. Implementations MUST NOT derive index values from JSON object member order. Canonical serialization of an already indexed Profile 0.2 authority map is separate from initial index assignment. For serialization and authority-state structural ordering, sections are ordered as identity_context, invariants, execution_contract, and entries within each indexed section are ordered by ascending numeric index. This ordering defines the deterministic canonical structure, but does not by itself define an interoperable hash-input byte string. An authority-state hash, when defined by a selected profile or schema, requires that profile or schema to define the exact byte serialization used as hash input. Profile 0.2 signed-artifact references such as root.pca_hash and predecessor.hash are computed over exact signed COSE artifact bytes. Authority-state identity and signed-artifact identity are separate domains. 2.5. Continuity Advancement Construction The Prover assembles the next continuity advancement from the PoR of Section 2.3, the attenuation of Section 2.4, the request or execution binding required by the profile, and the profile-defined freshness material for the next step. The profile defines the signed artifact that protects those values. Gallo Informational [Page 20] PIC Prover and Verifier July 2026 In PIC Profile 0.2, a PIC Continuity Transition COSE contains position, a structured predecessor reference, challenge.previous_challenge, challenge.next_challenge, optional attenuations, and typed proof_of_relationship. It is carried only by the workload-produced candidate PIC Continuity COSE for the current exchange. The settlement authority validates the candidate and, if the advancement is accepted, issues the next settled PIC Token JWT carrying a settled PIC Continuity COSE with transitions = null. Diagnostic JSON-like or CBOR-like views are illustrative unless a selected profile assigns exact encodings. The following non-normative sketch shows the abstract contents of an advancement: { "predecessorReference": "profile-defined cryptographic reference", "proofOfRelationship": { "...": "profile-defined PoR" }, "attenuation": { "...": "profile-defined authority attenuation" }, "nextFreshness": { "...": "profile-defined next challenge or equivalent" }, "requestBinding": { "...": "profile-defined request/execution binding" }, "signatureOrProof": { "...": "profile-defined integrity protection" } } The integrity protection MUST cover the predecessor reference, PoR, attenuation, freshness material, temporal fields, and any request/ execution binding required by the selected profile. A valid signature or proof is necessary but not sufficient: the Verifier still performs all semantic checks in Section 3. 3. Verifier Requirements A *PIC Verifier* validates a continuity state before any authority is exercised. The checks are profile-dependent in representation but not in semantics. A Verifier MUST: 1. establish and validate the trusted root; 2. validate the concrete continuity representation selected by the profile; 3. validate every required causal advancement or equivalent proof representation; 4. materialize the current authority; 5. accept only if every required check succeeds; otherwise reject. Gallo Informational [Page 21] PIC Prover and Verifier July 2026 The authority a Verifier may authorize at the current hop is the current materialized authority. By monotonicity (Section 2.4), it is bounded by the root authority, so a privilege absent from the root cannot be authorized downstream. 3.1. Verifier Procedure Given a received continuity state, the Verifier MUST perform the following steps and MUST reject the hop if any of them fails: 1. establish the trusted root authority representation; 2. validate the root representation and its authenticated origin; 3. validate the profile-selected continuity representation; 4. validate predecessor continuity for each required advancement; 5. validate PoR for each non-root advancement; 6. validate challenge continuity or the equivalent freshness mechanism used by the profile; 7. validate profile-required evidence, conformance, freshness, temporal state, and revocation state; 8. validate request/execution binding when required by the selected profile; 9. apply profile-defined attenuations and verify non-expansion; 10. verify the final materialized authority commitment when the profile defines one; 11. accept the materialized current authority. For PIC Profile 0.2, ordinary verification of a settled artifact includes verifying the settled PIC Token JWT signature, obtaining pic.root as the exact PIC Continuity COSE bytes, verifying the settled PIC Continuity COSE signature and profile, verifying that transitions = null, verifying root.pca as the exact signed PIC PCA COSE bytes for the current trusted checkpoint, recomputing root.pca_hash, and verifying that the signed PIC PCA COSE payload supplies the materialized authority, position, and challenge.next_challenge. When revocation is enabled for a revocable continuity, the Verifier also validates the authenticated revocation coordinates required by the PIC Revocation Specification before evaluating applicable authenticated revocation state. This document Gallo Informational [Page 22] PIC Prover and Verifier July 2026 does not assign concrete settled-token fields or placement for revocation coordinates other than the Profile 0.2 PCA position. Ordinary Profile 0.2 Verifiers are not required to replay a transported transition history. When a trusted settlement authority processes a Profile 0.2 advancement candidate, it additionally: 1. receives the candidate PIC Token JWT as untrusted input and parses it without accepting authenticity; 2. obtains pic.root as untrusted candidate PIC Continuity COSE bytes; 3. parses the candidate Continuity without accepting authenticity and validates the presence and shape of root.pca, root.pca_hash, and transitions; 4. requires transitions to contain exactly one PIC Continuity Transition COSE; 5. parses that Transition as untrusted input and extracts proof_of_relationship; 6. validates the proof_of_relationship structure; 7. requires proof_of_relationship.type = "sd-jwt"; 8. parses proof_of_relationship.evidence as the exact UTF-8 bytes of the textual issuer-signed Profile 0.2 SD-JWT presentation; 9. validates the SD-JWT issuer signature, issuer trust, required disclosures, claims, and schema requirements; 10. obtains or resolves the workload verification key accepted from the PoR; 11. verifies the Transition COSE signature, candidate Continuity COSE signature, and candidate PIC Token JWT signature using that accepted workload key, and verifies signer consistency as required by the profile; 12. verifies root.pca as the exact signed PIC PCA COSE bytes for the currently trusted checkpoint; 13. recomputes SHA-256(exact signed root.pca PIC PCA COSE bytes) and compares it with root.pca_hash; Gallo Informational [Page 23] PIC Prover and Verifier July 2026 14. verifies that Transition.position = current PCA.position + 1; 15. verifies predecessor.type = "pca" and predecessor.hash = SHA- 256(exact signed current root.pca PIC PCA COSE bytes); 16. verifies that Transition.challenge.previous_challenge = current PCA.challenge.next_challenge and validates challenge.next_challenge; 17. validates removal bitmaps and execution-contract additions, including deterministic ordering and section-local index assignment for accepted additions; 18. validates request/execution binding and executor evidence or conformance when required by the selected profile; 19. validates authority non-expansion, revocation, and local/profile policy; 20. materializes the new authority, creates logical PCA N+1, transfers the accepted next challenge into it, serializes and signs it as a new PIC PCA COSE checkpoint, creates a settled PIC Continuity COSE with the new root.pca, recomputed root.pca_hash, and transitions = null, and creates/signs the settled PIC Token JWT. If validation succeeds, the settlement authority issues the next settled PIC Token JWT. PIC-X is one realization of this settlement role. 3.2. Root Validation The root authority context is validated differently from later advancements: it carries no Proof of Relationship and no predecessor reference, because there is no predecessor. The Verifier MUST: * verify the root representation according to the selected profile; * verify that the root issuer or origin authority is trusted for the represented authority; * confirm applicable temporal and revocation state; * extract the root authority and any root bootstrap challenge or equivalent freshness material. Gallo Informational [Page 24] PIC Prover and Verifier July 2026 In PIC Profile 0.2, the root representation is the signed PIC PCA COSE checkpoint carried as exact bytes in root.pca by the settled PIC Continuity COSE. The PIC PCA COSE carries the Indexed Authority Map, position = 0, and challenge.next_challenge, which initializes the first PIC Continuity Transition COSE. The signed-artifact hash is carried as root.pca_hash and is computed over the exact signed PIC PCA COSE bytes. 3.3. Advancement Validation For each non-root continuity advancement, the Verifier MUST perform the following checks and MUST reject the continuity state if any fails: 1. *integrity* — the advancement artifact or proof is valid under the profile's canonical encoding and cryptographic suite (Section 6.4); 2. *predecessor binding* — the predecessor cryptographic reference identifies exactly one predecessor continuity state, and the challenge answered, authority attenuated, and execution contract checked all belong to that same predecessor; 3. *continuation* — the challenge or equivalent freshness mechanism satisfies the selected profile and has the declared consumption scope (Section 6.1); 4. *executor / relationship evidence* — when required by the selected profile, the required executor, holder, key, attestation, or equivalent relationship evidence is valid according to that profile; 5. *execution-contract conformance* — when the predecessor authority context contains an execution contract and the selected profile requires executor conformance evidence, the presented executor or evidence satisfies that contract according to the profile-defined conformance function (Section 4); for example a deterministic contract rejects an agentic executor; 6. *non-expansion* — the resulting authority is equal to or more restrictive than the predecessor materialized authority under the profile's attenuation order (Section 4); 7. *temporal* — the advancement and resulting continuity state satisfy the profile's temporal rules (Section 6.3); Gallo Informational [Page 25] PIC Prover and Verifier July 2026 8. *request/execution binding* — when the selected profile defines or requires a request/execution commitment, the concrete action accepted or executed matches the operation, target, parameters, digests, or equivalent semantic values bound by that commitment. A valid signature establishes _integrity_, not _semantic validity_: checks 2–8 are separate and the Verifier MUST NOT skip them because the signature verified. The Verifier does *not* trust that the Prover already performed these checks; it repeats them independently. *Executed-vs-bound.* When a selected profile defines a request/ execution commitment and relies on that commitment to authorize a concrete action, the reference monitor or equivalent enforcement point MUST ensure that the action accepted or executed matches the authenticated commitment. Signing or binding one action and executing another is invalid under that profile. This is where the cross-lineage composition of Section 1.4 fails: authority absent from the predecessor fails non-expansion (6), and a PoR that does not bind to the predecessor fails continuation (3) or predecessor binding (2). Such a state cannot be validated as a conforming continuation, even though an executor can always assemble arbitrary bytes locally. 4. Authority Domains and Attenuation Profiles 4.1. Authority as an Abstract Domain PIC does not define the application's authorization vocabulary and does not replace its access-control system. It preserves the _causal continuity_ and _non-expansion_ of an authority context whose meaning is defined by the application or by an applicable PIC profile. That context may be represented as operation-resource pairs, roles, labels, scopes (for example lifted from an OAuth token), capability classes, or policy references. Normatively the requirement is only: authority(i+1) ≤ authority(i) where ≤ is an _attenuation order_ defined by the profile. The operations set with subset inclusion, used in the examples, is the *reference profile*: it corresponds to the operation-resource privileges of the model [1] (Section 12). A label may _denote_ authority without listing it: EU-BACKUP-READONLY denotes a set of operation-resource permissions and carries that meaning by reference. This keeps the confused-deputy result intact rather than discarding it — a label is defined to denote a semantic set (in the reference case an O×R set), and the label order is Gallo Informational [Page 26] PIC Prover and Verifier July 2026 required to *refine* the subset order on those denotations. O×R is thus the profile where non-expansion is immediate, and any other profile inherits the guarantee exactly to the extent that its order refines its denotation order. 4.2. Attenuation Profiles Every profile that introduces an authority representation MUST define its syntax, its equivalence relation, its attenuation order ≤, and a deterministic comparison sufficient for non-expansion validation. A profile that uses an execution contract MUST additionally define the conformance semantics or function required to determine whether presented executor evidence satisfies that contract, when the profile requires such conformance evidence. For example: role: current == predecessor allowedRegions: current ⊆ predecessor requiredCompliance: current ⊇ predecessor executionModel: current ⊆ predecessor expiresAt: current ≤ predecessor The core uses the abstract relation Attenuates(current, predecessor, profile); a Verifier MUST reject a PCA whose profile is unknown or does not define a deterministic comparison. Concrete profiles for specific domains are defined by separate specifications. Translation between _heterogeneous_ authority domains is out of scope here; consistent with the model, an overly permissive translation is a profile error, not a violation of the continuity invariant. 4.3. Policy Decision Point (PDP) Integration PIC and access control answer different questions: PIC: is this authority state a valid non-expansive continuation of the state that caused the execution? Access control: does this authority state authorize this concrete operation under the application policy? Using a PDP is an *application choice*, not part of PIC. An executor MAY evaluate policy locally, or it MAY pass the authority context to a *Policy Decision Point* — Cedar, Rego, XACML, or another engine — that interprets the label's semantics and renders the access decision. The two decisions MAY run in one component or in separate ones. PIC neither requires a PDP nor defines one; this section exists only for implementers who choose that path. Gallo Informational [Page 27] PIC Prover and Verifier July 2026 Whoever takes that path takes an obligation with it, and it is *theirs, not PIC's*: the declared attenuation order on labels MUST be _monotone with respect to their semantics_. If current ≤ predecessor in the label order but the meaning of current is not contained in the meaning of predecessor, PIC's non-expansion is vacuous — the labels shrink while what they authorize grows. Establishing that the label order refines its denotation order is up to the application or its PDP. It does *not inherit the Lean proof* [2] (Section 12): the proof covers non-expansion of the _abstract_ order only; semantic monotonicity of a concrete vocabulary is a separate proof obligation that PIC does not discharge. This is the same boundary the model already draws for heterogeneous translation, and it is a natural point of standardization — label vocabularies with provably semantic- monotone orders, and the PIC↔PDP interface that carries the obligation. 5. Continuity Representations A PIC continuity state can be represented and validated in more than one way. The choice does not change the model - the invariants and the checks of Section 3 stay the same - but it changes validation cost and trust assumptions. This section contains non-normative representation guidance and explicit profile requirements. A representation does not inherit the Lean proof automatically; each profile MUST show that its concrete acceptance predicate implies the abstract PoC (Section 6.5). A continuity profile MAY use: * self-contained transition graphs; * incremental representations; * compacted or checkpointed representations; * referenced history; * succinct proofs; * other proof mechanisms. The profile MUST define its acceptance predicate, canonicalization, cryptographic references, freshness mechanism, authority materialization, and failure behavior. It MUST preserve exactly-one- predecessor continuity, PoR, non-expansion, request/execution binding when required by that profile, and verifier independence. Gallo Informational [Page 28] PIC Prover and Verifier July 2026 5.1. Current Profile 0.2 Representation PIC Profile 0.2 uses centralized settlement. A settled PIC Token JWT is issued by the trusted settlement authority and carries a settled PIC Continuity COSE in pic.root. That Continuity carries the exact signed PIC PCA COSE bytes for the current trusted checkpoint in root.pca, the matching root.pca_hash, and transitions = null. root.pca is the current checkpoint, not an immutable genesis artifact: after an accepted advancement it changes from PIC PCA COSE N to PIC PCA COSE N+1. trusted settled PIC Token JWT N `-- pic.root = settled PIC Continuity COSE N +-- root.pca = exact signed PIC PCA COSE N bytes +-- root.pca_hash = SHA-256(exact signed PIC PCA COSE N bytes) `-- transitions = null workload-signed candidate PIC Token JWT `-- pic.root = workload-signed candidate PIC Continuity COSE +-- root.pca = exact signed PIC PCA COSE N bytes +-- root.pca_hash = matching SHA-256 digest `-- transitions = [ exactly one workload-signed PIC Continuity Transition COSE N+1 ] trusted settlement validation trusted settled PIC Token JWT N+1 `-- pic.root = settled PIC Continuity COSE N+1 +-- root.pca = exact signed PIC PCA COSE N+1 bytes +-- root.pca_hash = SHA-256(exact signed PIC PCA COSE N+1 bytes) `-- transitions = null The candidate is not a trusted settled continuity artifact. The settlement authority validates the current settled continuity, the candidate PIC Token JWT, the candidate PIC Continuity COSE, the single PIC Continuity Transition COSE, PoR/key binding, predecessor hash over the exact current PIC PCA COSE bytes, position increment, challenge continuity, removal attenuations, execution-contract additions including deterministic canonical ordering and index assignment for accepted additions, non-expansion, revocation, and local/profile policy. If validation succeeds, the settlement authority materializes the new authority into a new PIC PCA COSE checkpoint and issues the next settled PIC Token JWT. Gallo Informational [Page 29] PIC Prover and Verifier July 2026 Profile 0.2 does not transport a replayable transition graph in the settled PIC Continuity COSE. The current authority and post-initial challenge material are represented by the latest trusted PIC PCA COSE checkpoint carried in root.pca; the settled Continuity itself has no position field and no challenge field. 5.2. Profile 0.2 Artifact Semantics This subsection is normative for PIC Profile 0.2. The semantic field names below are normative for this profile. Exact CBOR integer labels, COSE protected-header typ values, media-type registrations, and any IANA assignments are deferred to the applicable profile registry or a later byte-level wire assignment; this subsection does not invent them. The active PIC Profile 0.2 identifier is: https://pic-protocol.org/profiles/0.2 Profile 0.2 uses the following artifact format identifiers: +================================+================================+ | Artifact | Profile 0.2 format identifier | +================================+================================+ | PIC Token JWT | pic+jwt | +--------------------------------+--------------------------------+ | PIC PCA COSE | pic-pca+cose | +--------------------------------+--------------------------------+ | PIC Continuity COSE | pic-continuity+cose | +--------------------------------+--------------------------------+ | PIC Continuity Transition COSE | pic-continuity-transition+cose | +--------------------------------+--------------------------------+ Table 1 These identifiers are Profile 0.2 format identifiers, not IANA- assigned media types unless and until a registration assigns that status. Profile 0.2 also uses the following stable semantic definition URIs: Gallo Informational [Page 30] PIC Prover and Verifier July 2026 +====================+=======================================+ | Concept | Definition URI | +====================+=======================================+ | PIC Token type URI | https://pic-protocol.org/definitions/ | | | token-types/pic | +--------------------+---------------------------------------+ | Initial Continuity | https://pic-protocol.org/definitions/ | | Proposal type URI | proposal-types/continuity-initial | +--------------------+---------------------------------------+ Table 2 5.2.1. PIC Token JWT A PIC Token JWT has format identifier pic+jwt. The pic.root member MUST contain the unpadded Base64url encoding of the exact binary PIC Continuity COSE artifact bytes. A candidate PIC Token JWT is workload-signed. A settled PIC Token JWT is signed by the trusted settlement authority. Candidate and settled tokens use the same pic+jwt format; no second token format is defined for the candidate role. Exact JOSE typ assignment is deferred to the applicable profile registry or later byte-level wire assignment. 5.2.2. PIC PCA COSE A PIC PCA COSE is the signed checkpoint artifact representing a logical PCA. Its Profile 0.2 semantic payload contains: profile position context_of_authority challenge.next_challenge position is a non-negative canonical integer defined by Profile 0.2. context_of_authority is the canonical Indexed Authority Map defined in Section 2.4. challenge.next_challenge is binary challenge material for the next Profile 0.2 transition. 5.2.3. PIC Continuity COSE A PIC Continuity COSE has the following Profile 0.2 semantic payload: Gallo Informational [Page 31] PIC Prover and Verifier July 2026 profile root: pca_hash pca transitions root.pca MUST contain the exact signed PIC PCA COSE bytes for the current trusted checkpoint. root.pca_hash MUST equal SHA-256(exact signed root.pca bytes), and Verifiers MUST recompute it. A settled Profile 0.2 Continuity MUST have transitions = null. A candidate Profile 0.2 Continuity MUST have transitions containing exactly one PIC Continuity Transition COSE. PIC Continuity COSE itself does not require a position field or challenge field in Profile 0.2; those values belong to PIC PCA COSE checkpoints and PIC Continuity Transition COSE artifacts. 5.2.4. PIC Continuity Transition COSE A PIC Continuity Transition COSE has the following Profile 0.2 semantic payload: profile position predecessor: type hash challenge: previous_challenge next_challenge attenuations optional proof_of_relationship: type evidence request_digest optional/profile-defined executor_evidence optional/profile-defined For current Profile 0.2, predecessor.type MUST be "pca" and predecessor.hash MUST equal SHA-256(exact signed current root.pca PIC PCA COSE bytes). A future or separate profile MAY define another predecessor representation while preserving exactly-one-predecessor semantics. proof_of_relationship is a typed object. For current Profile 0.2, proof_of_relationship.type MUST be "sd-jwt" and proof_of_relationship.evidence MUST be a byte string containing the exact UTF-8 bytes of the textual issuer-signed SD-JWT presentation selected by the Profile 0.2 PoR schema. That schema MUST bind or Gallo Informational [Page 32] PIC Prover and Verifier July 2026 identify the workload verification key used to verify the workload- signed candidate artifacts. Profile 0.2 does not define a universal claim path, does not require cnf.jwk at the PIC protocol level, and does not require a separate SD-JWT KB-JWT for continuity advancement. Signer roles are: PoR issuer signs issuer-signed SD-JWT workload key accepted through PoR signs PIC Continuity Transition COSE signs candidate PIC Continuity COSE signs candidate PIC Token JWT trusted settlement authority signs new PIC PCA COSE signs settled PIC Continuity COSE signs settled PIC Token JWT The workload signatures prove control of the selected workload key and authenticate the candidate objects. They do not, by themselves, establish semantic continuity; the Verifier still performs the complete Profile 0.2 validation procedure. 5.3. Profile 0.2 OAuth Token Exchange Binding OAuth is not required by the PIC model. This subsection is normative only for a Profile 0.2 binding that uses OAuth Token Exchange [7] (Section 12) as an entry or advancement transport. For initialization: Gallo Informational [Page 33] PIC Prover and Verifier July 2026 grant_type urn:ietf:params:oauth:grant-type:token-exchange subject_token OAuth access token subject_token_type urn:ietf:params:oauth:token-type:access_token requested_token_type https://pic-protocol.org/definitions/token-types/pic continuity_proposal compact UTF-8 JSON encoded with unpadded Base64url; the decoded object is self-describing and has type https://pic-protocol.org/definitions/proposal-types/continuity-initial result settlement-authority-signed settled PIC Token JWT 0 For PIC-to-PIC advancement: grant_type urn:ietf:params:oauth:grant-type:token-exchange subject_token workload-signed candidate PIC Token JWT subject_token_type https://pic-protocol.org/definitions/token-types/pic requested_token_type https://pic-protocol.org/definitions/token-types/pic continuity_proposal omitted result settlement-authority-signed settled PIC Token JWT N+1 The initialization proposal is interpreted by its internal type member. Current Profile 0.2 PIC-to-PIC advancement omits continuity_proposal. The RFC 8693 response MAY transport the returned PIC Token JWT in the access_token response member. That placement does not make the PIC Token JWT an OAuth Bearer token. For this Profile 0.2 binding, when an issued_token_type response member is returned for a PIC Token JWT, Gallo Informational [Page 34] PIC Prover and Verifier July 2026 its value is https://pic-protocol.org/definitions/token-types/pic. When a token_type response member is returned for a PIC Token JWT, its value is "N_A". Endpoint paths, client authentication, and the complete Initial Continuity Proposal schema are defined by the selected exchange binding. This document does not assign additional OAuth endpoint paths, client-authentication rules, proposal schema fields, or URI values beyond the Profile 0.2 identifiers above. 5.4. Self-Contained Transition Graphs A future or separate profile MAY use a self-contained transition graph, provided the profile defines the graph format, predecessor references, authority materialization, proof requirements, and acceptance predicate. Such a graph is not the current Profile 0.2 realization. 5.5. Incremental, Checkpointed, or Referenced History A profile MAY carry only the information needed for the receiving Verifier, rely on external authenticated state, use checkpoints, use compacted or referenced history, or combine those mechanisms. Such a profile MUST define what the Verifier independently verifies and what trust assumption, if any, is placed on a validator, checkpoint issuer, history service, or prior verifier. 5.6. Succinct Proofs The validity of a continuity prefix can be represented by a succinct proof - for example a zero-knowledge proof or accumulator proof - that a Verifier checks without walking the entire prefix. The choice of construction, soundness assumptions, setup, disclosure properties, and verification procedure are out of scope for this document and MUST be defined by the selected profile. 6. Security Considerations 6.1. Freshness, Replay, and Fan-out Freshness protects against *replay*. Because a PCA travels in the clear, anyone who observes one could otherwise present it again as if it were continuing the lineage now. The authority it carries is still bounded by the origin, so replay cannot _escalate_ — but it could re-run a past action, or run it in a context that no longer applies. Freshness closes that window by making each continuation answer something the predecessor issued specifically for this hop. Gallo Informational [Page 35] PIC Prover and Verifier July 2026 The following JSON is an illustrative example of a profile that explicitly models challenge-consumption policy. It is not the current Profile 0.2 wire schema and does not define generic PIC fields: { "continuation": { "challenge": "base64url-random-256-bit-value", "mode": "single-use", "maxUses": 1, "expiresAt": "2026-07-17T10:06:00Z" } } In that example profile, continuation carries no recipient selector. In the core, continuation is *open*: the predecessor need not preselect the successor. When a selected profile defines mode and maxUses, those fields govern consumption, replay, and fan-out — not _who_ may continue. Recipient-, key-, or channel-constrained continuations are future extension profiles (Section 6.6). For a profile-defined single-use challenge, a Verifier MUST prevent it from being consumed twice within the enforcement scope declared by that profile, keeping state or an equivalent mechanism. Note the scope: maxUses enforced per Verifier is a _local_ bound — it does not cap total uses across independent Verifiers. A global limit needs shared state or coordination, whose delivery semantics (at-most-once vs at-least-once) are out of scope for this document. *Fan-out* is the case where reuse is intentional: several successors continue the same predecessor, which is permitted provided each branch references that predecessor, each branch is individually valid, and no branch composes authority from — or recovers authority attenuated by — another branch. Authorized fan-out is therefore distinct from unauthorized replay: in the example profile, the difference is declared by mode/maxUses and enforced by the Verifier. Gallo Informational [Page 36] PIC Prover and Verifier July 2026 Three consumption semantics are therefore distinct. *Local single- use*: the challenge is consumed once per Verifier state; independent Verifiers without shared state can each accept the same continuation. *Coordinated single-use*: the challenge is consumed once across Verifiers; it requires shared state or a coordinating component — the Trust Plane of the PIC Architecture and Deployment Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- architecture-deployment-spec.md), or a future federation profile. *Bounded multi-use (fan-out)*: reuse explicitly authorized and declared by the selected profile. A property that depends exclusively on local Verifier state MUST NOT be described as global single-use. Replay never expands authority, but it can duplicate effects or continuations; coordination adds the bound on their global cardinality. The continuation challenge is *one* freshness mechanism, not a mandatory one. A profile MAY meet the same goal differently — for example with a monotonic per-lineage counter, a server-issued single- use ticket, or a bounded acceptance window (Section 6.3). A profile MAY rely on an external anti-replay mechanism only when that mechanism is explicitly part of the profile's authenticated acceptance predicate, has a defined enforcement scope, and preserves the profile's continuity guarantees. Ordinary transport security by itself does not create PIC continuity. What is normative is conformance to the consumption semantics and enforcement scope declared by the selected profile, not the specific freshness mechanism: the anti-replay enforcement MUST match the scope the profile declares, and a profile claiming coordinated single-use MUST provide the shared state or coordination required to enforce that claim across the participating Verifiers. 6.2. Origin Trust Boundary PIC governs propagation _after_ an origin authority context has been validly established. It does not by itself determine whether an actor was entitled to originate that context. Minting or deriving a root PCA (Section 1.8) MUST be permissioned, policy-controlled, attributable, and auditable. In particular, distinguishing a request-caused action from an action an executor re-originates as a new lineage of its own is a responsibility of the origination policy and the enforcement architecture, not of the continuity invariant: a compromised executor that re-originates authority is outside the guarantee. Gallo Informational [Page 37] PIC Prover and Verifier July 2026 6.3. Temporal Rules and Per-Hop Expiry For every non-root continuity advancement a Verifier MUST check the temporal constraints defined by the selected profile. A simple profile may use: current.issuedAt ≥ predecessor.issuedAt current.expiresAt ≤ predecessor.expiresAt current.issuedAt ≤ verificationTime < current.expiresAt challenge.expiresAt ≤ predecessor.expiresAt Beyond this lineage bound, each advancement SHOULD carry its own short expiry or equivalent freshness bound, set from its creation time and distinct from the lineage's total validity. The lineage expiresAt bounds the whole continuity state; a tighter per- advancement window bounds a single continuation. This second, shorter expiry limits the damage of a replay: even if a continuation is duplicated within the lineage's total validity, it is accepted only for the brief window after its creation, not for the full remaining lifetime of the lineage. The root need not carry the tighter window; later advancements SHOULD. Allowed clock skew is a profile parameter. Online verification uses the current time; retrospective (audit) verification requires trusted-time evidence for the execution instant and is left to a profile. 6.4. Canonicalization and Cryptographic Agility The byte representation covered by a hash or signature MUST be unambiguous and deterministically reproducible under the selected profile. Each profile MUST state its canonical encoding, hash algorithm, signature algorithm, domain-separation rules, and a suite identifier. The illustrative profile uses canonical JSON, SHA-256, and Ed25519; these are not required of every implementation. PIC is not tied to JSON. A profile MAY carry and sign root authority and continuity artifacts with established envelopes such as *JOSE* (JWS/JWT) or *COSE*, or with any canonical binary encoding. For network-heavy or resource-constrained infrastructure, a binary format is RECOMMENDED — in particular *CBOR* (with COSE for signing) — to reduce size and parsing cost; deterministic CBOR gives the reproducible byte representation this section requires. Selective- disclosure or zero-knowledge mechanisms MAY replace full-attestation signing, provided the Verifier can still establish the required attributes, issuer validity, subject binding, validity period, and conformance. Such mechanisms do not change PIC semantics, but they may change the cryptographic trust model. Gallo Informational [Page 38] PIC Prover and Verifier July 2026 6.5. Formal Scope The Lean formalization [2] (Section 12) proves the logical safety properties of the abstract model and, through a refinement mapping, that any chain accepted under the modeled verifier assumptions satisfies the abstract PIC invariants. The computational security of the chosen cryptographic primitives, the soundness of concrete PoR mechanisms and issuer infrastructure, runtime or attestation integrity, revocation state, and the semantic monotonicity of a concrete authority profile (Section 4.3), remain *external assumptions*. It is not claimed that Lean proves the security of ES256, SHA-256, COSE, JWS, SD-JWT, or any deployment-specific cryptographic implementation. 6.6. Proof of Possession (Optional) The core binds a hop to its accepted continuity advancement. When a selected profile defines a request/execution binding, that profile pins the accepted or executed action through that binding (Section 2.3). A profile MAY add a *proof of possession* of the request or channel — for example *DPoP* [5] (Section 12), *HTTP Message Signatures* [6] (Section 12), or an equivalent signed request binding — or otherwise constrain the recipient or channel. These are *not core continuation modes* and are *not needed for the N+1 model*, whose successor is unknown; they serve profiles that require additional presentation constraints. Profiles MAY define recipient- or channel-constrained continuations when the successor or presentation key is known in advance. Such profiles remain PIC-compatible but do not address the unknown-successor case that motivates the core N+1 model, and are outside the scope of this specification. 6.7. Transport Separation and Confidentiality The security model is independent of transport (Section 1): the guarantees rest on the signed continuity state, and an implementation MUST NOT rely on the channel to obtain them. Transport nonetheless matters for *confidentiality and attack surface*, exactly as it does for OAuth. A man-in-the-middle on an unprotected channel cannot forge a valid continuity state - the signatures or proofs prevent that - but it can read message contents, including the result of a command, and attempt interception. That is a transport problem, addressed by transport, not by PIC. PIC is carrier-agnostic: the same continuity state can run over HTTP, over messaging systems such as Apache Kafka, or over any other transport. For messaging in particular, channels SHOULD be Gallo Informational [Page 39] PIC Prover and Verifier July 2026 encrypted. A plain outsider who reads a continuity artifact cannot continue it without satisfying the selected profile's PoR and conformance requirements. In the open core (Section 2.3), the core does not restrict who continues; it pins the action and prevents authority expansion. Constraints on recipient or channel are profile-specific (Section 6.6). Encryption protects payload confidentiality and reduces the man-in-the-middle surface; it is not a source of the model's integrity. 6.8. Incremental Verification and Trusted Hops An incremental or history-limited profile validates only the continuity evidence it carries or references at the receiving hop, and relies on authenticated prior validation state for earlier positions. Global validity back to the root is then inductive under that profile's trust assumptions. This profile makes one explicit assumption: *the prior validation boundary is trusted according to the selected profile*. It can contain a single faulty hop when the next honest Verifier has the evidence needed to reject that hop. It does not, by itself, resist two or more consecutive colluding hops when the receiving Verifier lacks authenticated evidence of the earlier prefix. Cryptographic predecessor references do not close this gap by themselves. They prove linkage and order. They do not prove that omitted authority-state content did not expand. A deployment that must resist consecutive collusion MUST use a profile that independently authenticates the relevant prefix: full-history validation, trusted central validation, authenticated checkpoints, succinct proofs, or an equivalent profile-defined mechanism. 7. Deployment Models PIC runs the same model in different topologies. The trade-off is between three properties the lightweight profile cannot maximize at once: *decentralization*, *low per-hop cost*, and *resistance to consecutive colluding hops* (Section 6.8). A single faulty hop is contained in _every_ model (Section 1.1); deployment only decides how much — and on what — to spend to also resist collusion among compromised-but-authorized parties. Gallo Informational [Page 40] PIC Prover and Verifier July 2026 +=================+=========+=================+===================+ | Model | Central | Per-hop cost | Consecutive | | | party | | collusion | +=================+=========+=================+===================+ | Decentralized, | none | profile-defined | not resisted | | history-limited | | | without | | | | | authenticated | | | | | prefix evidence | +-----------------+---------+-----------------+-------------------+ | Decentralized, | none | O(n) or | resisted | | full-history | | profile-defined | | +-----------------+---------+-----------------+-------------------+ | Central | yes | profile-defined | resisted under | | validator / | | | central-validator | | checkpoint | | | assumptions | | issuer | | | | +-----------------+---------+-----------------+-------------------+ | Succinct proof | none | O(1) verify | resisted | | (e.g. SNARK) | | | | +-----------------+---------+-----------------+-------------------+ Table 3 * *Decentralized, history-limited.* Each hop verifies the evidence available under the selected profile. It can be lightweight, but does not resist consecutive collusion unless the profile supplies authenticated prefix evidence. * *Decentralized, full-history.* The Verifier independently validates the relevant prefix. No central party is required, but size and validation cost grow with the represented history unless the profile defines compaction. * *Central validator or checkpoint issuer.* A trusted service validates advancements, maintains or authenticates validation state, or issues checkpoints. This can resist collusion under the central-validator assumptions, at the cost of a trust and availability dependency. * *Succinct proof.* A succinct proof — for example a SNARK or accumulator — proves non-expansion over the whole prefix (Section 5.3): decentralized, O(1) to verify, and collusion- resistant, all at once — at the cost of proof-generation complexity and a heavier cryptographic profile. Stated plainly: *to resist collusion among compromised-but-authorized hops while keeping bounded forwarding and no advanced cryptography, use a central or federated validator, or another profile-defined Gallo Informational [Page 41] PIC Prover and Verifier July 2026 authenticated-prefix mechanism.* Fully decentralized and lightweight means trusting the prior validation boundary according to the selected profile. 8. Zero Trust PIC is zero-trust in a precise, checkable sense, not as a label. Each property below is a concrete consequence of the model, not an aspiration. * *No implicit trust from network location.* Authorization comes from the signed continuity state, never from where a request originates. A caller inside the perimeter has exactly the authority its lineage carries, and no more (Section 6.7). * *Every hop is verified, never assumed.* No step is trusted because a previous one was: the Verifier re-checks the transition it holds — signature, predecessor link, freshness, profile-required evidence and conformance, non-expansion, time, and profile- required request/execution binding (Section 3.3) — and never assumes the Prover already did. The full-chain profile re-checks _every_ hop; the incremental profile re-checks the immediate transition and trusts prior verifiers inductively (Section 6.8). * *Least privilege by construction.* Authority only attenuates; each hop carries or materializes the smallest context it needs and can never regain what an ancestor dropped (Section 2.4). A privilege absent from the origin cannot appear anywhere downstream. * *Assume breach, contain it.* A buggy or compromised executor can act arbitrarily in its own step, but it cannot propagate an invalid authority state as a valid continuation (Section 1.1). The blast radius is one hop, not the chain. * *Per-request, contextual decisions.* Each continuation is authorized against the context that caused it, with freshness (Section 6.1) and time bounds (Section 6.3) making the decision specific to this request rather than a standing grant. * *Identity is not authority.* Authenticating who acts does not by itself grant continuation; the authority exercised must be a valid continuation of the lineage (Section 1.2). Compromising an identity does not confer authority the lineage never delegated to it. These hold against a single faulty hop when the selected profile gives the receiving Verifier the evidence needed to reject that hop. The properties that quantify over the whole continuity prefix hold Gallo Informational [Page 42] PIC Prover and Verifier July 2026 absolutely only when the relevant prefix is independently authenticated: full-history validation, trusted central validation, authenticated checkpoints, succinct proofs, or an equivalent profile- defined mechanism. The result is not "trust nothing" as a slogan but a model where trust is earned per hop, verified explicitly, and bounded by construction. 9. Contributors The editors and contributors of this document are listed in the *document header* above. Listing is governed by Appendix B.7 of the PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md). 10. Acknowledgement The *Provenance Identity Continuity (PIC) Model* — the theoretical framework this specification expresses in normative form — was created by *Nicola Gallo*. It first appeared on Zenodo on 1 December 2025 and is developed in full in the Proof-of-Continuity paper: * Gallo, N. (2025). _PIC Model — Provenance Identity Continuity for Distributed Execution Systems_. Zenodo. zenodo.org/ records/17777421 (https://zenodo.org/records/17777421) (DOI: 10.5281/zenodo.17777421). * Gallo, N. (2026). _Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents_. Zenodo. zenodo.org/records/21285112 (https://zenodo.org/ records/21285112) (DOI: 10.5281/zenodo.21285112). Authorship of the PIC Model remains with Nicola Gallo; the PIC specifications are published and maintained by *Nitro Agility S.r.l.* as Specification Steward. Any work that references, implements, or claims conformance with PIC must preserve this attribution, distinguishing the *PIC Model* (author: Nicola Gallo) from the *PIC Specifications* (steward: Nitro Agility S.r.l.), as required by the *PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (Appendix B, Attribution; Appendix D, Acknowledgements), which are incorporated into this specification by reference. 11. Legal Notices The appendices governing: * *A.* Use of Automated Language Assistance, Gallo Informational [Page 43] PIC Prover and Verifier July 2026 * *B.* Authorship, Stewardship, Attribution, and Derivative Works, * *C.* Disclaimer and Limitation of Liability, * *D.* Acknowledgements, are maintained in a single canonical document, the *PIC Legal Appendices (https://github.com/pic-protocol/pic- spec/blob/main/draft/0.2/pic-legal.md)* (draft/0.2/pic-legal.md), and are *incorporated into this specification by reference* as if fully set forth herein. In case of conflict between this document and the PIC Legal Appendices, the PIC Legal Appendices prevail for legal, governance, licensing, and attribution matters. This specification is subordinate to the PIC Specification (https://github.com/pic-protocol/pic-spec/blob/main/draft/0.2/pic- spec.md), which defines the normative semantics of the PIC Model and is the entry point of the specification set. This document does not introduce new conceptual authority, invariants, or authorship claims beyond those defined in the PIC Legal Appendices. 12. References 12.1. Normative References * [3] Bradner, S. (1997). _Key words for use in RFCs to Indicate Requirement Levels_. BCP 14, RFC 2119. rfc-editor.org/rfc/rfc2119 (https://www.rfc-editor.org/rfc/rfc2119) * [4] Leiba, B. (2017). _Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words_. BCP 14, RFC 8174. rfc-editor.org/rfc/rfc8174 (https://www.rfc-editor.org/rfc/rfc8174) * [7] Jones, M., Nadalin, A., Campbell, B., Bradley, J., & Mortimore, C. (2020). _OAuth 2.0 Token Exchange_. RFC 8693. rfc- editor.org/rfc/rfc8693 (https://www.rfc-editor.org/rfc/rfc8693) * [8] Jones, M., Bradley, J., & Sakimura, N. (2015). _JSON Web Token (JWT)_. RFC 7519. rfc-editor.org/rfc/rfc7519 (https://www.rfc- editor.org/rfc/rfc7519) * [9] Jones, M., Bradley, J., & Sakimura, N. (2015). _JSON Web Signature (JWS)_. RFC 7515. rfc-editor.org/rfc/rfc7515 (https://www.rfc-editor.org/rfc/rfc7515) Gallo Informational [Page 44] PIC Prover and Verifier July 2026 * [10] Bormann, C., & Hoffman, P. (2020). _Concise Binary Object Representation (CBOR)_. STD 94, RFC 8949. rfc-editor.org/rfc/ rfc8949 (https://www.rfc-editor.org/rfc/rfc8949) * [11] Schaad, J. (2022). _CBOR Object Signing and Encryption (COSE): Structures and Process_. STD 96, RFC 9052. rfc- editor.org/rfc/rfc9052 (https://www.rfc-editor.org/rfc/rfc9052) * [12] Fett, D., Yasuda, K., & Campbell, B. (2025). _Selective Disclosure for JSON Web Tokens_. RFC 9901. rfc-editor.org/rfc/ rfc9901 (https://www.rfc-editor.org/rfc/rfc9901) 12.2. Informative References * [1] Gallo, N. (2026). _Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents_. arXiv:2607.08906 [cs.CR]. arxiv.org/abs/2607.08906 (https://arxiv.org/abs/2607.08906) * [2] Gallo, N. (2026). _PIC Lean Verification_. Lean 4 formalization of the definitions and theorems of [1]. github.com/ngallo/pic-model/draft/0.1/pic-model-math/pic-lean (https://github.com/ngallo/pic-model/tree/main/draft/0.1/pic- model-math/pic-lean) * [5] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M. B., & Waite, D. (2023). _OAuth 2.0 Demonstrating Proof of Possession (DPoP)_. RFC 9449. rfc-editor.org/rfc/rfc9449 (https://www.rfc-editor.org/rfc/rfc9449) * [6] Backman, A., Richer, J., & Sporny, M. (2024). _HTTP Message Signatures_. RFC 9421. rfc-editor.org/rfc/rfc9421 (https://www.rfc-editor.org/rfc/rfc9421) Author's Address Nicola Gallo Nitro Agility S.r.l. Email: nicola.gallo@nitroagility.com Gallo Informational [Page 45]