]> TrueSource

Duesseldorf Germany hello@truesource.studio https://arp-protocol.org

Applications and Real-Time Internet Engineering Task Force AI verification DNS Ed25519 entity claims RAG LLM provenance 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 , JSON Canonicalization Scheme (JCS) , and DNS TXT records to establish a chain of trust analogous to DomainKeys Identified Mail (DKIM) but designed specifically for the verification of semantic entity data consumed by autonomous AI agents.

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 for email. ARP enables any consuming system to verify the provenance and integrity of machine-readable entity claims before incorporating them into synthesized responses.

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 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.

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).
• 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).

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 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.

Protocol Overview The ARP verification flow consists of four phases:

Phase 1 - Key Registration

The domain owner generates an Ed25519 keypair 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 . 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.

DNS TXT Record Format

Record Name The DNS TXT record MUST be published at: ._arp. ]]> 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:

Record Value The TXT record value MUST be a semicolon-delimited string of tag=value pairs. The following tags are defined:

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.

Example:

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.

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 Section 3.3.14.

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: 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. This model mirrors DKIM's delegation approach and prevents attackers from pointing unsigned JSON fields at arbitrary DNS records.

Reasoning Payload

File Location and Discovery The reasoning payload MUST be served at the well-known URL defined in : /.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.

Required Fields The reasoning payload MUST contain the following top-level fields:

Field	Type	Description
$schema	URI	MUST reference the ARP JSON 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.

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.
• diagnostics: RAG pipeline telemetry tokens for ingestion auditing, with transparency statement.

Canonicalization Before signing, the payload MUST be canonicalized according to the JSON Canonicalization Scheme (JCS) as specified in . 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 : 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.

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)
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 Section 5, no padding
12. Set payload._arp_signature.signature = signature_b64url

The RECOMMENDED signature TTL is 90 days.

Verification Procedure

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.

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.

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)
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)

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).
FAIL_INVALID	Ed25519 signature verification failed.
FAIL_UNSIGNED_POLICY	No _arp_signature present, but domain publishes p=reject policy.

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.

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.

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.

Relationship to Existing Standards

Standard	Relationship to ARP
DKIM	ARP adapts the DNS-anchored key publication and CNAME delegation models from DKIM for entity claim verification rather than email authentication.
C2PA v2.2	C2PA verifies media provenance via embedded manifests. ARP verifies textual entity claim provenance via DNS. Complementary, non-overlapping scope.
W3C Verifiable Credentials 2.0	VCs require an Issuer-Holder-Verifier ecosystem. ARP provides a simpler two-party (Publisher-Verifier) model for public entity claims.
AIVS v1.0 (W3C Community Group)	AIVS verifies what an agent DID (session/action integrity). ARP verifies what an agent READS (content provenance). Complementary: AIVS audit logs plus ARP content verification form a full 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.

Security Considerations

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.

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.

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.

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.

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 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.

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.

Keypair Separation When ARP is deployed alongside other verification systems that also use Ed25519 (e.g., 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. 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.

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: 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.

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>.
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) and HTTP Strict Transport Security (HSTS).

Alternative Cryptographic Envelopes This specification defines a custom _arp_signature block for simplicity and clarity. Future versions MAY consider adopting JSON Web Signature (JWS) with the Unencoded Payload Option 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.

IANA Considerations

Well-Known URI Registration This document requests IANA to register the following well-known URI suffix in the "Well-Known URIs" registry established by :

URI Suffix

reasoning.json

Change Controller

IETF

Reference

Section 5.1 of [this document]

Status

permanent

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 :

RR Type

TXT

_NODE NAME

_arp

Reference

Section 4.1 of [this document]

References Normative References Informative References Coalition for Content Provenance and Authenticity European Parliament

Complete Example

DNS TXT Record

Reasoning Payload

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

JSON Schema The normative JSON Schema for ARP v1.2 payloads is published at: 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.