ProofID 101

A Proof Protocol specification

Ownership and Attribution Notice

This specification is authored by Craig Thomas Ellrod and is published as part of Proof Protocol. Copyright (c) 2026 Craig Thomas Ellrod.

Any use, implementation, derivative, citation, or incorporation of this specification, in whole or in part, MUST attribute Craig Thomas Ellrod and Proof Protocol. This requirement applies to standards bodies, working groups, consortia, and commercial implementations.

This specification is licensed under the Proof Protocol License 1.1 (see LICENSE.md); text CC BY 4.0 under Part A, which grants no patent rights. Original inventor: Craig Thomas Ellrod (ORCID 0009-0004-1058-7666).

Patents. Patent terms are in PATENT-SCHEDULE.md. Claims not listed there are reserved by Craig Thomas Ellrod. Licensing: 1proofprotocol@gmail.com.

This specification is related to the Proof Economy Prior Art Declaration, DOI 10.5281/zenodo.21379780.

Abstract

ProofID 101 gives everything in a run an identity: the arena, every interface, the ingress and egress points, the traffic pipe, every target, every agent, every sensor, and every party that signs a record. It states who owns each identity, where its keys are kept, how it is accessed, what it is authorized to do, and which fields every record pulls and pushes so that a proof names exactly what was tested, by whom, and through what.

One rule carries the design. Testers sign; subjects are fingerprinted. Everything doing the testing holds a key and signs what it emits. Everything under test is identified by a fingerprint captured independently, and holds no key from the run. The whole arena can be authenticated through one Arena Identity, while the parties that must stay independent of the arena keep roots of their own.

Introduction: Why This Specification Exists

The problem this family of specifications solves

Nobody can price security risk, because nobody can measure security efficacy. Every control, whether bought, built, or adopted, is described by the party that made it: a datasheet, a demo, a Provider-funded report, a design document, a dashboard of alerts. Implementors choose controls on those descriptions. Insurers underwrite on questionnaires that ask whether controls exist, not whether they work. Regulators supervise against attestations. Each of them is relying on the word of someone with a stake in the answer, and none of them has proof of what a control actually does when an attack arrives.

Agentic AI makes the gap wider and more expensive. An agent acts inside the system with legitimate credentials, decides its next step from text it has just read, and can be persuaded to do what its owner never authorized. The losses it can cause are new, and the controls sold to contain it have no track record. When risk cannot be measured, it is excluded, restricted, or priced as if every control were equally good, which punishes the controls that work and rewards the ones that only claim to.

The Proof Protocol specifications replace description with proof. PP-SPEC-077 measures what a security control did to committed test traffic. PP-SPEC-078 measures whether an agent containment control stopped an agent that tried to break its policy. PP-SPEC-079 makes those measurements independent of whoever built the control, and comparable across controls of any origin. PP-SPEC-080 lets the parties who pay for risk, insurers, regulators, and Implementors, state in advance what proof they will accept. Together they produce records that a person or a machine can verify without trusting the party the record is about.

This specification's part: naming, exactly and verifiably, every thing and every party a record is about or was made by.

Why this specification

A proof that does not bind what was tested can be moved to something that was not. Prove product X, ship product Y, and point at the proof. A record whose emitter cannot be authenticated can be written by anyone. An attack signal whose source cannot be identified is self-attested. An agent whose authority was never stated cannot be shown to have exceeded it.

The other specifications in this family already carry pieces of identity: the Holder (077 21.3), DUT, CUT, SUT, and Pigtail Fingerprints (077 15.2), Component Fingerprints and the Interface Manifest (077 18.1), signing keys under IP-10, the AUT Fingerprint and Declared Policy (078), and Party Sets for reproof (081). None of them says, for every component, who owns its identity, where its key lives, how others reach it, or what it is allowed to do. This specification does, in one model that covers the whole arena.

What this specification cannot do

Identity answers who and what, not whether. A perfectly identified control can still fail, and a perfectly identified agent can still break its policy. Identity makes the proof about the right thing; the proof itself still comes from PP-SPEC-077 and PP-SPEC-078.

An identity also proves only that a key signed. It does not prove that the party holding the key told the truth. That is what independent witnessing (PP-SPEC-077 Section 10) and reproof (PP-SPEC-081) are for.

1. Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174.

Terms defined in PP-SPEC-077 Section 2 and PP-SPEC-078 Section 2 have the same meaning here.

2. Terminology

• Identity: The verifiable name of one thing or party in a run, recorded as an Identity Record.
• Identity Record: The registered record that defines an Identity: its kind, Owner, public key or fingerprint, scope, parent, network identifiers, and lifetime (Section 12).
• Owner: The party that controls an Identity: for a keyed Identity, the party that holds its private key; for a fingerprinted Identity, the party that captured the fingerprint.
• Keyed Identity: An Identity that holds a private key and signs what it emits. Every tester has one.
• Fingerprinted Identity: An Identity defined by a fingerprint captured independently, with no key issued by the run. Every subject has one.
• Root Identity: A Keyed Identity that certifies other Identities and is certified by none in the run.
• Arena Identity: The Root Identity of an arena instance, held by the Arena Operator, that certifies every component the Arena Operator runs (Section 6).
• Independent Root: A Root Identity held by a party that must be independent of the Arena Operator: the Witness Operator, the Registry, the Time Anchor, every Party Set of a reproof, and any other party that must be independent of the Arena Operator (Section 6.3).
• Component Identity: A Keyed or Fingerprinted Identity certified by a Root Identity.
• Subject: Anything a record is about: the SUT, DUT, CUT, or AUT.
• Scope: What an Identity is authorized to do in a run (Section 10).
• Delegated Credential: A credential minted for a run and given to an AUT so it can act, with a Scope bound to the Declared Policy (10.4).
• Identity Manifest: The registered list of every Identity in a run, assembled before release (Section 13).
• Arena Operator: The party that builds, runs, and tears down an arena instance.

3. Relationship to Other Specifications

3.1. A run under PP-SPEC-077, PP-SPEC-078, PP-SPEC-079, or PP-SPEC-081 that adopts this specification applies it in addition. Nothing here relaxes any of them.

3.2. The Identity Manifest (Section 13) extends the Interface Manifest of 077 18.1.3. Every Integration Point named there is occupied by an Identity defined here.

3.3. Fingerprints are captured as PP-SPEC-077 Section 15.2 requires. This specification makes each fingerprint the definition of a Fingerprinted Identity.

3.4. Key custody is 077 IP-10. This specification states where keys may and may not be kept (Section 8).

3.5. The Registry is PP-SPEC-004. Issuer identity for ProofStamp is governed by PP-SPEC-009, which this specification does not change.

4. Principles

4.1. Everything has an identity. Every component, party, interface, path, and Subject that a record is made by, passes through, or is about MUST have an Identity in the Identity Manifest.

4.2. Testers sign. Every Identity that emits a record MUST be a Keyed Identity and MUST sign what it emits. A record whose emitter cannot be authenticated is not a record.

4.3. Subjects are fingerprinted. A DUT, CUT, SUT, or AUT MUST be a Fingerprinted Identity. It MUST NOT be issued a signing key by the run, because it MUST NOT take part in producing its own proof (077 18.3.3, 078 16.3.3). Its fingerprint is captured independently (077 15.2.4).

4.4. Nothing vouches for its own independence. A party that must be independent of another MUST NOT hold an Identity certified by that other party's root.

4.5. Identity is not authority. An Identity authenticates. Its Scope authorizes. An authenticated record of a kind outside its emitter's Scope is invalid (Section 10).

4.6. Never reused. An Identity belongs to one arena instance or one run. Keys are minted for it, and an Identity Record, once revoked, is never reactivated.

5. What Has an Identity

5.1. A kind not in this table MUST be declared in the Identity Manifest with its Owner, its certifier, and whether it is keyed or fingerprinted, and MUST use an x- prefix (077 17.10).

5.2. Network identifiers (address, hostname, MAC, port) identify an interface; they do not authenticate it. Authentication is by key (Section 9).

6. The Arena as One Identity

6.1. One root. Every arena instance MUST have exactly one Arena Identity. Every component the Arena Operator runs in that instance MUST be certified by it, directly or through a chain of Component Identities. A verifier that trusts the registered Arena Identity can authenticate every such component without any other trust.

6.2. Born with the arena. The Arena Identity MUST be minted when the arena instance is created, and its Identity Record MUST be registered before the first release (077 9.6), bound to a Time Anchor pulse.

6.3. Independent roots stay outside. The Witness, the Registry, the Time Anchor, and every Party Set of a reproof (081 Section 4) MUST hold Independent Roots. They MUST NOT be certified by the Arena Identity, even when the Arena Operator installs or hosts them. A component installed in the arena but operated by an independent party is certified by that party's root.

6.4. Subjects are not certified. No Root Identity certifies a Subject. A Subject's Identity Record carries its fingerprint and the Identity of the party that captured it.

6.5. Interim. Where the Arena Operator also operates the Witness, the Witness MAY be certified by the Arena Identity, and the run MUST state that its Witness is not independent of the arena.

7. Ownership

7.1. The Owner of a Keyed Identity is the party that holds its private key, and MUST be the Operator of the component: the party that runs it and can change it. The Owner of a Fingerprinted Identity is the party that captured the fingerprint.

7.2. Every Identity Record MUST name its Owner, by a stable identifier and the Owner's own Root Identity.

7.3. Ownership MUST NOT change during a run. A component that changes Owner is a new Identity, and the change is drift (077 15.1).

7.4. The Agent Provider owns the AUT's own credentials outside the run. Inside the run, the AUT acts only with Delegated Credentials (10.4), which are owned by the party that minted them.

8. Storage

8.1. Private keys. Private keys MUST be held under 077 IP-10 custody (a hardware module, a key management service, or an equivalent signing service) outside the environment under test. A private key MUST NOT be stored on any disk, image, snapshot, or template of the environment under test.

8.2. Why outside. A key inside the environment is destroyed or leaked at teardown, and an image cloned with a key inside it lets the clone sign as the original. Keys outside the environment survive teardown, and nothing can sign as the arena after its Identity is revoked.

8.3. Signing. Components sign by calling their Owner's signing service. Private keys MUST NOT be exported to components.

8.4. Public records. Every Identity Record and every revocation MUST be registered in the Registry (PP-SPEC-004) and retained for as long as any record that names the Identity is retained.

8.5. Local cache. An arena MAY keep a read-only cache of the Identity Manifest and the public keys it needs. The Registry is authoritative.

9. Access and Authentication

9.1. Public part. The public part of every Identity Record is readable from the Registry by any party, person or machine, by Identity ID.

9.2. Sensitive fields. Network identifiers and any field that reveals the Implementor's environment MAY be held at Disclosure Level holder_only (077 21.9). The Identity Record then carries a digest of those fields in their place, so the record can still be verified.

9.3. Private part. Only the Owner's signing service uses a private key.

9.4. Every record names its emitter. Every record in this family that adopts this specification MUST carry emitter, the Identity ID of the Keyed Identity that emitted it, and MUST be signed by that Identity's key.

9.5. Mutual authentication. Components that exchange records or traffic for the run MUST authenticate each other with their Keyed Identities before exchanging anything that a record depends on. The transport is not specified (077 18.1.7).

9.6. Verification. A verifier MUST be able to authenticate any record from the record, the Identity Records it names, and the Registry, with no access to the Owner.

10. Authorization (Scope)

10.1. Every Identity Record MUST state a Scope: the Integration Points (077 18.2, 078 16.2) the Identity occupies and the record kinds it may emit.

10.2. A record of a kind outside its emitter's Scope is invalid and MUST be recorded as a finding of kind scope_violation. An Ingress Observer cannot emit an Outcome; a Release Driver cannot emit a verdict; a Sensor cannot emit a rate.

10.3. Scope is declared before release and MUST NOT be widened during a run.

10.4. Agents. An AUT acts with Delegated Credentials minted for the run by the Policy Provider (078 IP-J1) or the Twin and Decoy Provider (078 IP-J6). Each Delegated Credential's Scope MUST be bound to the hash of the Declared Policy (078 Section 5), MUST be recorded in the Identity Manifest by digest, and MUST be revoked at teardown (078 14.2). An action the AUT takes with a credential outside its Scope is an offense under PP-SPEC-078 and evidence of it.

10.5. Operators. An operator Identity's Scope lists the actions it may take in the run. Role-based access control inside a product is out of scope of this specification; only the actions that appear in records are.

11. Binding Identities to Records

11.1. Subjects. Every Unit of Proof, booking, result, and Capture Record MUST carry subject: the Identity ID of each Subject it is about, at the level it is attributed (077 2.2).

11.2. Asserted versus captured. A Subject's Identity Record MUST carry the captured fingerprint and MAY carry the Provider's or Agent Provider's asserted product, version, and configuration. A difference between the two MUST be recorded as a finding of kind identity_mismatch, and results are bound to the captured fingerprint only (077 15.2.2).

11.3. Attack source. Every release record MUST name the release_driver or attacker_agent Identity that released the canary, so that the attack signal is attributable and not self-attested.

11.4. Paths. Every Capture Record MUST name the ingress, egress, or interface Identity it was captured at, and every result MUST list the pipe Identities its canaries traveled.

11.5. The run. Every record MUST carry the Arena Identity ID of the arena instance it was produced in.

12. Identity Record

12.1. Every Identity Record conforms to schemas/identity-record.schema.json and carries at least these fields:

12.2. Identity ID. identity_id = SHA-256("IDN-1:record" || canonical_form), where canonical_form is the record in the canonical form of 077 21.2 with identity_id, status, and the registration fields of 077 21.1 removed. Status is excluded so that revoking an Identity does not change its ID.

13. Identity Manifest, and What Is Pulled and Pushed

13.1. Before release (pull). The Arena Operator MUST assemble the Identity Manifest: the Arena Identity and every Component Identity it certifies, minted for this instance; every Independent Root and the Identities it certifies, pulled from the Registry; and every Subject Identity, with fingerprints captured under 077 15.2. The manifest conforms to schemas/identity-manifest.schema.json, is registered with the commitment root (077 9.2), and each component pulls from it the public keys of the peers it must authenticate.

13.2. During the run (push). Every record names its emitter, its subject, its Capture Point Identity where it has one, and its arena (Sections 9 and 11).

13.3. At teardown (push). Before the environment is torn down, the Arena Operator MUST revoke the Arena Identity and every Component Identity it certified, and every Delegated Credential, and MUST register the revocations. Each Independent Root Owner decides the lifetime of its own Identities.

13.4. After the run. The final Identity Manifest root, with every Identity's final status, is carried in the run's result record. Revoked Identities stay in the Registry so that every record they signed stays verifiable.

14. Reproof

14.1. Every Assay under PP-SPEC-081 MUST run on new infrastructure with a new Arena Identity. No Keyed Identity of the Head Assay MAY appear in a Check Assay or an Umpire Assay, except the Registry and Time Anchor (081 4.2).

14.2. Subject Identities are compared by fingerprint, never by instance. An Instance Reproof requires equal SUT and DUT fingerprints captured independently (081 5.1, 5.2); it never requires, and MUST NOT accept, the same instance identifiers.

15. Lifecycle

15.1. Create. Before release, as in 13.1.

15.2. Rotate. Keys are rotated only between runs, or at once on suspected compromise. A rotation creates a new Identity; the old one is revoked.

15.3. Compromise. An Identity whose key is suspected compromised MUST be marked compromised at once. Records it signed after the last time it is known to have been secure are not records.

15.4. Revoke. At teardown, as in 13.3, and on any change of Owner (7.3).

16. Security Considerations

• Substitution: Proving one product and shipping another. Prevented by captured fingerprints bound into every result (11.1, 11.2).
• Key in the image: A cloned arena with its key inside can sign as the original. Prevented by 8.1.
• Self-vouching: An arena that certifies its own Witness makes it look independent. Prevented by 6.3; stated when it happens (6.5).
• Replay of old identities: Prevented by per-instance minting, revocation at teardown, and Time Anchor binding (6.2, 13.3).
• Spoofed network identifiers: An address is not an identity. Authentication is by key only (5.2, 9.5).
• Credential leakage beyond the run: Delegated Credentials are minted per run and revoked at teardown (10.4).
• Scope creep: A component that emits records outside its Scope is caught by 10.2.
• Privacy: Network identifiers can reveal an Implementor's environment. They may be held holder_only with a digest in the public record (9.2).

17. Humans and Machines

PP-SPEC-077 21.14 applies. A person and a machine applying Sections 9 to 11 to the same records MUST reach the same answer on whether each record is authentic, within Scope, and bound to the right Subject.

18. Authorship Disclosure

PP-SPEC-077 21.15 applies. This specification's disclosure is AI_DISCLOSURE.md and ai_disclosure.json.

19. Interpretation

Craig Thomas Ellrod, as maintainer of Proof Protocol, is responsible for the editorial text of this specification. Whether a run or record conforms is determined from its records against the normative text, and is not decided by the maintainer.

Revision History