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 [RFC2119] and [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.¶

Prover

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

Verifier

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

Federation Hub

A node in the PTV mesh that maintains BFT-consensus audit logs across multiple jurisdictions.¶

Sovereign Bound Metadata

Jurisdiction flags embedded in attestation chains that cannot be removed without invalidating the attestation.¶

Hardware Root of Trust

A tamper-resistant chip (TPM 2.0/Secure Enclave) proving software has not been altered since last attestation.¶

4.1. Zero-Knowledge Proofs

PTV uses Groth16 zk-SNARK implementation [GROTH16-PAPER] for efficiency in production environments. Benchmarks indicate:¶

4.2. Hardware Roots of Trust

Agents MUST anchor identities to TPM 2.0 (or equivalent Secure Enclave) using Hardware Endorsement Keys (HEK). [TPM20SPEC] defines the endorsement key specification.¶

• PCR Selection: 0 (Platform Config Register for boot integrity)¶
• AK Generation: HMAC-based AK wrapped by EK¶
• Endorsement Key Rotation: every 90 days (MUST)¶

4.3. Byzantine Fault Tolerant Consensus

PTV employs HotStuff-based BFT consensus at the Federation Hub layer. See [HOTSTUFF-PAPER] for protocol details. This ensures:¶

• Tolerance up to f faulty nodes where f less than floor((n-1)/3)¶
• Cross-jurisdictional audit integrity even if one cloud region compromised¶
• Immutable Reasoning Trace verifiable by other sovereign mesh nodes¶
• Sub-second finality (<500ms for f less than or equal to 2 faults)¶

5.1. Encoding Formats

Messages use JSON-LD encoding with @context validation. Binary components (ZK-proofs, signatures) are Base64URL-encoded per [RFC4648] for transport safety.¶

Media type registration recommended: application/ptv-attestation+json. See Section 11.2 for the full IANA registration template.¶

5.2. End-to-End Attestation Exchange (Non-Normative)

This subsection illustrates a complete PROVE–TRANSFORM–VERIFY exchange using JSON-LD encoding and the application/ptv-attestation+json media type carried in an OAuth 2.0 token request.¶

POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=patient.read
&ptv_attestation={
  "@context": "https://schemas.example.com/ptv/v1",
  "msg_type": "ATT_REQ",
  "version": "1.0",
  "request_id": "550e8400-e29b-41d4-a716-446655440000",
  "prover_id": "a3f1c8e5b9d2f7a4c6e8b1d3f5a7c9e2b4d6f8a1",
  "timestamp": 1743415200,
  "nonce": "ZGF0YV9leGFtcGxlX25vbmNl",
  "sovereign_bound": {
    "jurisdiction": "EU/DE",
    "region_code": "DE-BY",
    "compliance_profile": ["GDPR"]
  },
  "action_context": {
    "task_type": "eligibility_check",
    "cognitive_mandate": "validate_patient_data",
    "token_expiry": "2026-03-31T12:00:00Z"
  },
  "attestation_envelope": {
    "method": "groth16-2026",
    "proof": "<base64url-groth16-proof>",
    "model_hash": "e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b"
  }
}

The authorization server binds the issued access token to the supplied PTV attestation and enforces the declared sovereign_bound and action_context when processing subsequent API calls.¶

6.1. Relationship to EAT (Entity Attestation Token)

PTV attestation envelopes MAY be carried as EAT claims [RFC9334]. Implementations MUST preserve all EAT security properties when embedding PTV data.¶

For example, a PTV attestation envelope can be embedded as an EAT non-critical claim:¶

{
  "eat_profile": "urn:ietf:params:attest:ptv",
  "submods": {
    "ptv": {
      "method": "groth16-2026",
      "attestation_envelope": "<base64url-ptv-attestation>"
    }
  }
}

6.2. Relationship to SCITT (Supply Chain Integrity)

PTV BFT audit logs are SCITT-compatible transparency logs. PTV proofs MAY be submitted to SCITT registries for public verification.¶

A Federation Hub MAY publish each finalized attestation envelope as a SCITT transparency log entry, using the attestation hash as the statement digest and including sovereign_bound metadata as signed attributes.¶

6.3. Relationship to DICE (Device Identifier Composition Engine)

TPM 2.0 AK binding is compatible with DICE layer 0 identity. PTV inherits DICE chain-of-trust for hardware root establishment.¶

When DICE is present, the TPM Attestation Key used in PTV corresponds to the layer-0 device identity, and PTV proofs inherit the DICE chain-of-trust without additional changes to the wire format.¶

6.4. OAuth 2.0 Integration

The "ptv_attestation" parameter MAY be carried in [RFC6749] token requests to bind access tokens to attested agent identity.¶

Authorization servers receiving ptv_attestation parameters MUST validate the embedded attestation envelope before issuing an access token and MUST reject requests where the model_hash or sovereign_bound fields do not match local policy.¶

7.1. Threat Model

PTV assumes an honest-majority Federation Hub with at most f faulty nodes where f < floor((n-1)/3), as required by HotStuff-style BFT consensus.¶

Agent devices are assumed to have a correctly provisioned hardware root of trust (TPM 2.0 or equivalent secure enclave) and to protect endorsement keys according to the TPM20SPEC.¶

Network attackers are assumed capable of eavesdropping, replay, message tampering, and denial-of-service, but not of breaking the underlying cryptographic primitives or compromising all BFT nodes simultaneously.¶

Out-of-scope threats include physical compromise of all Federation Hubs in a jurisdiction and regulatory misuse of otherwise valid attestation data.¶

7.2. STRIDE Mapping

This protocol implements a threat model based on STRIDE categories mapped to ISO 14971 hazards for medical device integration:¶

Implementation notes:¶

• Nonce usage required for replay attack prevention per [RFC4086]¶
• Timestamp validation within plus or minus 5 minute window¶
• Key management must comply with [RFC8017] RSA padding standards or FIPS 140-2 validated libraries¶

Operational Security Notes:¶

• Always validate hardware root of trust before accepting attestation¶
• Implement rate limiting on proof verification endpoints (RECOMMENDED)¶
• Rotate BFT federation hub keys periodically (recommended: every 180 days)¶
• Log all attestation failures with timestamp for incident response¶
• Maintain backup verification keys for recovery scenarios¶
• Monitor latency SLA: p99.9 under 240ms (alert threshold)¶

9.1. Key Lifecycle

• TPM EK rotation: every 90 days (MUST)¶
• BFT node key rotation: every 180 days (SHOULD)¶
• Verification key publication: via HTTPS Well-Known URI (/well-known/ptv-keys/)¶

9.2. Monitoring

• Attestation failure rate SHOULD be logged per system metrics.¶
• Latency SLA: p99.9 under 240ms (alert threshold)¶
• BFT quorum health checks: every 60 seconds (MUST)¶

9.3. Failover

• Minimum 3 BFT nodes per jurisdiction (RECOMMENDED)¶
• Fallback: human override¶
• Recovery procedure: documented in incident response playbook¶

10.1. PTV Attestation Method Types Registry

New registry: "PTV Attestation Method Types" managed by IANA. Initial values:¶

10.2. MIME Type Full Registration Template

Type name:               application
Subtype name:            ptv-attestation+json
Required parameters:     version
Optional parameters:     jurisdiction
Encoding considerations: UTF-8
Security considerations: See Section 9
Interoperability:        See Section 8
Published specification: This document
Applications:            AI agent attestation systems
Fragment identifier:     None
Restrictions on usage:   None
Author:                  Anandakrishnan Damodaran
Change controller:       IETF

B.1. Sample model_hash (SHA-256)

e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b

B.2. Sample ATT_REQ (truncated)

{
"msg_type": "ATT_REQ",
"version": "1.0",
"request_id": "550e8400-e29b-41d4-a716-446655440000",
"prover_id": "a3f1c8e5b9d2f7a4c6e8b1d3f5a7c9e2b4d6f8a1",
"timestamp": 1743415200,
"nonce": "ZGF0YV9leGFtcGxlX25vbmNl",
"sovereign_bound": {
"jurisdiction": "EU/DE",
"region_code": "DE-BY"
}
}

B.3. Sample Groth16 proof (base64url, 288 bytes)

eyJhIjpbIjB4MWFlODg3OWJiN2ExNTQ4NjU4OTFhMWRjOGVlYmIwMGIyNTE5MTc2ND...

B.4. Expected verification result

{
"valid": true,
"jurisdiction": "EU",
"latency_ms": 187,
"model_hash_verified": true,
"sovereign_bound_ok": true
}