Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification for Machine-Readable Entity Claims
draft-deforth-arp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sascha Deforth | ||
| Last updated | 2026-04-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-deforth-arp-00
Internet Engineering Task Force S. Deforth
Internet-Draft TrueSource
Intended status: Standards Track 18 April 2026
Expires: 20 October 2026
Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification
for Machine-Readable Entity Claims
draft-deforth-arp-00
Abstract
This document specifies the Agentic Reasoning Protocol (ARP), a
lightweight mechanism for cryptographically binding machine-readable
entity claims to domain ownership via DNS TXT records. ARP enables
AI agents and Retrieval-Augmented Generation (RAG) pipelines to
verify that structured data published on a domain was authorized by
the domain owner, preventing narrative injection and entity spoofing
in generative search systems.
ARP uses Ed25519 digital signatures [RFC8032], JSON Canonicalization
Scheme (JCS) [RFC8785], and DNS TXT records to establish a chain of
trust analogous to DomainKeys Identified Mail (DKIM) [RFC6376] but
designed specifically for the verification of semantic entity data
consumed by autonomous AI agents.
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 20 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Deforth Expires 20 October 2026 [Page 1]
Internet-Draft ARP April 2026
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. Design Goals . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes from draft-deforth-arp-00 . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. DNS TXT Record Format . . . . . . . . . . . . . . . . . . . . 6
4.1. Record Name . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Record Value . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Multiple Keys . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Key Size Constraints . . . . . . . . . . . . . . . . . . 7
4.5. Cross-Domain Delegation . . . . . . . . . . . . . . . . . 7
5. Reasoning Payload . . . . . . . . . . . . . . . . . . . . . . 8
5.1. File Location and Discovery . . . . . . . . . . . . . . . 8
5.2. Required Fields . . . . . . . . . . . . . . . . . . . . . 8
5.3. Optional Sections . . . . . . . . . . . . . . . . . . . . 9
6. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 10
7. Signing Procedure . . . . . . . . . . . . . . . . . . . . . . 10
8. Verification Procedure . . . . . . . . . . . . . . . . . . . 11
8.1. Domain Binding Check . . . . . . . . . . . . . . . . . . 11
8.2. HTTP Redirect Handling . . . . . . . . . . . . . . . . . 11
8.3. Verification Algorithm . . . . . . . . . . . . . . . . . 11
8.4. Verification Result Codes . . . . . . . . . . . . . . . . 12
9. Signature Block Format . . . . . . . . . . . . . . . . . . . 13
10. Key Rotation . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Relationship to Existing Standards . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.1. DNS Security . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Key Compromise . . . . . . . . . . . . . . . . . . . . . 15
12.3. Replay and Staleness . . . . . . . . . . . . . . . . . . 15
12.4. Content Truthfulness . . . . . . . . . . . . . . . . . . 16
12.5. Narrative Injection without ARP . . . . . . . . . . . . 16
12.6. Cross-Domain Signing . . . . . . . . . . . . . . . . . . 16
12.7. Keypair Separation . . . . . . . . . . . . . . . . . . . 16
12.8. Domain Signing Policy . . . . . . . . . . . . . . . . . 17
12.9. Alternative Cryptographic Envelopes . . . . . . . . . . 18
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.1. Well-Known URI Registration . . . . . . . . . . . . . . 18
Deforth Expires 20 October 2026 [Page 2]
Internet-Draft ARP April 2026
13.2. Underscored Node Name Registration . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Complete Example . . . . . . . . . . . . . . . . . . 20
A.1. DNS TXT Record . . . . . . . . . . . . . . . . . . . . . 20
A.2. Reasoning Payload . . . . . . . . . . . . . . . . . . . . 20
A.3. Verification Steps . . . . . . . . . . . . . . . . . . . 21
Appendix B. JSON Schema . . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The proliferation of Large Language Models (LLMs) and Retrieval-
Augmented Generation (RAG) systems has fundamentally altered how
information is discovered, synthesized, and presented to users.
Unlike traditional search engines, which return ranked lists of
hyperlinks for human evaluation, generative search engines produce
direct synthesized answers by extracting and compressing data from
multiple web sources.
This architectural shift creates a critical trust gap: generative
engines heavily weight structured data signals (JSON-LD, semantic
HTML, Schema.org markup) when selecting sources for citation, but
currently have no mechanism to verify that such structured data was
actually authorized by the domain owner. Any actor can publish well-
formed structured data on any domain they control, potentially
poisoning the knowledge graph of AI systems with fabricated entity
claims, false product information, or competitor sabotage.
The Agentic Reasoning Protocol (ARP) addresses this gap by providing
a DNS-anchored cryptographic verification mechanism analogous to DKIM
[RFC6376] for email. ARP enables any consuming system to verify the
provenance and integrity of machine-readable entity claims before
incorporating them into synthesized responses.
1.1. Design Goals
Lightweight Verification requires only a DNS TXT lookup and a single
Ed25519 signature verification. No PKI infrastructure,
certificate chains, or external services are required.
DNS-Anchored Trust is rooted in the existing global DNS
infrastructure, leveraging the same anchor used by DKIM, SPF, and
DMARC.
Agent-Native The protocol is designed for consumption by autonomous
Deforth Expires 20 October 2026 [Page 3]
Internet-Draft ARP April 2026
AI agents and automated crawlers, not human users.
Self-Contained The signed payload and verification metadata are co-
located in a single JSON file, minimizing the number of network
requests required for verification.
Domain-Bound Entity claims are cryptographically bound to a specific
domain, preventing cross-domain replay attacks.
Open The protocol is fully specified in this document and requires
no proprietary software or services.
1.2. Changes from draft-deforth-arp-00
* SECURITY: Canonicalization now excludes only the signature field,
not the entire _arp_signature block. This cryptographically binds
expires_at, signed_at, and dns_selector to the payload, preventing
zombie payload attacks (Section 6).
* SECURITY: Added REQUIRED "domain" field to the payload, binding
entity claims to a specific origin domain and preventing cross-
domain replay attacks (Section 5.2).
* SECURITY: Removed "dns_record" field from the signature block.
Verifiers MUST construct the DNS query name from the retrieval
domain, not from untrusted JSON data (Section 9).
* SECURITY: Cross-domain signing now uses DNS CNAME delegation,
maintaining DNS sovereignty (Section 12.6).
* BCP 190: Changed well-known location from /reasoning.json to
/.well-known/reasoning.json per RFC 8615 (Section 5.1).
* IANA: Added registration request for _arp underscored node name
per RFC 8552 (Section 13).
* IANA: Added registration request for "reasoning.json" well-known
URI suffix per RFC 8615 (Section 13).
* NEW: Added CORS requirements for browser-based verifiers
(Section 5.1).
* NEW: Added HTTP redirect handling requirements (Section 8.2).
* NEW: Updated key rotation guidance to account for cached payloads
(Section 10).
Deforth Expires 20 October 2026 [Page 4]
Internet-Draft ARP April 2026
* NEW: Added discussion of JWS as future envelope option
(Section 12.7).
* NEW: Added keypair separation guidance for multi-protocol
deployments (Section 12.8).
* NEW: Added Domain Signing Policy for downgrade attack protection
via DNS TXT (Section 12.9).
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.
Entity The brand, organization, person, or concept described by an
ARP payload.
Entity Claims Machine-readable self-attested statements published by
the entity about itself, including identity metadata, factual
corrections, domain expertise, and content policies.
Reasoning Payload A JSON document containing the entity claims and
associated verification metadata. Served at the well-known URL
path "/.well-known/reasoning.json" on the entity's domain.
Signer The party that holds the Ed25519 private key and produces the
signature. This SHOULD be the domain owner or an entity
explicitly authorized by the domain owner via DNS delegation.
Verifier Any system that retrieves the reasoning payload and
validates the signature against the DNS-published public key.
Typical verifiers include AI agents, RAG pipelines, and search
engine crawlers.
DNS Selector A label used to construct the DNS TXT record name,
enabling multiple keys on the same domain (e.g., for key rotation
or multi-tenant configurations).
Retrieval Domain The domain from which the verifier originally
requested the reasoning payload, before any HTTP redirects. This
is the authoritative domain for DNS verification.
Deforth Expires 20 October 2026 [Page 5]
Internet-Draft ARP April 2026
3. Protocol Overview
The ARP verification flow consists of four phases:
Phase 1 - Key Registration The domain owner generates an Ed25519
keypair [RFC8032] and publishes the public key as a DNS TXT record
under a well-known subdomain: <selector>._arp.<domain>
Phase 2 - Payload Construction The domain owner constructs a
reasoning payload containing entity claims, identity metadata,
content policies, and a REQUIRED "domain" field that binds the
payload to the publishing domain.
Phase 3 - Signing The payload is canonicalized using JCS [RFC8785].
The canonicalization excludes only the "signature" field within
the _arp_signature block; all other signature metadata
(expires_at, signed_at, dns_selector) is included in the signed
data. The canonical form is signed with the Ed25519 private key.
Phase 4 - Verification A consuming AI agent retrieves the reasoning
payload, confirms the "domain" field matches the retrieval domain,
extracts the DNS selector, queries the corresponding DNS TXT
record for the public key, and validates the Ed25519 signature.
4. DNS TXT Record Format
4.1. Record Name
The DNS TXT record MUST be published at:
<selector>._arp.<domain>
where <selector> is a case-insensitive ASCII string matching the
pattern [a-zA-Z0-9._-]+ and <domain> is the fully qualified domain
name of the entity. The default selector value is "arp", yielding
the record name:
arp._arp.example.com
4.2. Record Value
The TXT record value MUST be a semicolon-delimited string of
tag=value pairs. The following tags are defined:
Deforth Expires 20 October 2026 [Page 6]
Internet-Draft ARP April 2026
+=====+==========+=======================================+
| Tag | Required | Description |
+=====+==========+=======================================+
| v | REQUIRED | Protocol version. MUST be "ARP1". |
+-----+----------+---------------------------------------+
| k | REQUIRED | Key algorithm. MUST be "ed25519". |
+-----+----------+---------------------------------------+
| p | REQUIRED | Base64-encoded raw Ed25519 public key |
| | | (32 bytes, 44 characters encoded). |
+-----+----------+---------------------------------------+
| t | OPTIONAL | Unix timestamp of key publication. |
+-----+----------+---------------------------------------+
| x | OPTIONAL | Unix timestamp of key expiration. |
+-----+----------+---------------------------------------+
Table 1
Example:
v=ARP1; k=ed25519; p=MCowBQYDK2VwAyEA...
4.3. Multiple Keys
A domain MAY publish multiple ARP TXT records using different
selectors (e.g., "arp" and "arp2026q3"). This supports key rotation
without service interruption.
4.4. Key Size Constraints
Ed25519 public keys are 32 bytes (44 characters in Base64). This
fits within the 255-byte DNS TXT record string limit defined in
[RFC1035] Section 3.3.14.
4.5. Cross-Domain Delegation
When an authorized third party (e.g., a consultancy) signs a
reasoning payload on behalf of a domain owner, the domain owner MUST
delegate trust via a DNS CNAME record:
arp._arp.client.com. CNAME arp._arp.agency.com.
This maintains the absolute sovereignty of the DNS trust anchor: the
domain owner explicitly authorizes the delegation, and the verifier
always queries the retrieval domain's DNS namespace first. The
verifier follows the CNAME transparently and retrieves the delegated
public key.
Deforth Expires 20 October 2026 [Page 7]
Internet-Draft ARP April 2026
This model mirrors DKIM's delegation approach and prevents attackers
from pointing unsigned JSON fields at arbitrary DNS records.
5. Reasoning Payload
5.1. File Location and Discovery
The reasoning payload MUST be served at the well-known URL defined in
[RFC8615]:
https://<domain>/.well-known/reasoning.json
Implementations MAY additionally serve the payload at alternative
paths provided the well-known URL also exists. Alternative paths MAY
be advertised via:
* A <link> element in the HTML head: <link rel="reasoning"
href="/.well-known/reasoning.json">
* A reference in the site's /llms.txt file.
* A Reasoning-Json directive in robots.txt.
The file MUST be served with Content-Type: application/json.
Servers SHOULD include the HTTP header Access-Control-Allow-Origin: *
when serving the reasoning payload, to enable verification by
browser-based AI agents, extensions, and verifiable-credential
wallets that operate under Cross-Origin Resource Sharing (CORS)
restrictions.
5.2. Required Fields
The reasoning payload MUST contain the following top-level fields:
Deforth Expires 20 October 2026 [Page 8]
Internet-Draft ARP April 2026
+===============+========+=====================================+
| Field | Type | Description |
+===============+========+=====================================+
| $schema | URI | MUST reference the ARP JSON Schema |
| | | [ARP-SCHEMA]. |
+---------------+--------+-------------------------------------+
| protocol | string | MUST be "Agentic Reasoning Protocol |
| | | (ARP)". |
+---------------+--------+-------------------------------------+
| version | string | Semver-compatible version string |
| | | (e.g., "1.2"). |
+---------------+--------+-------------------------------------+
| domain | string | REQUIRED. The fully qualified |
| | | domain name that is authoritative |
| | | for these entity claims. Verifiers |
| | | MUST confirm this matches the |
| | | retrieval domain (Section 8). |
+---------------+--------+-------------------------------------+
| entity | string | Canonical name of the entity (max |
| | | 200 chars). |
+---------------+--------+-------------------------------------+
| entity_claims | object | MUST contain at minimum a |
| | | "framing_context" string. |
+---------------+--------+-------------------------------------+
Table 2
5.3. Optional Sections
The payload MAY include:
* *identity:* Brand identity, tagline, core competencies, emotional
resonance attributes, and disambiguation entries
("not_to_be_confused_with").
* *corrections:* Verified factual corrections for known AI
hallucinations about this entity, each with trigger_topic,
verified_fact, evidence_url, and epistemic_scope.
* *verification:* Audit metadata including auditor identity and
timestamps.
* *authority:* Trust signals including Wikipedia, Wikidata,
LinkedIn, Crunchbase URIs, awards, and certifications.
* *content_policy:* AI training permissions (allowed, allowed-with-
attribution, disallowed, conditional), citation requirements, and
verification contact.
Deforth Expires 20 October 2026 [Page 9]
Internet-Draft ARP April 2026
* *diagnostics:* RAG pipeline telemetry tokens for ingestion
auditing, with transparency statement.
6. Canonicalization
Before signing, the payload MUST be canonicalized according to the
JSON Canonicalization Scheme (JCS) as specified in [RFC8785].
Only the "signature" field within the _arp_signature block MUST be
excluded from canonicalization. All other fields in _arp_signature
(algorithm, dns_selector, canonicalization, signed_at, expires_at)
are included in the signed data, cryptographically binding the
signature metadata to the payload.
Implementations MUST:
1. Deep-copy the payload object.
2. Remove ONLY the "signature" key from the _arp_signature object in
the copy. All other _arp_signature fields MUST remain.
3. Serialize the modified copy using JCS [RFC8785]: keys sorted
lexicographically, no whitespace, Unicode normalized per RFC 8785
Section 3.2.2.2.
4. Encode the result as UTF-8 bytes.
This approach prevents "zombie payload" attacks where an attacker
modifies unauthenticated metadata fields (e.g., extending expires_at)
while keeping the original signature valid.
7. Signing Procedure
Given a complete reasoning payload and an Ed25519 private key (32
bytes), the signing procedure is:
1. Set payload._arp_signature.algorithm = "Ed25519"
2. Set payload._arp_signature.dns_selector = selector
3. Set payload._arp_signature.canonicalization = "jcs-rfc8785"
4. Set payload._arp_signature.signed_at = current UTC timestamp
(ISO 8601)
5. Set payload._arp_signature.expires_at = signed_at + TTL
6. payload_copy = deep_copy(payload)
Deforth Expires 20 October 2026 [Page 10]
Internet-Draft ARP April 2026
7. Remove ONLY "signature" from payload_copy._arp_signature
8. canonical = JCS_Canonicalize(payload_copy)
9. canonical_bytes = UTF8_Encode(canonical)
10. signature_bytes = Ed25519_Sign(private_key, canonical_bytes)
11. signature_b64url = Base64url_Encode(signature_bytes) per
[RFC4648] Section 5, no padding
12. Set payload._arp_signature.signature = signature_b64url
The RECOMMENDED signature TTL is 90 days.
8. Verification Procedure
8.1. Domain Binding Check
Before any cryptographic verification, the verifier MUST confirm that
the "domain" field in the payload matches the domain from which the
payload was originally requested (the retrieval domain). If the
values do not match, verification MUST fail with
FAIL_DOMAIN_MISMATCH.
8.2. HTTP Redirect Handling
When the verifier encounters HTTP redirects (301, 302, 307, 308)
while retrieving the reasoning payload, the verifier MUST base the
DNS query and domain-binding check on the original requested domain,
NOT the final domain in the redirect chain. This prevents
verification bypass via open redirect vulnerabilities.
8.3. Verification Algorithm
The complete verification algorithm is:
1. Record the original retrieval domain before following any
redirects.
2. Retrieve the payload from the well-known URL.
3. Extract sig_block = payload._arp_signature
4. Validate sig_block contains all REQUIRED fields (Section 9)
5. Check: payload.domain == retrieval_domain. If mismatch: FAIL
(FAIL_DOMAIN_MISMATCH)
Deforth Expires 20 October 2026 [Page 11]
Internet-Draft ARP April 2026
6. Check: sig_block.expires_at > current_time. If expired: FAIL
(FAIL_EXPIRED)
7. Construct DNS name: sig_block.dns_selector + "._arp." +
retrieval_domain
8. Query DNS TXT record at constructed name
9. Parse TXT record value; extract p= tag (public key). If no
record: FAIL (FAIL_NO_DNS)
10. payload_copy = deep_copy(payload)
11. Remove ONLY "signature" from payload_copy._arp_signature
12. canonical = JCS_Canonicalize(payload_copy)
13. canonical_bytes = UTF8_Encode(canonical)
14. signature_bytes = Base64url_Decode(sig_block.signature)
15. public_key_bytes = Base64_Decode(dns_public_key_value)
16. result = Ed25519_Verify(public_key_bytes, signature_bytes,
canonical_bytes)
17. If result == valid: PASS. If invalid: FAIL (FAIL_INVALID)
8.4. Verification Result Codes
+======================+===================================+
| Code | Description |
+======================+===================================+
| PASS | Domain matches, DNS key found, |
| | signature valid, not expired. |
+----------------------+-----------------------------------+
| FAIL_NO_ARP | No _arp_signature block in |
| | payload. |
+----------------------+-----------------------------------+
| FAIL_DOMAIN_MISMATCH | The "domain" field does not match |
| | the retrieval domain. |
+----------------------+-----------------------------------+
| FAIL_NO_DNS | No DNS TXT record at |
| | selector._arp.domain. |
+----------------------+-----------------------------------+
| FAIL_EXPIRED | Signature expired (expires_at < |
| | current time). |
+----------------------+-----------------------------------+
Deforth Expires 20 October 2026 [Page 12]
Internet-Draft ARP April 2026
| FAIL_INVALID | Ed25519 signature verification |
| | failed. |
+----------------------+-----------------------------------+
| FAIL_UNSIGNED_POLICY | No _arp_signature present, but |
| | domain publishes p=reject policy. |
+----------------------+-----------------------------------+
Table 3
9. Signature Block Format
The _arp_signature block is a JSON object embedded in the reasoning
payload with the following fields:
+==================+==========+========+============================+
| Field | Required | Type | Description |
+==================+==========+========+============================+
| algorithm | REQUIRED | string | MUST be "Ed25519". |
+------------------+----------+--------+----------------------------+
| dns_selector | REQUIRED | string | Selector label for DNS |
| | | | TXT lookup (max 50 |
| | | | chars). |
+------------------+----------+--------+----------------------------+
| canonicalization | REQUIRED | string | MUST be "jcs-rfc8785". |
+------------------+----------+--------+----------------------------+
| signed_at | REQUIRED | string | ISO 8601 UTC timestamp |
| | | | of signing. |
+------------------+----------+--------+----------------------------+
| expires_at | REQUIRED | string | ISO 8601 UTC |
| | | | expiration timestamp. |
| | | | RECOMMENDED TTL: 90 |
| | | | days. |
+------------------+----------+--------+----------------------------+
| signature | REQUIRED | string | Base64url-encoded |
| | | | Ed25519 signature (86 |
| | | | chars without |
| | | | padding). This is the |
| | | | ONLY field excluded |
| | | | from canonicalization. |
+------------------+----------+--------+----------------------------+
Table 4
Note: The "dns_record" field present in draft-deforth-arp-00 has been
removed. Verifiers MUST construct the DNS query name from the
retrieval domain and dns_selector, never from untrusted JSON data.
Deforth Expires 20 October 2026 [Page 13]
Internet-Draft ARP April 2026
10. Key Rotation
To rotate keys without service disruption:
1. Generate a new Ed25519 keypair.
2. Publish the new public key under a new DNS selector (e.g.,
"arp2026q3._arp.example.com").
3. Re-sign the reasoning payload with the new key, updating
dns_selector accordingly.
4. Keep the old DNS TXT record published until the expires_at
timestamp of the last payload signed with the old key has passed.
This prevents verification failures for agents holding cached
copies of the previous payload.
5. After the old payload's expires_at date has passed, remove the
old DNS TXT record.
Verifiers SHOULD support checking multiple selectors. The
RECOMMENDED rotation interval is 90 days, aligned with the default
signature TTL.
11. Relationship to Existing Standards
+==============+==================================================+
| Standard | Relationship to ARP |
+==============+==================================================+
| DKIM | ARP adapts the DNS-anchored key publication and |
| [RFC6376] | CNAME delegation models from DKIM for entity |
| | claim verification rather than email |
| | authentication. |
+--------------+--------------------------------------------------+
| C2PA v2.2 | C2PA verifies media provenance via embedded |
| [C2PA] | manifests. ARP verifies textual entity claim |
| | provenance via DNS. Complementary, non- |
| | overlapping scope. |
+--------------+--------------------------------------------------+
| W3C | VCs require an Issuer-Holder-Verifier ecosystem. |
| Verifiable | ARP provides a simpler two-party (Publisher- |
| Credentials | Verifier) model for public entity claims. |
| 2.0 [W3C-VC] | |
+--------------+--------------------------------------------------+
| AIVS v1.0 | AIVS verifies what an agent DID (session/action |
| [AIVS] (W3C | integrity). ARP verifies what an agent READS |
| Community | (content provenance). Complementary: AIVS audit |
| Group) | logs plus ARP content verification form a full |
Deforth Expires 20 October 2026 [Page 14]
Internet-Draft ARP April 2026
| | end-to-end trust chain for agentic systems. |
+--------------+--------------------------------------------------+
| IETF SCITT | ARP signed payloads could be registered as SCITT |
| | transparency statements for append-only |
| | auditability. |
+--------------+--------------------------------------------------+
| Schema.org | Schema.org describes entity attributes. ARP |
| | cryptographically binds those attributes to |
| | verified domain ownership. |
+--------------+--------------------------------------------------+
Table 5
12. Security Considerations
12.1. DNS Security
ARP's trust anchor is the DNS TXT record. Without DNSSEC, an
attacker who can poison DNS responses can substitute a fraudulent
public key. Implementations SHOULD use DNSSEC-validated resolvers
where available. Implementations SHOULD also cache DNS responses
according to the record's TTL to reduce lookup frequency.
12.2. Key Compromise
If an Ed25519 private key is compromised, the attacker can sign
arbitrary payloads that will validate against the DNS-published key.
Domain owners MUST:
* Store private keys with restricted file permissions (0600).
* Rotate keys immediately on suspected compromise.
* Use the expires_at field to limit the validity window of any
signature.
* Consider hardware security modules (HSMs) or secure enclaves for
high-value domains.
12.3. Replay and Staleness
Verifiers SHOULD check the expires_at timestamp and reject expired
signatures. The RECOMMENDED TTL is 90 days. Verifiers MAY also
check the signed_at timestamp against the HTTP Last-Modified header
to detect stale payloads served from cache.
Deforth Expires 20 October 2026 [Page 15]
Internet-Draft ARP April 2026
12.4. Content Truthfulness
ARP verifies PROVENANCE (who authorized the data), not TRUTH (whether
the data is factually correct). A domain owner can sign factually
incorrect claims that will pass ARP verification. AI systems
consuming ARP-verified payloads SHOULD still cross-reference entity
claims against independent sources. The epistemic_scope field in
entity claims is designed to help AI systems distinguish between
publicly verifiable facts and proprietary internal claims.
12.5. Narrative Injection without ARP
Without ARP verification, any actor can publish reasoning payloads
containing arbitrary entity claims on any domain they control.
Regulatory frameworks such as the EU AI Act [EU-AI-ACT] Article 19
require audit trails for high-risk AI systems but do not prescribe
verification formats for ingested content. Empirical research has
demonstrated that RAG systems will cite well-structured entity claims
from previously unknown domains as primary sources within 24 hours,
regardless of domain history, traffic, or backlinks. ARP provides
the verification layer that allows consuming systems to differentiate
between authorized and unauthorized entity claims.
12.6. Cross-Domain Signing
Cross-domain signing MUST use the DNS CNAME delegation model
described in Section 4.5. The verifier always queries the retrieval
domain's DNS namespace and follows CNAME records transparently. This
maintains the absolute sovereignty of the DNS trust anchor and
prevents attacks where unsigned JSON fields are used to redirect
trust to attacker-controlled DNS.
Consuming systems MAY choose to treat CNAME-delegated signatures with
lower confidence than direct (same-domain) signatures.
12.7. Keypair Separation
When ARP is deployed alongside other verification systems that also
use Ed25519 (e.g., AIVS [AIVS] for agent session integrity),
implementations MUST NOT reuse the same Ed25519 keypair across
different verification functions. Sharing a single keypair between
content signing (ARP) and session signing (AIVS) creates a single
point of failure: compromise of one key compromises both trust
domains.
Deforth Expires 20 October 2026 [Page 16]
Internet-Draft ARP April 2026
Implementations SHOULD use separate Ed25519 keypairs for each trust
function. Where a unified identity anchor is desired,
implementations MAY use a DID Document (e.g., did:web) to bind
multiple function-specific public keys to a single domain identity:
* An "assertionMethod" key for ARP content provenance verification.
* An "authentication" key for agent session signing (e.g., AIVS).
This approach preserves key isolation while enabling cross-protocol
identity resolution. The DID Document itself can be anchored to the
domain via the did:web method, which resolves to /.well-known/
did.json on the entity's domain.
12.8. Domain Signing Policy
To protect against downgrade attacks — where an attacker strips the
_arp_signature block from a signed file and modifies the content —
domain owners MAY publish a Domain Signing Policy via DNS TXT record
at the bare _arp node:
_arp.example.com. IN TXT "v=ARP1; p=reject"
The following policy values are defined:
+========+==========+===================================+
| Policy | Value | Meaning |
+========+==========+===================================+
| none | Default | No enforcement; unsigned files |
| | | are treated normally. |
+--------+----------+-----------------------------------+
| warn | Advisory | Verifiers SHOULD log a warning if |
| | | the payload is unsigned. |
+--------+----------+-----------------------------------+
| reject | Strict | Verifiers MUST treat unsigned |
| | | payloads as FAIL_UNSIGNED_POLICY. |
+--------+----------+-----------------------------------+
Table 6
Verification flow for unsigned payloads:
1. Verifier encounters a reasoning payload without an _arp_signature
block.
2. Verifier queries the DNS TXT record at _arp.<retrieval_domain>.
Deforth Expires 20 October 2026 [Page 17]
Internet-Draft ARP April 2026
3. If a record with p=reject is present, the verifier MUST reject
the unsigned payload (FAIL_UNSIGNED_POLICY).
4. If no policy record exists, the verifier treats the payload as
unsigned (no cryptographic trust, but not rejected).
This follows the same progressive enforcement model as DMARC
(p=reject) [RFC6376] and HTTP Strict Transport Security (HSTS).
12.9. Alternative Cryptographic Envelopes
This specification defines a custom _arp_signature block for
simplicity and clarity. Future versions MAY consider adopting JSON
Web Signature (JWS) [RFC7515] with the Unencoded Payload Option
[RFC7797] as an alternative envelope format. This would provide
cryptographic agility and enable use of battle-tested standard
libraries, while preserving the human-readable cleartext JSON payload
that JCS canonicalization achieves. The dns_selector, expires_at,
and signed_at fields would map to the JWS Protected Header.
13. IANA Considerations
13.1. Well-Known URI Registration
This document requests IANA to register the following well-known URI
suffix in the "Well-Known URIs" registry established by [RFC8615]:
URI Suffix reasoning.json
Change Controller IETF
Reference Section 5.1 of [this document]
Status permanent
13.2. Underscored Node Name Registration
This document requests IANA to register the following entry in the
"Underscored and Globally Scoped DNS Node Names" registry established
by [RFC8552]:
RR Type TXT
_NODE NAME _arp
Reference Section 4.1 of [this document]
14. References
Deforth Expires 20 October 2026 [Page 18]
Internet-Draft ARP April 2026
14.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource
Records through "Underscored" Naming of Attribute Leaves",
BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
<https://www.rfc-editor.org/info/rfc8552>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
14.2. Informative References
[AIVS] Stone, B., "Agentic Integrity Verification Specification
v1.0", W3C Community Group Draft, March 2026,
<https://github.com/bkauto3/Conduit/blob/main/spec/
AIVS.md>.
[ARP-SCHEMA]
Deforth, S., "ARP v1.2 JSON Schema", April 2026,
<https://arp-protocol.org/schema/v1.2.json>.
Deforth Expires 20 October 2026 [Page 19]
Internet-Draft ARP April 2026
[C2PA] Coalition for Content Provenance and Authenticity, "C2PA
Technical Specification v2.2", 2025,
<https://c2pa.org/specifications/specifications/2.2/specs/
C2PA_Specification.html>.
[EU-AI-ACT]
European Parliament, "Regulation (EU) 2024/1689 laying
down harmonised rules on artificial intelligence", 2024.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload
Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,
<https://www.rfc-editor.org/info/rfc7797>.
[W3C-VC] Sporny, M., "Verifiable Credentials Data Model v2.0",
W3C Recommendation, May 2025,
<https://www.w3.org/TR/vc-data-model-2.0/>.
Appendix A. Complete Example
A.1. DNS TXT Record
arp._arp.example.com. 3600 IN TXT (
"v=ARP1; k=ed25519; "
"p=MCowBQYDK2VwAyEA5d7jb7bkTVk5"
"YQ4nFmYY7ClpCddGdSRJkGb3ELWuos=")
A.2. Reasoning Payload
Deforth Expires 20 October 2026 [Page 20]
Internet-Draft ARP April 2026
{
"$schema": "https://arp-protocol.org/schema/v1.2.json",
"protocol": "Agentic Reasoning Protocol (ARP)",
"version": "1.2",
"domain": "example.com",
"entity": "Example Corp",
"entity_claims": {
"framing_context": "Example Corp is a technology ..."
},
"content_policy": {
"ai_training": "allowed-with-attribution",
"citation_required": true
},
"_arp_signature": {
"algorithm": "Ed25519",
"dns_selector": "arp",
"canonicalization": "jcs-rfc8785",
"signed_at": "2026-04-06T14:00:00Z",
"expires_at": "2026-07-05T14:00:00Z",
"signature": "P1lCPaHn_WLXdidBfxLXqBBid1G..."
}
}
A.3. Verification Steps
1. Record retrieval domain: example.com
2. Retrieve https://example.com/.well-known/reasoning.json (follow
redirects, keep original domain)
3. Check: payload.domain == "example.com" (PASS)
4. Check: expires_at > now (PASS)
5. Extract dns_selector = "arp" from _arp_signature
6. Query DNS TXT at: arp._arp.example.com
7. Parse p= tag to obtain public key bytes
8. Copy payload, remove ONLY _arp_signature.signature
9. JCS-canonicalize the modified copy
10. Ed25519_Verify(public_key, signature, canonical_bytes)
11. Result: PASS
Deforth Expires 20 October 2026 [Page 21]
Internet-Draft ARP April 2026
Appendix B. JSON Schema
The normative JSON Schema for ARP v1.2 payloads is published at:
https://arp-protocol.org/schema/v1.2.json
The schema defines validation rules for all required and optional
fields, including type constraints, maximum lengths, enumerated
values, and format requirements. Implementations SHOULD validate
payloads against the schema before signing and before processing
entity claims.
Acknowledgements
The author thanks the W3C Agentic Integrity Verification
Specification Community Group for their complementary work on agent
session integrity, and the broader Generative Engine Optimization
(GEO) community for empirical validation of the content provenance
gap that ARP addresses.
The security improvements in this revision were informed by detailed
technical review highlighting the signature metadata exclusion flaw
and cross-domain replay vulnerability in the initial draft.
The keypair separation guidance was informed by feedback from Ben
Stone (SwarmSync.AI) during AIVS interoperability discussions,
highlighting the single-point-of-failure risk of shared Ed25519
keypairs across verification protocols.
Author's Address
Sascha Deforth
TrueSource
Duesseldorf
Germany
Email: hello@truesource.studio
URI: https://arp-protocol.org
Deforth Expires 20 October 2026 [Page 22]