The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity

1.1. Terminology and Definitions

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Agent

An autonomous software entity that performs tasks on behalf of a user or system.¶

Attester

The agent component responsible for generating cryptographic attestations about its state or actions.¶

Verifier

A system that validates cryptographic attestations received from Attesters without accessing underlying sensitive data.¶

Relying Party

A system that consumes attestation results to make authorization decisions.¶

PTV Edge Proxy

A trusted gateway that performs attestation on behalf of constrained devices lacking hardware roots of trust.¶

Nonce

A cryptographically random value used to prevent replay attacks.¶

Triage Band

A risk classification (ROUTINE, ZK_PROOF, BFT) that determines the attestation mechanism. Valid values are 0 (ROUTINE), 1 (ZK_PROOF), or 2 (BFT).¶

Governance Pack

A set of policies and compliance rules applied during attestation.¶

Proof

A zero-knowledge proof attesting to agent state.¶

Sovereign Bound Metadata

Jurisdiction and data residency metadata embedded in attestation chains that cannot be removed without invalidating the attestation. The corresponding envelope field is sovereign_bound, which contains the subfields jurisdiction, data_residency, and compliance.¶

Hardware Root of Trust

A tamper-resistant chip (TPM 2.0 or Secure Enclave) providing cryptographic evidence that software has not been altered since last attestation.¶

2.1. Identity Binding Integrity

Identity binding integrity asks: "Is this the agent that was enrolled, and is the signer of this attestation trusted to hold the corresponding key?"¶

PTV addresses this class of threats by:¶

• binding attestation evidence to a hardware root of trust (e.g., TPM AK),¶
• using nonce-based freshness to prevent replay, and¶
• allowing policy-aware verification of configuration state.¶

This corresponds to cryptographic identity continuity in the sense of the RATS Architecture [RFC9334]. A relying party that consumes a PTV attestation MAY treat it as an assertion about identity binding integrity only, unless additional mechanisms are in place.¶

2.2. Behavioral Continuity (Out of Scope for -01)

Behavioral continuity asks: "Is the enrolled agent still behaving within its attested envelope after context changes?"¶

This version of PTV does not fully address this requirement class. In particular, PTV does not detect or mitigate:¶

• behavioral drift after context compression or summarization,¶
• model weight replacement or fine-tuning after enrollment, and¶
• runtime drift from adversarial prompt injection or accumulated state corruption.¶

A valid PTV attestation on a behaviorally-drifted agent is therefore a false signal of behavioral identity continuity. For high-stakes use cases such as clinical decision support systems (CDSS) and ICS/OT, relying parties SHOULD treat behavioral continuity as a separate requirement. It can be partially addressed by combining PTV freshness with delegation provenance (e.g., HDP) and execution outcome verification (e.g., SCITT receipts). See Section 6.¶

2.3. Exercise-time Freshness Requirement

For high-stakes deployments, relying parties SHOULD be able to demand fresh attestation at exercise time (per authorization decision), via an EAT nonce challenge or a PTV challenge-response, rather than relying solely on a credential issued at enrollment time.¶

3.1. Protocol Overview

The PTV protocol operates through three phases:¶

   Agent                    Federation Hub                   Verifier
    |                           |                                |
    |--[1] PROVE---------------|                                |
    |  - Generate proof         |                                |
    |  - Hash: Model+Metadata   |                                |
    |                           |                                |
    |                           |--[2] TRANSFORM--------------->|
    |                           |  - Forward Proof Only         |
    |                           |                              |
    |                           |<-[3] VERIFY-------------------|
    |                           |  - Validate Proof             |
    |                           |  - No Raw Data Exposed        |

The three phases are as follows:¶

• PROVE: The agent generates a cryptographic proof locally that a task was executed correctly on an authorized model.¶
• TRANSFORM: Only the proof (not raw data) is transmitted to the central system.¶
• VERIFY: The system validates the proof without accessing sensitive inputs.¶

3.2. Roles

The PTV protocol defines four logical roles:¶

• Attester: The agent generating attestations. May be a direct TPM-bound agent or a constrained device using an Edge Proxy.¶
• Verifier: The system validating attestations.¶
• Relying Party: The system consuming attestation results for authorization decisions.¶
• Edge Proxy: An optional gateway performing attestation on behalf of constrained devices.¶

3.3. Deployment Models

PTV supports two deployment models:¶

• Direct Mode: The agent has a TPM 2.0 or TEE and generates proofs natively.¶
• Proxy-Assisted Mode: The agent is a constrained device (e.g., legacy PLC, sensor) without a TPM. The PTV Edge Proxy performs attestation on its behalf.¶

4.1. CBOR/CDDL Envelope

All PTV messages are encapsulated in a common envelope structure, serialized using CBOR [RFC8610].¶

The following CDDL rules define the envelope:¶

triage-band = 0..2

ptv-envelope = {
  ptv_version: tstr,
  msg_type: ptv-msg-type,
  nonce: bstr,
  ? attester_id: tstr,
  ? sovereign_bound: {
    jurisdiction: tstr,
    data_residency: tstr,
    compliance: [* tstr]
  },
  ? triage_band: triage-band,
  ? evidence: bstr,
  ? proof: bstr,
  ? policy: ptv-policy,
  ? result: ptv-result,
  ? behavior_fingerprint: bstr,
  ? timestamp: time,
  ? extensions: { * tstr => any }
}

ptv-msg-type = &(
  prove-req: 1,
  prove-resp: 2,
  transform-att: 3,
  verify-result: 4
)

ptv-policy = {
  ? audience: tstr,
  ? policy_uri: tstr,
  ? trust_domain: tstr,
  ? requirements: [* tstr]
}

ptv-result = &(
  success: 0,
  failure: 1,
  indeterminate: 2
)

The behavior_fingerprint field is OPTIONAL in this version. It is intended for deployments that adopt a SCITT-style execution receipt pattern. Its contents are opaque bytes with deployment-specific semantics; this version does not define normative processing rules. See Section 6.3 for discussion of related future work.¶

In PTV_PROVE_RESP and PTV_TRANSFORM_ATT, exactly one of evidence or proof MUST be present. A message that contains neither or both MUST be rejected by the verifier.¶

4.2. Message Types

PTV_PROVE_REQ = {
  ptv_version: "1.0",
  msg_type: 1,
  nonce: bstr,
  ? policy: ptv-policy
}

PTV_PROVE_RESP = {
  ptv_version: "1.0",
  msg_type: 2,
  nonce: bstr,
  attester_id: tstr,
  sovereign_bound: {
    jurisdiction: tstr,
    data_residency: tstr,
    compliance: [* tstr]
  },
  triage_band: triage-band,
  (evidence: bstr // ROUTINE triage
   // OR
   proof: bstr),   // ZK_PROOF triage
  ? behavior_fingerprint: bstr,
  timestamp: time
}

PTV_TRANSFORM_ATT = {
  ptv_version: "1.0",
  msg_type: 3,
  nonce: bstr,
  attester_id: tstr,
  sovereign_bound: {
    jurisdiction: tstr,
    data_residency: tstr,
    compliance: [* tstr]
  },
  triage_band: triage-band,
  (evidence: bstr // ROUTINE triage
   // OR
   proof: bstr),   // ZK_PROOF triage
  timestamp: time
}

PTV_VERIFY_RESULT = {
  ptv_version: "1.0",
  msg_type: 4,
  nonce: bstr,
  result: ptv-result,
  ? reason: tstr,
  ? audit_id: tstr,
  timestamp: time
}

4.3. Error Code Registry

The following error codes are defined for PTV attestation failures:¶

4.4. Performance Characteristics (Informative)

Note: The following figures are preliminary observations from a prototype implementation. They are provided for illustration only and are not normative requirements of the protocol.¶

5.1. Freshness and Replay

All PTV attestations MUST include a nonce provided by the relying party or verifier. The nonce MUST be cryptographically random (see [RFC4086]) and MUST NOT be reused across attestation sessions. Timestamps SHOULD be included and checked against a deployment-specific freshness window (RECOMMENDED: less than or equal to 300 seconds).¶

5.2. Zero-Knowledge Proof Mechanism

PTV is designed to be compatible with zero-knowledge proof systems but does not mandate a specific construction.¶

The predicate being proven MUST be specified, for example: "the hash of the agent configuration matches an enrolled value".¶

The zero-egress property of ZK-proofs aligns with Privacy by Design principles. Deployers SHOULD assess compliance with applicable regulations; this protocol is designed to facilitate such assessments but does not constitute legal certification.¶

5.3. Identity Misbinding

Attestations SHOULD be bound to the specific agent instance using a hardware root of trust (TPM 2.0 or Secure Enclave). Software-only attestations are NOT RECOMMENDED for high-assurance deployments.¶

5.4. Denial of Service

Verifiers SHOULD implement rate limiting and proof caching to mitigate DoS attacks.¶

6.1. EAT

When Entity Attestation Tokens (EAT, [RFC9711]) are present, PTV evidence and proofs SHOULD map to EAT claims such as eat_nonce, swname, and swversion. PTV evidence/proofs are also intended to be usable within SEAT/ExPAT-style exported attestation mechanisms. A future revision of this document may define a concrete mapping.¶

6.2. Layering and Composition

PTV is designed to compose with complementary protocols that address different parts of the agentic trust chain. Specifically:¶

• PTV provides attested agent identity and model/policy binding at exercise time (the "who and what is running" layer),¶
• The Human Delegation Provenance Protocol (HDP) [HDP] establishes signed delegation provenance anchored to a human principal (the "who authorized what" layer), and¶
• SCITT-based execution receipts or Execution Outcome Verification (EOV) provide evidence of what the agent actually produced (the "what was done" layer).¶

A natural composition point is for an EOV receipt to reference a hash of an HDP delegation record as its delegation token, rather than duplicating the full provenance chain. Future revisions of this document may describe concrete mappings once the HDP and EOV models stabilize.¶

6.3. SCITT and Execution Receipts

PTV is intended to compose with SCITT as follows:¶

• PTV/SEAT provide attested agent identity and state at exercise time, and¶
• SCITT COSE_Sign1 statements carry execution receipts for actions with external effects.¶

Three open standardization gaps remain, treated as future work:¶

1. A registered COSE header label for the behavioral fingerprint.¶
2. A standardized format for behavior probes / fingerprints.¶
3. A live transparency service for cross-domain execution logs.¶

6.4. Execution Outcome Verification

Execution outcome verification is treated as a separate concern from attestation. This version assumes that execution receipts, where needed, are carried by SCITT or a similar transparency mechanism.¶

Delegation provenance protocols (for example HDP [HDP]) and execution-outcome attestation patterns are complementary to PTV and out of scope for this version.¶