Independent Submission P. Etcheverry Internet-Draft Rama Intended status: Informational K. Ives Expires: 24 January 2027 23 July 2026 Action Reference: A Deterministic Identifier for Agent Actions draft-etcheverry-action-ref-02 Abstract This document defines "action_ref", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees. Editorial Note Discussion of this draft takes place on the argentum-core repository: . A conformance test suite with byte-verified vectors is maintained at . 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 24 January 2027. Etcheverry & Ives Expires 24 January 2027 [Page 1] Internet-Draft Action Reference July 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Action Reference Derivation . . . . . . . . . . . . . . . . . 4 3.1. Preimage Fields . . . . . . . . . . . . . . . . . . . . . 5 3.2. Serialization . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Hash Function . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Timestamp Format . . . . . . . . . . . . . . . . . . . . 6 3.5. Derivation Example . . . . . . . . . . . . . . . . . . . 7 4. Canonical Receipt Envelope . . . . . . . . . . . . . . . . . 7 4.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 7 4.2. Optional Fields for Rotation Auditability . . . . . . . . 8 5. Three-Record Trail and authorization_ref . . . . . . . . . . 9 5.1. Layer Model . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. authorization_ref Derivation . . . . . . . . . . . . . . 10 5.3. Canonical Linking Key . . . . . . . . . . . . . . . . . . 10 6. Scope Conventions . . . . . . . . . . . . . . . . . . . . . . 11 7. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Telemetry Integration . . . . . . . . . . . . . . . . . . . . 12 8.1. Instrumentation Point . . . . . . . . . . . . . . . . . . 12 8.2. Attribute Placement . . . . . . . . . . . . . . . . . . . 13 8.3. Cross-Producer Correlation . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.1. Replay Attack Surface . . . . . . . . . . . . . . . . . . 14 9.2. Scope Injection . . . . . . . . . . . . . . . . . . . . . 14 9.3. Timestamp Manipulation . . . . . . . . . . . . . . . . . 14 9.4. Operator-Independence Guarantee . . . . . . . . . . . . . 14 10. Interoperability Considerations . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 16 A.1. Positive Conformance Vector . . . . . . . . . . . . . . . 17 A.2. Negative Conformance Vector — Epoch-Integer Timestamp . . 17 A.3. authorization_ref Vector . . . . . . . . . . . . . . . . . 17 Etcheverry & Ives Expires 24 January 2027 [Page 2] Internet-Draft Action Reference July 2026 Appendix A.4. External Conformance Set — evidence-anchor-static-analysis-v0 . . . . . . . . . . . 18 Appendix B. Field Mapping for Existing Systems . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Autonomous agents operating across distributed systems need a way to identify individual actions that is independent of any single system's infrastructure. Existing audit trail mechanisms rely on operator-managed identifiers — UUIDs, database primary keys, or system-specific event IDs — that cannot be verified by a third party without trusting the issuing system. This document defines "action_ref": a deterministic identifier derived from four preimage fields that any party can independently compute. The identifier is content-addressed — it is derived from the action content itself, not from a sequencer or registry. A verifier holding the four fields can recompute it without any call to the operator's infrastructure. The design goal is operator-independence: a receipt carrying action_ref can be verified by an auditor, a smart contract, or a competing system without trusting the emitter. This property is structural, not procedural — it follows from the derivation algorithm, not from operator policy. An automated static analysis of 35,689 agent-ecosystem endpoints [AgentGraph-EvidenceAnchor] found that 636 of 7,029 MCP servers (~9%) carry a high or critical finding — hardcoded secrets, unsafe exec/ eval, missing authentication, or known-vulnerable dependencies — detectable by static analysis alone. This motivates an independently-verifiable evidence anchor for scan results, so a relying party can confirm a verdict without trusting the scanner operator. | This figure covers static analysis only; it does not cover | runtime or behavioral risk. Methodology: AgentGraph | EvidenceAnchor static analysis conformance set, June 2026 | [AgentGraph-EvidenceAnchor]. This document covers: * The derivation algorithm (SHA-256 over JCS-canonical JSON). * Preimage field semantics and invariants. Etcheverry & Ives Expires 24 January 2027 [Page 3] Internet-Draft Action Reference July 2026 * Timestamp format requirements for cross-implementation byte consistency. * The canonical receipt envelope. * Optional fields for policy rotation and revocation auditability. * The authorization_ref derivation for three-record trail correlation. * Scope conventions for cross-emitter disambiguation. * Security considerations including replay attack surface. 2. Terminology 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. action_ref: A deterministic, content-addressed identifier for an agent action. Computed as SHA-256(JCS({agent_id, action_type, scope, timestamp})). preimage: The four-field JSON object over which the SHA-256 hash is computed: {agent_id, action_type, scope, timestamp}. emitter: The system or agent that produces a receipt containing action_ref. verifier: Any party that independently recomputes action_ref from the preimage fields and checks it against a presented receipt. operator: The system controlling the emitter. A verifier MUST be able to verify action_ref without trusting the operator. JCS: JSON Canonicalization Scheme, defined in [RFC8785]. Produces a unique byte sequence for any JSON value. trail: A sequence of records (pre-execution, decision, receipt) correlated by action_ref across systems. 3. Action Reference Derivation Etcheverry & Ives Expires 24 January 2027 [Page 4] Internet-Draft Action Reference July 2026 3.1. Preimage Fields The preimage is a JSON object containing exactly four fields: +=============+========+===========================================+ | Field | Type | Description | +=============+========+===========================================+ | agent_id | string | Stable identifier for the executing agent | | | | at issuance time — the terminal executor | | | | after full delegation resolution. In a | | | | delegation chain A→B→C where C executes | | | | the action, agent_id is C. | +-------------+--------+-------------------------------------------+ | action_type | string | Semantic label for what the agent did | | | | (e.g., "code.execute", "payment.send", | | | | "oracle.signal"). | +-------------+--------+-------------------------------------------+ | scope | string | Terminal executing agent's requested- | | | | intent scope at the point of action. | | | | Non-empty string. MUST NOT be a derived | | | | hash of the intent object (see | | | | Section 6). | +-------------+--------+-------------------------------------------+ | timestamp | string | RFC 3339 UTC with exactly 3 millisecond | | | | digits. Format: YYYY-MM- | | | | DDTHH:MM:SS.mmmZ. See Section 3.4. | +-------------+--------+-------------------------------------------+ Table 1 The four fields are REQUIRED. No additional fields enter the preimage. Optional fields in the receipt envelope (Section 4) do not affect the action_ref value. 3.2. Serialization The four fields MUST be serialized using RFC 8785 JSON Canonicalization Scheme (JCS) before hashing: * Keys in lexicographic Unicode code point order: action_type, agent_id, scope, timestamp. * No whitespace between tokens. * UTF-8 encoded. * Values are JSON strings (standard JSON escaping only). Etcheverry & Ives Expires 24 January 2027 [Page 5] Internet-Draft Action Reference July 2026 The resulting JCS payload for a conformant implementation will sort keys in this order: action_type < agent_id < scope < timestamp. Implementations using the simple json.dumps approach (Python, Node.js) produce RFC 8785-compatible bytes for inputs within the safe band: ASCII-only field values, conformant RFC 3339 timestamps, no surrogate-pair Unicode. For inputs outside this band, implementations MUST use an RFC 8785-compliant library. 3.3. Hash Function action_ref = SHA-256(JCS(preimage)), encoded as lowercase hexadecimal. The output is a 64-character lowercase hex string (256 bits / 32 bytes). Uppercase hex is non-conformant. 3.4. Timestamp Format The timestamp field MUST conform to the following format constraints: * Timezone: "Z" suffix only. "+00:00" or any other offset representation is non-conformant. * Fractional precision: exactly 3 digits (milliseconds). No trailing zero suppression. ".000" is conformant; ".0" is not. * Template: YYYY-MM-DDTHH:MM:SS.mmmZ — one valid byte sequence per instant. These constraints close the [RFC3339] underspecification surface. RFC 3339 admits multiple lexically distinct encodings of the same instant that produce different SHA-256 digests under JCS. This specification closes that surface at the format level. Implementations holding epoch-millisecond integers MUST convert to the conformant RFC 3339 string before hashing. Implementations that hash the epoch-ms integer directly are not conformant. The W3C CG ai-agent-protocol discussion (issue #34) established epoch-millisecond integer as an application-layer representation. This specification uses the RFC 3339 string form in the preimage. The two representations are not interchangeable in the preimage — they produce different digests. Etcheverry & Ives Expires 24 January 2027 [Page 6] Internet-Draft Action Reference July 2026 3.5. Derivation Example The following example is byte-verified in the conformance suite (vector "nexus-oracle-signal"): Input: agent_id = "nexus-agent-xa12.onrender.com" action_type = "oracle.signal" scope = "BTC" timestamp = "2025-05-18T11:40:31.000Z" JCS payload: {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":"2025-05-18T11:40:31.000Z"} SHA-256: fdd7f810499f06be24355ca8e2bfb8c4b965cc80c838f41fa074683443d89f5a 4. Canonical Receipt Envelope 4.1. Required Fields Implementations that emit a receipt referencing this specification SHOULD include the following fields to ensure long-lived verifiability: { "packet_version": "1.0", "action_ref": "", "hash_algo": "sha256", "preimage_format": "jcs-rfc8785-v1", "preimage": { "agent_id": "...", "action_type": "...", "scope": "...", "timestamp": "2026-05-15T10:00:00.123Z" } } packet_version: Forward-compatibility anchor. v1 verifiers can explicitly reject unknown versions rather than fail silently. hash_algo: Makes receipts self-describing. If a future implementation switches hash functions, receipts issued before the change remain replayable. preimage_format: Unambiguously identifies the serialization. Any Etcheverry & Ives Expires 24 January 2027 [Page 7] Internet-Draft Action Reference July 2026 verifier can recompute action_ref from the preimage fields using RFC 8785 without trusting the emitter. 4.2. Optional Fields for Rotation Auditability The canonical receipt envelope v1.0 records state at the moment the action was claimed. It does not record whether that state was still valid when the action was admitted for execution. Two failure modes this gap creates: 1. *Trust tier degradation:* an agent moves from TRUSTED to WATCH between claim and execution. The anchor records the claim-time state. A verifier replaying the receipt cannot determine from the receipt alone whether the agent was still trusted when the action was admitted. 2. *Policy rotation:* the counterparty policy changes between issuance and execution. A counterparty_policy_hash field proves which policy was referenced at claim time, but does not prove whether that policy was still current at admission. Three optional fields close this gap: policy_version (string, OPTIONAL): Identifies which version of the governing policy was in force when the action was admitted. Distinct from counterparty_policy_hash, which proves which policy was referenced — policy_version proves whether it was still current at execution time. authority_verified_at_ms (integer, OPTIONAL): Unix timestamp in milliseconds at which the delegation authority was verified at issuance. Records when the acting agent's authority was confirmed before the action was admitted. revocation_check_at_ms (integer, OPTIONAL): Unix timestamp in milliseconds of the last non-revocation check performed before execution. Establishes a maximum window of credential exposure. A receipt without this field cannot prove the agent's credentials were valid immediately before the action was admitted. A verifier that requires post-rotation auditability SHOULD treat a receipt missing either field as unauditable for the rotation window — not as invalid. The millisecond precision for revocation_check_at_ms is REQUIRED. Credential checks in live multi-agent systems happen at sub-second granularity. Systems that only have second-precision timestamps SHOULD multiply by 1000 and document the precision loss. Etcheverry & Ives Expires 24 January 2027 [Page 8] Internet-Draft Action Reference July 2026 Note: the three optional fields in this section correspond to the "freshness" verification layer described in discussions on the agntcy/identity repository (issue #165). A verifier confirming offline signature integrity (integrity), checking that the executed scope sat within the delegated scope (authority), and establishing the key validity window at decision time (freshness) needs all three layers. The fields in this section address the freshness layer; the authorization_ref in Section 5 addresses the authority layer. 5. Three-Record Trail and authorization_ref 5.1. Layer Model action_ref is the correlation key across a three-record trail: 1. *Pre-execution record:* the commitment before the action is taken. Contains the action_ref preimage fields and authorization_ref. 2. *Decision record:* the authorization event. Contains authorization_ref as its identifier and action_ref as the correlation key. 3. *Receipt:* the post-execution record. Contains action_ref and authorization_ref; verifier checks both against the pre-execution record. A conformant verifier runs four independent checks across the trail: +====================+========================================+ | Check | Fields compared | +====================+========================================+ | Same call instance | action_ref in pre-execution == | | | action_ref in receipt | +--------------------+----------------------------------------+ | Same proposed | original_args_digest recomputed from | | payload | disclosed args | +--------------------+----------------------------------------+ | Same dispatched | effective_args_digest in pre-execution | | payload | == verifier-recomputed from receipt | +--------------------+----------------------------------------+ | Same authorization | authorization_ref in pre-execution == | | decision | authorization_ref in receipt | +--------------------+----------------------------------------+ Table 2 Etcheverry & Ives Expires 24 January 2027 [Page 9] Internet-Draft Action Reference July 2026 A trail that passes the first three checks but fails the fourth proves that execution proceeded under a different approval than the one recorded in the pre-execution entry. 5.2. authorization_ref Derivation authorization_ref is the identifier for the Decision record: authorization_ref = SHA-256(JCS({ "action_ref": "", "authorized_scope": "", "decision_ts": , "policy_id": "" })) JCS lexicographic key order: action_ref, authorized_scope, decision_ts, policy_id. Note: decision_ts is an epoch-millisecond integer, not an RFC 3339 string. Invariants: * action_ref is embedded in the preimage. A verifier can confirm the decision was not reused across action instances. * Recomputable without operator cooperation from the four decision record fields. * MUST appear in both the pre-execution record and the receipt. * The signer of the Decision record MUST be independent of the actor/executor whose action it authorizes. A party recomputing and certifying an existing signed record after the fact (referee role) does not satisfy this — the signer of record must be independent BEFORE the outcome is final, not verifying it afterward. 5.3. Canonical Linking Key The same action_ref is computable from artifacts produced by independent systems using the same four-field derivation: * A Mycelium TrailRecord (preimage fields published in each record). * A Nobulex covenant receipt (action_type as semantic label + timestamp + agent_id + scope). * A SafeAgent claim (joint spec argentum-core issue #7). Etcheverry & Ives Expires 24 January 2027 [Page 10] Internet-Draft Action Reference July 2026 * A CrewAI idempotency key (crewAI PR #5822 — key derivation converges on this primitive from the retry-deduplication direction). * NEXUS oracle receipts (implements canonical envelope v1.0). Any verifier holding one artifact can validate against another without trusting either system. 6. Scope Conventions scope is a free-form non-empty string. Any value is valid as long as it is non-empty and consistent across all parties deriving the same action_ref. RECOMMENDED convention (non-normative): namespace-prefix with the emitter identifier using :, for example "algovoi:compliance_screen" or "presidio:x402.screen:clean-allow". Prefixing avoids collisions when trails from multiple emitters are verified or aggregated by a third party. The scope anti-pattern: scope MUST NOT be a derived hash of the intent object. A common mistake is to hash the initial intent object and use that hash as the scope value. This breaks the primary verifiability property: any party holding the four preimage fields must be able to recompute action_ref independently, without retrieving any external record. With a hashed scope, a verifier cannot recompute action_ref from the intent tuple alone — they must also retrieve the commitment record. Multi-value scope segments: when a scope segment encodes a set of values (e.g., entity types detected by a screening decision), implementations MUST sort those values lexicographically and join them with a comma and no spaces. This ensures byte-determinism across implementations that may produce values in non-stable detection order. 7. Conformance A conformance test suite with byte-verified vectors is maintained in [argentum-core]. The suite includes: * action-ref-v1-baseline: positive and negative vectors for the four preimage fields, including timestamp format violations. Etcheverry & Ives Expires 24 January 2027 [Page 11] Internet-Draft Action Reference July 2026 * guardrail-provider-v1: authorization_ref derivation vectors including NEG cases for decision reuse detection. * near-miss-v1: same action_ref, different state (KNOWN_DESIGN_PROPERTY). * recompute-drift-v1: epoch-integer non-conformance (neg-b01-epoch- integer). * signing-trust-ref-v1: operator key isolation vectors. * restraint-receipt-v1: deny and defer verdict vectors. Each conformance directory includes verify.py and verify.mjs. All vectors are byte-identical across implementations. The stable tag for v1.0 is "action-ref-v1.0" in the argentum-core repository. External conformance sets accepted under review: * examples/conformance/graph-advocate/ — PaulieB14 (Graph Advocate), counterparty-ref-v1, 3 vectors, 2 implementations byte-identical, production service. * examples/conformance/agentoracle-v1/ — TKCollective (AgentOracle + AgentTrust), 10 vectors, cross-issuer property verified. * examples/conformance/presidio-x402/ — vstantch/presidio-group.eu, PII screening with composition, 3 vectors. 8. Telemetry Integration action_ref is designed to serve as a correlation key in observability pipelines. This section defines the instrumentation point, attribute placement, and cross-producer correlation property for implementations that export telemetry records. 8.1. Instrumentation Point The correct instrumentation point is the authorization gate's evaluation operation: the component that receives the intent tuple, applies policy, and returns a decision (allow, deny, warn, escalate, or transform). Etcheverry & Ives Expires 24 January 2027 [Page 12] Internet-Draft Action Reference July 2026 Implementations MUST NOT derive action_ref at the invoking agent's span level. Agent-level instrumentation does not have access to the complete intent tuple (agent_id, action_type, scope, timestamp) as presented to the gate. A hash computed from partial or reconstructed inputs is not conformant and will not verify against independently derived values. The gate SHOULD derive action_ref before returning the verdict, so that the value is available for inclusion in the evaluation record at the moment of decision. The derivation requires no network call or external state: it is a local SHA-256 of the JCS-serialized preimage. 8.2. Attribute Placement When the gate's evaluation operation is recorded as a telemetry span or structured event, action_ref SHOULD be included as a string attribute. The gate sets this attribute from the preimage fields, not from the returned decision object or any downstream record. Downstream components that reference the same action (e.g., a payment receipt, an audit log entry, or a screening record) MAY carry action_ref as a correlation attribute. When a downstream span includes action_ref, the value MUST be the 64-character lowercase hex string derived by the gate for that evaluation. Re-deriving the value from a different preimage is not permitted: only the gate holds the authoritative preimage at decision time. 8.3. Cross-Producer Correlation Because action_ref is derived deterministically from a fixed preimage, independent components that participate in the same authorized action can produce the same value without coordination. A policy gate, a screening component, and an audit service each derive the same action_ref from the same four fields, independently and without shared session state. This property enables a verifier to correlate telemetry records across producers without trusting any single emitter. A monitoring system that receives evaluation events from multiple authorization components can join them on action_ref without relying on an operator-provided correlation key. The join is verifiable: any party holding the preimage fields can recompute the key and confirm the association. When multiple components record the same action_ref in the same telemetry pipeline, the set of matching records constitutes an independently verifiable trace of the action across system boundaries. Etcheverry & Ives Expires 24 January 2027 [Page 13] Internet-Draft Action Reference July 2026 9. Security Considerations 9.1. Replay Attack Surface action_ref is deterministic: the same four preimage field values always produce the same identifier. This is a design property — it enables cross-system correlation without operator trust. The implication is that action_ref alone does not prevent replay. Replay protection requires the receipt to carry: * authorization_ref (Section 5.2): binds the identifier to a specific authorization decision. A replayed action_ref with a different authorization decision will fail check 4. * signing-trust-ref-v1: an operator-independent signature over the full receipt envelope. An attacker cannot substitute a different receipt without invalidating the signature. A verifier that checks action_ref alone (without authorization_ref and signature) cannot detect replay. This specification requires both fields for complete replay resistance. 9.2. Scope Injection If scope is not validated at emission time, an adversary can inject a scope string that differs from the actual intent. The action_ref will be a valid hash of the injected scope, not of the actual action. Verifiers SHOULD require that scope is provided by the executing agent, not derived or transformed by an intermediary system. 9.3. Timestamp Manipulation A non-conformant timestamp (wrong precision, wrong timezone suffix, epoch-ms instead of RFC 3339 string) produces a different digest. This can be used to generate action_refs that appear valid but cannot be independently recomputed by a conformant verifier. Implementations MUST validate timestamp format at emission time, not only at verification time. 9.4. Operator-Independence Guarantee The operator-independence property holds only if: 1. The four preimage fields are disclosed to verifiers. 2. The hash function and serialization are public and deterministic. Etcheverry & Ives Expires 24 January 2027 [Page 14] Internet-Draft Action Reference July 2026 3. No field in the preimage is derived from an operator-controlled system without disclosure. An emitter that uses a non-public agent_id (e.g., a UUID assigned by an internal sequencer and not disclosed) breaks the verifiability property: a verifier cannot recompute action_ref without retrieving the agent_id from the operator. Implementations MUST use stable, publicly disclosed agent identifiers. The operator-independence property can be satisfied in two distinct ways, and implementers SHOULD state which one applies. In the *internally-consistent* case, the verifier's own recomputation of action_ref from the disclosed preimage fields is sufficient: the digest either matches or it does not, and no party external to the emitter and the verifier needs to attest to anything. In the *externally-witnessed* case, byte recomputation alone does not close the loop — the property also depends on a step that could not have been skipped or backdated by the operator, such as a timestamp or inclusion proof from a system the operator does not control (e.g. an on-chain anchor, or a SCITT receipt as described in Section 10). This is not an additional preimage field: it is a statement about how conformance to this section is established, not about what is hashed. 10. Interoperability Considerations action_ref is compatible with SCITT transparency logs [I-D.ietf-scitt-architecture] as an anchoring layer. A SCITT-enabled system can treat action_ref as the payload hash submitted to a Transparency Service: the resulting SCITT receipt provides a signed inclusion proof over the same content-addressed identifier defined in this specification. The on-chain anchor described in Section 6 is conceptually equivalent to a SCITT receipt — both bind a content- addressed identifier to an external, operator-independent timestamp — but the on-chain variant does not require hardware TEE endorsement or a dedicated Transparency Service deployment. Implementers operating within SCITT-enabled infrastructure MAY substitute a SCITT receipt for the on-chain anchor without changing the action_ref derivation algorithm or the receipt envelope structure defined in this document. 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References Etcheverry & Ives Expires 24 January 2027 [Page 15] Internet-Draft Action Reference July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . 12.2. Informative References [argentum-core] Giskard, R., "argentum-core: Mycelium Trails Reference Implementation and Conformance Suite", 2026, . [CTEF] kenneives, K., "Composable Trust Evaluation Framework (CTEF)", 2026, . [AgentGraph-EvidenceAnchor] kenneives, K., "evidence-anchor-static-analysis-v0: Static analysis conformance set for action_ref", June 2026, . [I-D.ietf-scitt-architecture] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Jaeger, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains (SCITT)", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture, 2024, . Appendix A. Test Vectors All vectors are byte-verified in the conformance suite at . Etcheverry & Ives Expires 24 January 2027 [Page 16] Internet-Draft Action Reference July 2026 A.1. Positive Conformance Vector Vector: nexus-oracle-signal (action-ref-v1-baseline) agent_id = "nexus-agent-xa12.onrender.com" action_type = "oracle.signal" scope = "BTC" timestamp = "2025-05-18T11:40:31.000Z" JCS payload (UTF-8): {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":"2025-05-18T11:40:31.000Z"} action_ref: fdd7f810499f06be24355ca8e2bfb8c4b965cc80c838f41fa074683443d89f5a A.2. Negative Conformance Vector — Epoch-Integer Timestamp Vector: neg-b01-epoch-integer (recompute-drift-v1) Same action as A.1, but timestamp hashed as epoch-ms integer instead of RFC 3339 string. Produces a different digest. Non-conformant preimage (epoch-ms as integer — DO NOT USE): {"action_type":"oracle.signal","agent_id":"nexus-agent-xa12.on render.com","scope":"BTC","timestamp":1747568431000} A verifier recomputing from the RFC 3339 string will obtain a different hash and correctly reject the receipt. A.3. authorization_ref Vector Vector: step_2b_authorization_ref (guardrail-provider-v1) action_ref = "104812928eb50e0e1ad28f379f8ade03ea0f479ac7abd1b bf9205e9317665c7f" authorized_scope = "autogen:guardrail" decision_ts = 1749513600000 policy_id = "guardrail-policy-v1" JCS payload: {"action_ref":"104812928eb50e0e1ad28f379f8ade03ea0f479ac7abd1bbf920 5e9317665c7f","authorized_scope":"autogen:guardrail","decision_ts": 1749513600000,"policy_id":"guardrail-policy-v1"} authorization_ref: b9f8494a4a5943687d105769556be2963271e37f2216d2afd279e5b260261327 Etcheverry & Ives Expires 24 January 2027 [Page 17] Internet-Draft Action Reference July 2026 Appendix A.4. External Conformance Set — evidence-anchor-static- analysis-v0 Contributed by: AgentGraph (agentgraph-co/agentgraph, kenneives). This conformance set anchors static analysis findings from an agent- ecosystem endpoint scan (35,689 endpoints; June 2026) to verifiable action_ref identifiers. It contains 4 byte-verified vectors covering three invariants: 1. *Scan-attest anchor:* a scan.attest action from a did:web scanner agent produces a stable action_ref independently recomputable by any verifier without registry access. 2. *Cross-implementation byte match:* the spec's Appendix A Vector 1 (nexus-oracle-signal, fdd7f810…) reproduces byte-for-byte using the rfc8785 Python library and Node built-ins — two independent implementation lineages agreeing on the same digest. 3. *Live ecosystem seam:* the payment-charge vector's action_ref is identical to the one carried in AgentGraph's v0.4 pre-execution- verdict-v0 verifier fixture, where it is byte-matched across the haroldmalikfrimpong-ops / evidai / azender1 payment seam — this derivation is exercised live, not only specified. All 4 vectors are byte-verified in the conformance directory at . The set was contributed under AGT PR #21 (evidence-anchor-static-analysis-v0, merged 2026-06-24). Appendix B. Field Mapping for Existing Systems Systems that have adopted action_ref derivation or compatible primitives: Etcheverry & Ives Expires 24 January 2027 [Page 18] Internet-Draft Action Reference July 2026 +==============+==========+====================+====================+ |System |agent_id |action_type mapping |Notes | | |mapping | | | +==============+==========+====================+====================+ |SafeAgent |agent |claim type |Joint spec argentum-| |(azender1) |identifier| |core #7 | +--------------+----------+--------------------+--------------------+ |Graph Advocate|wallet |counterparty event |counterparty-ref-v1,| |(PaulieB14) |address |type |production | | |(EIP-55) | | | +--------------+----------+--------------------+--------------------+ |AgentOracle/ |issuer DID|oracle action type |Two issuers, cross- | |AgentTrust | | |issuer property | |(TKCollective)| | | | +--------------+----------+--------------------+--------------------+ |CTEF ([CTEF]) |agent |evaluation action |action_ref REQUIRED | | |graph node| |in v0.4 | | |ID | | | +--------------+----------+--------------------+--------------------+ |presidio-x402 |screening |presidio:x402.screen|PII screening, | |(vstantch) |agent ID | |composition | +--------------+----------+--------------------+--------------------+ Table 3 Authors' Addresses Pablo Etcheverry Rama Email: playplay2736@gmail.com URI: https://github.com/giskard09/argentum-core Kenne Ives Email: kennethives@gmail.com Etcheverry & Ives Expires 24 January 2027 [Page 19]