RATS A. Damodaran Internet-Draft Sovereign AI Stack Intended status: Experimental 29 September 2026 Expires: 2 April 2027 The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity draft-anandakrishnan-rats-ptv-agent-identity-01 Abstract This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV enables an agent to prove, at exercise time, that it is bound to an enrolled attestation key and an authorized configuration, without exposing model weights or inference inputs. PTV is a thin request/response profile over the RATS architecture (RFC 9334) and the Entity Attestation Token (RFC 9711). It does not replace workload identifiers such as SPIFFE or WIMSE. It does not attest behavioral continuity; behavioral continuity is a separate requirement class that relying parties need to treat as such. This revision is intended as Experimental. It defines a common CBOR/ CDDL message set, four message types, a COSE-based message protection rule, an informative EAT claim mapping, and a threat model that separates identity binding integrity from behavioral continuity. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-anandakrishnan-rats-ptv-agent- identity/. Discussion of this document takes place on the Remote ATtestation procedureS (RATS) Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Damodaran Expires 2 April 2027 [Page 1] Internet-Draft PTV Agent Identity September 2026 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 April 2027. 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. Relationship to WIMSE and SPIFFE . . . . . . . . . . . . 4 1.2. Changes from -00 . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Identity Binding Integrity . . . . . . . . . . . . . . . 6 3.2. Behavioral Continuity (Out of Scope) . . . . . . . . . . 7 3.3. Exercise-Time Freshness . . . . . . . . . . . . . . . . . 7 4. PTV Model and Roles . . . . . . . . . . . . . . . . . . . . . 7 4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 4.2. Nonce Issuance and Checking . . . . . . . . . . . . . . . 8 4.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Deployment Models . . . . . . . . . . . . . . . . . . . . 9 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. CBOR/CDDL Definitions . . . . . . . . . . . . . . . . . . 9 5.2. Mutual Exclusion of Evidence and Proof . . . . . . . . . 10 5.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 11 5.3.1. PTV_PROVE_REQ (Type 1) . . . . . . . . . . . . . . . 11 5.3.2. PTV_PROVE_RESP (Type 2) . . . . . . . . . . . . . . . 11 5.3.3. PTV_TRANSFORM_ATT (Type 3) . . . . . . . . . . . . . 12 Damodaran Expires 2 April 2027 [Page 2] Internet-Draft PTV Agent Identity September 2026 5.3.4. PTV_VERIFY_RESULT (Type 4) . . . . . . . . . . . . . 12 5.4. Message Authentication . . . . . . . . . . . . . . . . . 13 5.5. Error Code Registry . . . . . . . . . . . . . . . . . . . 13 6. Informative EAT Mapping . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.1. Freshness and Replay . . . . . . . . . . . . . . . . . . 15 7.2. Zero-Knowledge Proof Mechanism . . . . . . . . . . . . . 16 7.3. Identity Misbinding . . . . . . . . . . . . . . . . . . . 16 7.4. Self-Asserted Metadata . . . . . . . . . . . . . . . . . 16 7.5. Edge Proxy Trust . . . . . . . . . . . . . . . . . . . . 16 7.6. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 9. Interoperability and Future Work . . . . . . . . . . . . . . 17 9.1. Layering . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Open Items . . . . . . . . . . . . . . . . . . . . . . . 18 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Appendix A. Prototype Observations (Non-Normative) . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Appendix B. Examples (Non-Normative) . . . . . . . 21 B.1. PTV_PROVE_REQ . . . . . . . . . . . . . . . . . . . . . . 21 B.2. PTV_PROVE_RESP, ROUTINE band . . . . . . . . . . . . . . 21 B.3. PTV_PROVE_RESP, ZK_PROOF band . . . . . . . . . . . . . . 22 B.4. PTV_VERIFY_RESULT . . . . . . . . . . . . . . . . . . . . 22 B.5. Rejected message . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Current identity frameworks (OAuth 2.0, SPIFFE, WIMSE) establish workload identity but do not, by themselves, verify which model an agent is running or whether the running configuration matches what was enrolled. A compromised agent can therefore present valid credentials while executing unauthorized code or policy. PTV addresses the identity-binding gap: * bind the attestation to a hardware root of trust (TPM 2.0 Attestation Key [TPM2], or equivalent TEE attestation key); * require a verifier- or relying-party-issued nonce so that evidence is fresh at exercise time; Damodaran Expires 2 April 2027 [Page 3] Internet-Draft PTV Agent Identity September 2026 * carry either raw evidence (ROUTINE band) or a zero-knowledge proof of an enrolled predicate (ZK_PROOF band); * leave behavioral continuity, delegation provenance, and execution- outcome verification to complementary mechanisms. This document does not claim that a valid PTV attestation means the agent is still behaving inside its enrolled envelope after context compression, fine-tuning, or prompt injection. A relying party that needs that property MUST combine PTV with exercise-time re- attestation plus an execution-receipt mechanism (for example SCITT [RFC9943]). Example relying-party questions PTV can answer: * "Is the signer of this evidence the enrolled agent instance?" * "Does the attested software/configuration hash match the authorized set?" * "Was this evidence produced in response to this nonce?" Example questions PTV cannot answer alone: * "Did the agent follow the clinical protocol on this patient?" * "Who delegated this action?" * "What side effect did the agent actually cause?" 1.1. Relationship to WIMSE and SPIFFE When a WIMSE or SPIFFE identifier is present, that identifier names the workload. PTV evidence is additional appraisal input about the same workload. PTV does not mint a new identifier namespace. See [I-D.ietf-wimse-aims]. 1.2. Changes from -00 * Intended status changed from Standards Track to Experimental. * Behavioral-continuity non-claim moved into the Abstract. * Federation Hub removed from the protocol diagram; Transform is performed by the Attester or an Edge Proxy. * triage_band reduced to ROUTINE (0) and ZK_PROOF (1). BFT (2) and PTV_ERR_004 removed until a consensus mechanism is specified. Damodaran Expires 2 April 2027 [Page 4] Internet-Draft PTV Agent Identity September 2026 * sovereign_bound is OPTIONAL unless the policy object requires it. * CDDL rewritten: one map per message type, no duplicate keys, and evidence and proof are mutually exclusive via a CDDL group choice. The generic envelope is removed. * Message protection added: types 2 and 3 are COSE_Sign1 signed by the attestation key. * Nonce issuance and Verifier-side nonce checking specified. * Nonce size constrained to 16-64 bytes for compatibility with the EAT nonce claim. * Informative EAT claim mapping added and corrected. * Edge Proxy key-custody threats added to Security Considerations. * Trusted-setup, privacy, and self-asserted-metadata considerations added. * Prototype performance table moved to an appendix and aligned with the prototype repository. * Predicate for the ZK_PROOF band stated as a public-input list, without mandating a proof system. * SCITT reference corrected to RFC 9943. * Implementation Status section added. * Appendix B added with CBOR diagnostic-notation examples. 2. 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 that generates Evidence or a Proof about its identity-binding state. Corresponds to the Attester role in [RFC9334]. Damodaran Expires 2 April 2027 [Page 5] Internet-Draft PTV Agent Identity September 2026 Verifier: A system that appraises Evidence or a Proof without needing the Attester's inference inputs or model weights. Corresponds to the Verifier role in [RFC9334]. Relying Party: A system that consumes Attestation Results to make an authorization decision. Corresponds to the Relying Party role in [RFC9334]. Edge Proxy: An optional gateway that generates or forwards attestation on behalf of a constrained device that lacks a local hardware root of trust. The Edge Proxy is an Attester from the Verifier's point of view and MUST be treated as a distinct trust component. Nonce Issuer: The Relying Party or the Verifier, whichever generates the nonce for a session. See Section 4.2. Nonce: A cryptographically random value supplied by the Nonce Issuer to bind an attestation session and prevent replay. See [RFC4086]. Triage Band: The attestation mechanism selected for a session. This version defines 0 (ROUTINE: Evidence) and 1 (ZK_PROOF: Proof). Governance Pack / Policy: Optional constraints the Attester must satisfy, referenced by URI or carried inline. Proof: A zero-knowledge proof that a stated predicate holds over Attester-private inputs. The proof system is not mandated. Evidence: Attestation Evidence in the RATS sense [RFC9334], typically an EAT [RFC9711] or a TPM quote. Sovereign Bound Metadata: Optional jurisdiction, residency, and compliance labels carried in the message. They are integrity- protected by the message signature (Section 5.4) but are self- asserted unless covered by appraised Evidence. Hardware Root of Trust: A TPM 2.0, Secure Enclave, or equivalent component that can produce Evidence bound to an attestation key that never leaves the component. 3. Threat Model 3.1. Identity Binding Integrity Identity binding integrity asks: "Is this the enrolled agent instance, and is the signer trusted to hold the corresponding attestation key?" Damodaran Expires 2 April 2027 [Page 6] Internet-Draft PTV Agent Identity September 2026 PTV addresses this class by: * binding Evidence or Proof to a hardware attestation key through the message signature (Section 5.4); * using a session nonce for freshness; * allowing the Verifier to appraise configuration hashes against an endorsed reference value. A Relying Party MUST NOT treat a PTV result as evidence of anything beyond identity binding integrity unless additional mechanisms are in place. 3.2. Behavioral Continuity (Out of Scope) Behavioral continuity asks: "Is the enrolled agent still behaving within its attested envelope after context changes?" This version of PTV does not detect or mitigate: * behavioral drift after context compression or summarization; * model-weight replacement or fine-tuning after enrollment; * runtime drift from prompt injection or accumulated state corruption. A valid PTV attestation on a behaviorally drifted agent is a false signal of behavioral identity continuity. For high-stakes use (clinical decision support, ICS/OT), Relying Parties SHOULD treat behavioral continuity as a separate requirement and compose PTV with delegation provenance and execution receipts. See Section 9. 3.3. Exercise-Time Freshness For high-stakes deployments, Relying Parties SHOULD demand fresh attestation at exercise time (per authorization decision) via an EAT nonce challenge or a PTV_PROVE_REQ, rather than relying solely on a credential issued at enrollment. 4. PTV Model and Roles 4.1. Protocol Overview PTV has three phases. They are logical, not a new transport. Damodaran Expires 2 April 2027 [Page 7] Internet-Draft PTV Agent Identity September 2026 1. PROVE. The Attester produces Evidence or a Proof over the current configuration, bound to the challenge nonce and the hardware attestation key. 2. TRANSFORM. Only Evidence or Proof is forwarded. Inference inputs, model weights, and plant telemetry stay local. The forwarder is the Attester itself or an Edge Proxy. 3. VERIFY. The Verifier appraises the Evidence or Proof and returns a result to the Relying Party. Relying Party Attester / Edge Proxy Verifier | | | |-- nonce, policy (A) ---------------------------------->| |-- PTV_PROVE_REQ ------->| | | (nonce, policy) | | | |-- generate Evidence/Proof | | | | | |-- PTV_PROVE_RESP --------->| | | or PTV_TRANSFORM_ATT | | | (COSE_Sign1 by AK) | | | | |<--------- PTV_VERIFY_RESULT -------------------------| Figure 1: PTV message flow (A: nonce registration, see below) This flow is a profile of the Challenge/Response interaction model in [I-D.ietf-rats-reference-interaction-models]. 4.2. Nonce Issuance and Checking The Verifier can only judge freshness if it knows which nonce was issued for the session. One of the following two modes MUST be used: RP-issued: The Relying Party generates the nonce, sends it in PTV_PROVE_REQ, and also gives the Verifier the nonce (and the policy) for the session over an authenticated channel (step A in Figure 1). The Verifier MUST reject a response whose nonce does not match a registered, unconsumed session. Verifier-issued: The Verifier generates the nonce and hands it to the Relying Party, which places it in PTV_PROVE_REQ. The Verifier MUST record the nonce as outstanding and mark it consumed on first successful or failed appraisal. In both modes a nonce is single-use. A Verifier that cannot associate a received nonce with an issued session MUST return result failure with reason PTV_ERR_006. Damodaran Expires 2 April 2027 [Page 8] Internet-Draft PTV Agent Identity September 2026 4.3. Roles * Attester: produces PTV_PROVE_RESP. * Edge Proxy: optional; produces PTV_TRANSFORM_ATT on behalf of a constrained device and is itself an Attester. * Verifier: consumes RESP or TRANSFORM_ATT; produces PTV_VERIFY_RESULT. * Relying Party: issues PTV_PROVE_REQ and consumes PTV_VERIFY_RESULT. The Verifier and Relying Party MAY be co-located, in which case step A in Figure 1 is internal. 4.4. Deployment Models Direct Mode: The agent has a TPM 2.0 or TEE and produces Evidence or Proof locally. Proxy-Assisted Mode: A constrained device (legacy PLC, sensor) has no hardware root of trust. An Edge Proxy attests that it is mediating that device under an enrolled proxy policy. The Verifier appraises the proxy, not the device CPU. See Section 7.5. 5. Message Formats 5.1. CBOR/CDDL Definitions All PTV messages are CBOR maps [RFC8949] described in CDDL [RFC8610]. The CDDL fragments in this section, concatenated in order, form one CDDL module. Implementers SHOULD check the concatenation with a CDDL tool. Damodaran Expires 2 April 2027 [Page 9] Internet-Draft PTV Agent Identity September 2026 triage-band = 0 / 1 ; 0=ROUTINE, 1=ZK_PROOF ; 16..64 bytes, compatible with the EAT nonce claim (RFC 9711) nonce-type = bstr .size (16..64) ptv-result = &( success: 0, failure: 1, indeterminate: 2 ) ptv-policy = { ? audience: tstr, ? policy_uri: tstr, ? trust_domain: tstr, ? requirements: [* tstr], ? require_sovereign_bound: bool } sovereign-bound = { jurisdiction: tstr, data_residency: tstr, compliance: [* tstr] } ; Fields common to every message. msg_type and timestamp are ; NOT here; each message map declares them exactly once. ptv-common = ( ptv_version: tstr, ; this document: "1.1" nonce: nonce-type, ? extensions: { * tstr => any } ) behavior_fingerprint remains OPTIONAL and opaque. This version defines no processing rules for it. 5.2. Mutual Exclusion of Evidence and Proof In PTV_PROVE_RESP and PTV_TRANSFORM_ATT: * ROUTINE (triage_band = 0): evidence MUST be present and proof MUST NOT be present. * ZK_PROOF (triage_band = 1): proof MUST be present and evidence MUST NOT be present. A message that contains both, or neither, MUST be rejected with PTV_ERR_008. Damodaran Expires 2 April 2027 [Page 10] Internet-Draft PTV Agent Identity September 2026 payload-routine = ( triage_band: 0, evidence: bstr ) payload-zk = ( triage_band: 1, proof: bstr ) sovereign_bound MUST be present if policy.require_sovereign_bound is true in the corresponding request. Otherwise it is OPTIONAL. 5.3. Message Types 5.3.1. PTV_PROVE_REQ (Type 1) Sent by the Relying Party (or Verifier acting for it). ptv-prove-req = { ptv-common, msg_type: 1, ? timestamp: time, ? policy: ptv-policy } The nonce MUST be at least 128 bits of cryptographic randomness [RFC4086], MUST be 16 to 64 bytes long, and MUST be unique across attestation sessions of its Nonce Issuer. 5.3.2. PTV_PROVE_RESP (Type 2) Sent by a direct-mode Attester. ptv-prove-resp = { ptv-common, msg_type: 2, attester_id: tstr, ? sovereign_bound: sovereign-bound, (payload-routine // payload-zk), ? behavior_fingerprint: bstr, timestamp: time } evidence, when present, SHOULD be an EAT [RFC9711] whose eat_nonce equals the request nonce. See Section 6. Damodaran Expires 2 April 2027 [Page 11] Internet-Draft PTV Agent Identity September 2026 proof, when present, is an opaque encoding of a ZK proof. The public inputs of the proof MUST include: 1. the request nonce; 2. the Attester identifier, or a hash of the public part of the attestation key that signs the message (Section 5.4); 3. a configuration digest H(model_id || policy_id || runtime_measurement) whose reference value is endorsed out of band; 4. optionally, a digest of sovereign_bound when that field is present. This document does not mandate Groth16, PLONK, or any other system. Deployments MUST document the proof system, curve, and verifying key distribution. 5.3.3. PTV_TRANSFORM_ATT (Type 3) Sent by an Edge Proxy. Same payload rules as Type 2. attester_id identifies the proxy. The mediated device identity, if any, MAY appear in extensions. ptv-transform-att = { ptv-common, msg_type: 3, attester_id: tstr, ? sovereign_bound: sovereign-bound, (payload-routine // payload-zk), timestamp: time } 5.3.4. PTV_VERIFY_RESULT (Type 4) ptv-verify-result = { ptv-common, msg_type: 4, result: ptv-result, ? reason: tstr, ? audit_id: tstr, timestamp: time } ptv-message = ptv-prove-req / ptv-prove-resp / ptv-transform-att / ptv-verify-result Damodaran Expires 2 April 2027 [Page 12] Internet-Draft PTV Agent Identity September 2026 reason SHOULD use a code from Section 5.5 when result is not success. 5.4. Message Authentication PTV_PROVE_RESP and PTV_TRANSFORM_ATT MUST be carried as a COSE_Sign1 [RFC9052] whose payload is the CBOR encoding of the message and whose signature is produced by the attestation key (AK) identified by attester_id. This signature is what binds a ZK_PROOF to the hardware root of trust: the proof alone carries no hardware binding, and a Verifier MUST NOT treat a ZK_PROOF message without a valid AK signature as attested. For the ROUTINE band, the embedded Evidence is separately signed per its own format; the outer signature additionally protects sovereign_bound and the other envelope fields. PTV_VERIFY_RESULT SHOULD be a COSE_Sign1 signed by the Verifier, unless it is carried over a channel that authenticates the Verifier to the Relying Party and protects integrity. ptv-signed-message = #6.18([ protected: bstr, unprotected: { * any => any }, payload: bstr .cbor ptv-message, signature: bstr ]) The mapping of attester_id to a verification key is an enrollment matter and is outside this document; the Verifier MUST have that key (or a certificate chain to it) from enrollment. 5.5. Error Code Registry These codes are for the reason field. They are not an IANA registry in this version. Damodaran Expires 2 April 2027 [Page 13] Internet-Draft PTV Agent Identity September 2026 +=============+============================+========================+ | Code | Meaning | Typical recovery | +=============+============================+========================+ | PTV_ERR_001 | TPM/TEE attestation failed | Check local RoT | | | | and AK | +-------------+----------------------------+------------------------+ | PTV_ERR_002 | Proof verification failed | Regenerate with | | | | correct inputs | +-------------+----------------------------+------------------------+ | PTV_ERR_003 | Jurisdiction mismatch | Compare | | | | sovereign_bound | +-------------+----------------------------+------------------------+ | PTV_ERR_005 | Envelope expired | Request a new | | | | nonce | +-------------+----------------------------+------------------------+ | PTV_ERR_006 | Nonce replay or unknown | Discard; issue | | | | new nonce | +-------------+----------------------------+------------------------+ | PTV_ERR_007 | Config digest not approved | Update endorsed | | | | reference set | +-------------+----------------------------+------------------------+ | PTV_ERR_008 | Evidence/proof mutex error | Reject; do not | | | | retry same msg | +-------------+----------------------------+------------------------+ | PTV_ERR_009 | Proxy policy unsatisfied | Re-enroll proxy | | | | or device | +-------------+----------------------------+------------------------+ | PTV_ERR_010 | Signature invalid | Check AK | | | | enrollment | +-------------+----------------------------+------------------------+ Table 1 PTV_ERR_004 (quorum/BFT) from -00 is reserved and MUST NOT be used until a consensus mechanism is specified. 6. Informative EAT Mapping When Evidence is an EAT, the following mapping is RECOMMENDED. It is not a new EAT profile registration. Claim names are those of [RFC9711]. Damodaran Expires 2 April 2027 [Page 14] Internet-Draft PTV Agent Identity September 2026 +=====================+==============+=========================+ | PTV field / concept | EAT claim | Notes | +=====================+==============+=========================+ | nonce | eat_nonce | MUST match PTV nonce | | | | (PTV: 16-64 bytes) | +---------------------+--------------+-------------------------+ | attester_id | ueid or | Stable instance | | | oemid | identity | +---------------------+--------------+-------------------------+ | configuration | measurements | Endorsed reference | | digest | | values | +---------------------+--------------+-------------------------+ | hardware model | hwmodel, | As available; not the | | | hwversion | RoT type itself | +---------------------+--------------+-------------------------+ | timestamp | iat | Also carried in the PTV | | | | message | +---------------------+--------------+-------------------------+ | policy.audience | aud | CWT/JWT claim | +---------------------+--------------+-------------------------+ | policy.trust_domain | none | Carry in PTV policy | | | standard | | +---------------------+--------------+-------------------------+ | EAT profile | eat_profile | Identifies the profile, | | | | not a trust domain | +---------------------+--------------+-------------------------+ | sovereign_bound | none | Carry in EAT submodule | | | standard | or PTV message | +---------------------+--------------+-------------------------+ | proof (ZK_PROOF | not an EAT | Proof is the payload; | | band) | | EAT optional sidecar | +---------------------+--------------+-------------------------+ Table 2 PTV Evidence MAY itself be a CMW-wrapped EAT [RFC9999]. A future revision may define a concrete eat_profile URI. 7. Security Considerations 7.1. Freshness and Replay Every PTV attestation MUST echo the request nonce. Verifiers MUST reject a nonce that was not issued for a registered session or that has already been consumed (Section 4.2). Timestamps SHOULD be checked against a deployment-specific window. A window of 300 seconds is RECOMMENDED as a starting point, not a protocol constant. Damodaran Expires 2 April 2027 [Page 15] Internet-Draft PTV Agent Identity September 2026 7.2. Zero-Knowledge Proof Mechanism PTV is compatible with ZK proof systems and does not mandate one. The predicate is the public-input list in Section 5.3.2. Deployers MUST treat verifying-key distribution as an endorsement problem in the RATS sense [RFC9334]. A ZK proof that does not bind the nonce is not a PTV proof. A ZK proof that is not covered by a valid AK signature (Section 5.4) is not hardware-bound. Some proof systems (Groth16, for example) require a per-circuit trusted setup. Whoever retains the setup randomness ("toxic waste") can forge proofs that verify. Deployments using such systems MUST document how the setup was performed, SHOULD use a multi-party ceremony, and MUST treat a single-party setup as suitable only for non-adversarial testing. Deployments SHOULD also state the security level of the chosen curve. 7.3. Identity Misbinding Attestations SHOULD be bound to the agent instance via a hardware attestation key. Software-only attestations are NOT RECOMMENDED for high-assurance deployments. Values read from a platform without a signature by a hardware-protected key (for example a public key or an event log read through an operating system interface) are not Evidence in the sense of [RFC9334] and MUST NOT be presented as such. 7.4. Self-Asserted Metadata sovereign_bound labels are integrity-protected by the message signature but are claims made by the Attester. A Verifier MUST NOT treat them as verified facts unless they are also covered by appraised Evidence or an endorsement. 7.5. Edge Proxy Trust In Proxy-Assisted Mode the Verifier learns that a proxy attested, not that the constrained device ran a particular binary. Threats include: * a compromised proxy attesting for a device it does not mediate; * key reuse across proxied devices; * silent substitution of the downstream channel. Mitigations: Damodaran Expires 2 April 2027 [Page 16] Internet-Draft PTV Agent Identity September 2026 * enroll each proxy under its own attestation key; * put the mediated-device identifier into extensions and into the configuration digest when the device identity is stable; * rate-limit and independently audit proxy enrollment; * do not treat proxy Evidence as device-CPU Evidence. 7.6. Denial of Service Verifiers SHOULD rate-limit proof verification and MAY cache verifying keys and ROUTINE Evidence appraisals keyed by (attester_id, config_digest). 8. Privacy Considerations attester_id, ueid, and a stable attestation key are long-lived identifiers. Presenting them to many Relying Parties lets those parties correlate an agent's activity. Deployments SHOULD limit the Relying Parties that receive attester_id, and MAY use per-Relying- Party pseudonymous identifiers or per-audience attestation keys where the hardware supports it. The ZK_PROOF band is intended to avoid disclosing model weights and inference inputs, but the configuration digest and any reference- value set are visible to the Verifier. Sovereign-bound labels may reveal deployment location. Neither the proof nor these labels amount to legal compliance certification. 9. Interoperability and Future Work 9.1. Layering PTV is Layer 1 (identity binding) in the three-layer agent accountability framing [ACCOUNT-LAYERS]: * PTV / EAT: who is running, and in what enrolled state; * Delegation provenance (for example HDP [I-D.helixar-hdp-agentic-delegation]): who authorized the act; * Execution receipts (SCITT [RFC9943] or similar): what external effect was produced. Composition SHOULD be by hash reference (receipt cites hash of PTV result and hash of delegation record), not by embedding one protocol inside another. Damodaran Expires 2 April 2027 [Page 17] Internet-Draft PTV Agent Identity September 2026 9.2. Open Items 1. A registered EAT profile URI for PTV ROUTINE Evidence. 2. A COSE header for behavior_fingerprint if that field is standardized. 3. A concrete proof-system profile if the WG wants ZK_PROOF to be interoperable rather than opaque. 4. Whether PTV should remain a message protocol or collapse to EAT Challenge/Response with these claims. This Experimental revision exists so that implementers can answer item 4 with running code. 10. Implementation Status Note to RFC Editor: remove this section before publication. A prototype is available at [PTV-PROTOTYPE]. As of this revision it implements the ZK_PROOF path using Poseidon hashing and Groth16 over BN254 (circom/snarkjs), and reads platform measurements from a TPM 2.0 on Windows. It does not yet produce a TPM quote signed by an attestation key, does not implement the COSE_Sign1 protection in Section 5.4, and uses a single-party trusted setup. It is therefore not yet an implementation of the hardware binding described in this document and SHOULD NOT be used in adversarial environments. 11. IANA Considerations This document makes no requests of IANA. A future revision may request an EAT profile URI, a CBOR tag, or a media type once the message set is stable. 12. Acknowledgements Comments from participants on the RATS list and from the three-layer accountability discussion improved the -00 separation of identity binding from behavioral continuity. Remaining errors are the author's. 13. References 13.1. Normative References Damodaran Expires 2 April 2027 [Page 18] Internet-Draft PTV Agent Identity September 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . 13.2. Informative References [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Damodaran Expires 2 April 2027 [Page 19] Internet-Draft PTV Agent Identity September 2026 [I-D.ietf-rats-reference-interaction-models] Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats- reference-interaction-models-18, 17 September 2026, . [RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [I-D.helixar-hdp-agentic-delegation] Dalugoda, A., "Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems", Work in Progress, Internet-Draft, draft-helixar-hdp- agentic-delegation-02, 11 September 2026, . [TPM2] Trusted Computing Group, "Trusted Platform Module Library, Part 1: Architecture", 2019. [ACCOUNT-LAYERS] agent-morrow, "Three-Layer Architecture for Verifiable Agent Accountability", 2026, . [PTV-PROTOTYPE] Damodaran, A., "zk-agent-attestation: PTV reference prototype", 2026, . Damodaran Expires 2 April 2027 [Page 20] Internet-Draft PTV Agent Identity September 2026 Appendix A. Appendix A. Prototype Observations (Non-Normative) The following figures are from the prototype in [PTV-PROTOTYPE] (10 runs each, Windows 11, Node.js v24, snarkjs v0.7, library mode, Poseidon plus equality circuit with 426 non-linear constraints). They are not requirements, they cover proof generation and verification only, and they do not include TPM quote generation or COSE signing. +====================+=============+=======================+ | Metric | Observed | Conditions | +====================+=============+=======================+ | Proof generation | about 49 ms | library mode, 10 runs | +--------------------+-------------+-----------------------+ | Proof verification | about 9 ms | single proof, 10 runs | +--------------------+-------------+-----------------------+ Table 3: Prototype observations Appendix B. Appendix B. Examples (Non-Normative) All values are illustrative. Byte strings are shortened where noted; a real message carries full EAT bytes, a full proof, and a real COSE_Sign1 signature. Timestamps are CBOR tag 1 (epoch seconds). B.1. PTV_PROVE_REQ { "ptv_version": "1.1", "nonce": h'a1b2c3d4e5f60718293a4b5c6d7e8f90', "msg_type": 1, "timestamp": 1(1790640000), "policy": { "audience": "https://rp.example", "requirements": ["approved-config"], "require_sovereign_bound": false } } B.2. PTV_PROVE_RESP, ROUTINE band This is the payload of the COSE_Sign1 in Section 5.4. The evidence field is an EAT whose eat_nonce equals the request nonce (bytes elided here). Damodaran Expires 2 April 2027 [Page 21] Internet-Draft PTV Agent Identity September 2026 { "ptv_version": "1.1", "nonce": h'a1b2c3d4e5f60718293a4b5c6d7e8f90', "msg_type": 2, "attester_id": "ueid:0102030405060708", "triage_band": 0, "evidence": h'd28443a10126', / EAT, elided / "timestamp": 1(1790640002) } B.3. PTV_PROVE_RESP, ZK_PROOF band The proof bytes are elided. Its public inputs are the nonce, the hash of the AK public key, and the configuration digest, in the order fixed by the deployment's proof-system profile. { "ptv_version": "1.1", "nonce": h'a1b2c3d4e5f60718293a4b5c6d7e8f90', "msg_type": 2, "attester_id": "ueid:0102030405060708", "sovereign_bound": { "jurisdiction": "IN", "data_residency": "IN", "compliance": ["example-policy-1"] }, "triage_band": 1, "proof": h'9f3c00a1', / proof, elided / "timestamp": 1(1790640002) } B.4. PTV_VERIFY_RESULT { "ptv_version": "1.1", "nonce": h'a1b2c3d4e5f60718293a4b5c6d7e8f90', "msg_type": 4, "result": 0, "audit_id": "audit-0001", "timestamp": 1(1790640003) } B.5. Rejected message A PTV_PROVE_RESP carrying both evidence and proof, or neither, is malformed and is answered with result 1 and reason PTV_ERR_008: Damodaran Expires 2 April 2027 [Page 22] Internet-Draft PTV Agent Identity September 2026 { "ptv_version": "1.1", "nonce": h'a1b2c3d4e5f60718293a4b5c6d7e8f90', "msg_type": 4, "result": 1, "reason": "PTV_ERR_008", "timestamp": 1(1790640003) } Author's Address Anandakrishnan Damodaran Sovereign AI Stack Email: ananda.krishnan@hotmail.com URI: https://github.com/anandkrshnn Damodaran Expires 2 April 2027 [Page 23]