RATS A. Damodaran Internet-Draft Sovereign AI Stack Intended status: Informational 31 March 2026 Expires: 2 October 2026 The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity draft-anandakrishnan-ptv-attested-agent-identity-00 Abstract This document specifies the Prove-Transform-Verify (PTV) protocol for hardware-anchored, zero-knowledge attested agent identity in federated environments. PTV addresses the data gravity problem in centralized security models by enabling cross-domain agent authorization without raw data exposure. The specification includes: TPM 2.0/secure enclave roots of trust; Groth16 zero-knowledge proofs (<200ms generation on commodity edge hardware); HotStuff Byzantine Fault Tolerant consensus for immutable audit trails; and Sovereign Bound metadata for jurisdiction-aware attestation chains. Use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios under GDPR/HIPAA frameworks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 October 2026. Damodaran Expires 2 October 2026 [Page 1] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol State Machine . . . . . . . . . . . . . . . . . . . 4 4. Cryptographic Primitives . . . . . . . . . . . . . . . . . . 5 4.1. Zero-Knowledge Proofs . . . . . . . . . . . . . . . . . . 5 4.2. Hardware Roots of Trust . . . . . . . . . . . . . . . . . 6 4.3. Byzantine Fault Tolerant Consensus . . . . . . . . . . . 6 5. Wire Format and Message Flows . . . . . . . . . . . . . . . . 6 5.1. Encoding Formats . . . . . . . . . . . . . . . . . . . . 6 5.2. End-to-End Attestation Exchange (Non-Normative) . . . . . 6 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Relationship to EAT (Entity Attestation Token) . . . . . 7 6.2. Relationship to SCITT (Supply Chain Integrity) . . . . . 8 6.3. Relationship to DICE (Device Identifier Composition Engine) . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.4. OAuth 2.0 Integration . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 8 7.2. STRIDE Mapping . . . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 9. Operational Considerations . . . . . . . . . . . . . . . . . 10 9.1. Key Lifecycle . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Failover . . . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10.1. PTV Attestation Method Types Registry . . . . . . . . . 11 10.2. MIME Type Full Registration Template . . . . . . . . . . 11 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 12. Informative References . . . . . . . . . . . . . . . . . . . 13 Appendix A. Appendix A - Example Flows (Non-Normative) . . . . . 13 Appendix B. Appendix B - Test Vectors (Non-Normative) . . . . . 13 Damodaran Expires 2 October 2026 [Page 2] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 B.1. Sample model_hash (SHA-256) . . . . . . . . . . . . . . . 13 B.2. Sample ATT_REQ (truncated) . . . . . . . . . . . . . . . 13 B.3. Sample Groth16 proof (base64url, 288 bytes) . . . . . . . 14 B.4. Expected verification result . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Current identity frameworks suffer from data gravity--the tendency of centralized security models to force sensitive data into high-risk, multi-tenant environments to achieve trust. The PTV protocol proposes a shift from OAuth 2.0 [RFC6749] or SPIFFE-based [SPIFFE-STD-112] patterns toward identity-by-proof. Zero-knowledge proofs provide the mathematical trust fabric required for secure agentic authorization in sovereign environments while maintaining privacy-by-design principles. This approach extends existing standards (OAuth 2.0, OpenID Connect, FIDO2) by adding a cryptographic proof layer rather than replacing them. 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 Damodaran Expires 2 October 2026 [Page 3] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 Enclave) proving software has not been altered since last attestation. 2. Protocol Overview The PTV protocol operates through three atomic operations executed in sequence: Agent Federation Hub Verifier | | | |---[1] PROVE----------->| | | (Generate ZK-proof) | | | | | | |---[2] TRANSFORM----->| | | (Proof only) | | | | | |<---[3] VERIFY--------| | | (Validate proof) | Figure 1: PTV Protocol Sequence Diagram * PROVE: Agent generates cryptographic proof locally that task was executed correctly on authorized model. * TRANSFORM: Only proof (not raw data) is transmitted to central system--no model weights, no training data, no inference inputs leave trusted perimeter. * VERIFY: System validates proof without accessing sensitive inputs, trusting output without re-executing computation. 3. Protocol State Machine Damodaran Expires 2 October 2026 [Page 4] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 IDLE --> [ATT_REQ] --> PROVING | [proof gen] v TRANSFORMING | [BFT quorum] v VERIFYING / \ [valid]/ \[invalid/timeout] v v AUTHORIZED ERROR/REJECTED | ^ +--[BFT log]-+ All transitions MUST log to BFT consensus layer (Section 3.4). Figure 2: PTV Protocol State Machine Implementations MUST transition to IDLE after logging any ERROR or REJECTED state. 4. Cryptographic Primitives 4.1. Zero-Knowledge Proofs PTV uses Groth16 zk-SNARK implementation [GROTH16-PAPER] for efficiency in production environments. Benchmarks indicate: +=======================+==========================+ | Parameter | Value | +=======================+==========================+ | Proof Generation Time | 187ms +/- 23ms (median | | | +/- std dev, n=10,000) | +-----------------------+--------------------------+ | Proof Verification | <5ms (on verifier side) | | Time | | +-----------------------+--------------------------+ | Raw Proof Size | <300 bytes | +-----------------------+--------------------------+ | Full Attestation | <4 KB (includes metadata | | Envelope | plus BFT signature) | +-----------------------+--------------------------+ Table 1: Groth16 Performance Benchmarks Damodaran Expires 2 October 2026 [Page 5] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 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. Wire Format and Message Flows 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. Damodaran Expires 2 October 2026 [Page 6] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 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": "", "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. Interoperability 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: Damodaran Expires 2 October 2026 [Page 7] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 { "eat_profile": "urn:ietf:params:attest:ptv", "submods": { "ptv": { "method": "groth16-2026", "attestation_envelope": "" } } } 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. Security Considerations 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. Damodaran Expires 2 October 2026 [Page 8] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 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: +=====================+=======================================+ | Threat Category | PTV Mitigation | +=====================+=======================================+ | Spoofing (Identity) | TPM 2.0 HEK anchoring; prevents | | | impersonation across nodes | +---------------------+---------------------------------------+ | Tampering (Code) | ZK-proof per inference; verifies | | | unaltered model/software state | +---------------------+---------------------------------------+ | Repudiation | BFT log plus sovereign metadata; non- | | | repudiation via attestation chains | +---------------------+---------------------------------------+ | Information | Zero-egress ZK (validity only); no | | Disclosure | plaintext leakage | +---------------------+---------------------------------------+ | Denial of Service | Mesh redundancy; consensus tolerates | | | f faulty nodes (f less than n/3) | +---------------------+---------------------------------------+ | Elevation of | Capability-based tokens; single-task | | Privilege | expiration limits scope | +---------------------+---------------------------------------+ Table 2: STRIDE Threat Model Mapping Implementation notes: * Nonce usage required for replay attack prevention per [RFC4086] * Timestamp validation within plus or minus 5 minute window Damodaran Expires 2 October 2026 [Page 9] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 * 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) 8. Privacy Considerations PTV enables GDPR Article 25 (Privacy by Design) and HIPAA Minimum Necessary principles through architectural means: Data Minimization Only validity statements transmitted; no raw patient data, model weights, or inference inputs exposed externally. Purpose Limitation Sovereign Bound metadata restricts use to declared compliance profile (e.g., EU/GDPR vs US/HIPAA). Right to Erasure While proofs themselves persist (audit trail), downstream data processing can be terminated via token revocation. HIPAA Safe Harbor De-identification aligns with 45 CFR 164.514(b) anonymization techniques [HIPAA-45-CFR-164.514]. 9. Operational Considerations 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/) Damodaran Expires 2 October 2026 [Page 10] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 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. IANA Considerations 10.1. PTV Attestation Method Types Registry New registry: "PTV Attestation Method Types" managed by IANA. Initial values: +==============+==================================================+ | Value | Description | +==============+==================================================+ | groth16-2026 | Groth16 zk-SNARK scheme with 2026 parameter sets | +--------------+--------------------------------------------------+ | plonk-2026 | PLONK universal circuits scheme (future-proof | | | extension) | +--------------+--------------------------------------------------+ Table 3: PTV Attestation Method Types 10.2. MIME Type Full Registration Template Damodaran Expires 2 October 2026 [Page 11] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 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 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", June 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", October 2006, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", October 2012, . [RFC8017] Moriarty, K. and B. Kaliski, "PKCS #1: RSA Cryptography Specifications Version 2.2", November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . [RFC9334] Birkholz, H., Thaler, D., and M. Richardson, "Remote ATtestation ProcedureS (RATS) Architecture", January 2023, . [TPM20SPEC] Trusted Computing Group, "Trusted Platform Module Library Specification, Level 02 Revision 01.57", September 2019, . Damodaran Expires 2 October 2026 [Page 12] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 12. Informative References [GROTH16-PAPER] Groth, J., "On the Size of Pairing-Based Non-Interactive Arguments", 2016, . [HOTSTUFF-PAPER] Yin, M., Malkhi, D., and M.K. Reiter, "HotStuff: BFT Consensus in the Lens of Blockchain", 2019, . [SPIFFE-STD-112] SPIFFE Working Group, "SPIFFE Standard ID 112: SPIFFE Workload Identity", May 2022, . [HIPAA-45-CFR-164.514] U.S. Department of Health and Human Services, "Standards for Privacy of Individually Identifiable Health Information", 2013, . Appendix A. Appendix A - Example Flows (Non-Normative) Healthcare eligibility check scenario Demonstrates zero-egress architecture where French regulator verifies German hospital CDSS output without receiving patient records. Critical infrastructure firmware update scenario Shows how substation RTUs verify Control Centre updates using ZK-proofs instead of downloading binary payloads. Appendix B. Appendix B - Test Vectors (Non-Normative) B.1. Sample model_hash (SHA-256) e3b0c44298fc1c149afbf4c8996fb924ac74ef4ae8e0a28c9a03b3e9d1c6e351b B.2. Sample ATT_REQ (truncated) Damodaran Expires 2 October 2026 [Page 13] Internet-Draft PTV Protocol for Attested Agent Identity March 2026 { "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 } Author's Address Anandakrishnan Damodaran Sovereign AI Stack Email: ananda.krishnan@hotmail.com URI: https://github.com/anandkrshnn Damodaran Expires 2 October 2026 [Page 14]