ARP Protocol SOP

Appearance

IETF Internet-Draft ​

Fresh

Summary of draft-deforth-arp-01, submitted to the IETF in April 2026. Standards Track. This page summarizes the draft for protocol implementors. The full draft text is the authoritative source.

Abstract ​

The Agentic Reasoning Protocol defines a lightweight mechanism for domain owners to publish cryptographically-signed, machine-readable entity claims that AI agents can use to improve the accuracy of entity-related responses. The protocol binds entity claims to domain ownership using Ed25519 signatures (RFC 8032) and DNS TXT records, following a pattern analogous to DKIM (RFC 6376) but applied to semantic entity data rather than email authentication.

The document specifies: the JSON document format at /.well-known/reasoning.json, the cryptographic signing algorithm and verification procedure, DNS TXT record format for public key distribution, IANA considerations for the .well-known URI and DNS label registrations, and security considerations covering replay attacks, key compromise, and social engineering.

Status: Internet-Draft, work in progress. Not an IETF Standard.

Background ​

The IETF draft formalizes work that began as a community protocol. The primary motivation for pursuing IETF standardization:

  • Interoperability. An IETF RFC creates a stable, version-independent reference that AI system implementors can implement against without tracking community documentation changes.
  • DNS registration. The _arp DNS label requires IANA registration to avoid conflicts with other uses of that label.
  • Well-known URI registration. The /.well-known/reasoning.json path requires IANA registration in the Well-Known URIs registry (RFC 8615).
  • Cryptographic algorithm clarity. The IETF process subjects the algorithm choices to security review.

Key Sections of the Draft ​

Section 1 - Protocol Overview ​

The draft frames ARP as a pull-based protocol. AI systems periodically fetch reasoning.json files from domains they encounter. There is no push mechanism and no central registry. Domain owners publish at the well-known URI and the protocol handles discovery through the conventions defined in the spec.

The draft explicitly scopes ARP to entity self-description. It is not a general-purpose AI agent communication protocol. It does not define how AI systems must act on the information in a reasoning.json file.

Section 2 - JSON Document Format ​

The draft incorporates the ARP v1.2 schema by reference and adds normative language around the MUST/SHOULD/MAY requirements for each field. The distinction between required and optional fields in the community schema translates to MUST/MAY language in the RFC context.

Key normative requirements in the draft:

  • Implementations MUST support UTF-8 encoding
  • Implementations MUST reject files larger than 100KB
  • Servers MUST include Access-Control-Allow-Origin: *
  • Parsers MUST ignore unknown properties (forward compatibility)
  • Parsers MUST validate against the schema version indicated by $schema

Section 3 - Cryptographic Binding ​

The draft specifies the complete Ed25519 signing and verification procedure. It defers to RFC 8032 for the Ed25519 algorithm specification and RFC 8785 for JCS canonicalization.

The draft defines "authorship verification" as distinct from "content verification." A valid signature proves the file was signed by the party controlling the private key corresponding to the DNS-published public key. It does not prove the content is accurate.

The signing procedure in the draft is identical to the ARP v1.2 spec (Section 13): remove _arp_signature, serialize with JCS, sign with Ed25519 private key, base64url-encode, add _arp_signature back.

Section 4 - DNS Integration ​

The draft specifies the DNS TXT record format and the lookup procedure.

DNS TXT record format:

_arp.{domain} TXT "v=ARP1; k=ed25519; p={base64url-public-key}; kid={key-id}"

The draft requires:

  • The v=ARP1 version tag must appear first in the TXT record value
  • Implementations MUST support multiple TXT records at _arp.{domain} to allow key rotation
  • Key IDs must be unique within a domain's DNS records
  • Implementations MUST treat a missing DNS record as an unverified (but not invalid) ARP file

Key rotation is handled by publishing a new DNS record with a new kid, signing a new reasoning.json with the new key, and allowing a transition period before removing the old DNS record.

Section 5 - Security Considerations ​

The draft's security analysis identifies three primary threat vectors:

Replay Attacks

An adversary who captures a valid reasoning.json file and its _arp_signature could replay it at a different domain. The draft mitigates this by requiring that verifiers check the domain field in the ARP file against the domain from which the file was fetched. A file fetched from attacker.com that contains "domain": "victim.com" fails verification.

Additionally, the signed_at timestamp in _arp_signature allows implementations to reject files with signatures older than a configurable threshold (the draft suggests 90 days as a reasonable default, though this is not normative).

Key Compromise

If an entity's Ed25519 private key is compromised, an adversary could publish a malicious reasoning.json. The draft recommends:

  • Store private keys in hardware security modules or secrets managers
  • Rotate keys on a scheduled basis (annually recommended)
  • Monitor DNS for unauthorized new _arp TXT records

Key revocation is handled by removing the DNS TXT record for the compromised key ID. Once removed, any signature using that key ID fails verification.

Social Engineering

The most significant risk the draft identifies is social engineering at the domain level. An adversary who gains control of a domain (via DNS hijacking, domain expiration, or registrar compromise) gains the ability to publish any reasoning.json for that domain. The draft notes this is the same threat model as websites generally and defers to existing domain security practices (DNSSEC, registrar 2FA, domain locking).

The draft also notes that ARP's self-attestation trust model means that even a fully valid, uncompromised ARP file should be treated as a claimed fact rather than a verified fact. The ethics policy and community validator complement the cryptographic layer.

Section 6 - IANA Considerations ​

The draft requests two IANA registrations:

Well-Known URI Registration (RFC 8615)

URI suffix: reasoning.json
Change controller: IETF
Specification document(s): [this document]
Status: permanent

DNS Label Registration

_arp - Used for ARP public key distribution in DNS TXT records
Reference: [this document]

Relationship to DKIM (RFC 6376) ​

The draft explicitly draws the analogy to DKIM. Both protocols:

  • Use DNS TXT records to publish public keys
  • Bind a published artifact to domain ownership via cryptographic signatures
  • Allow key rotation through multiple DNS records
  • Do not prevent false claims, only false authorship claims

The primary difference is the domain of application. DKIM authenticates email headers. ARP authenticates JSON entity data consumed by AI agents.

The draft borrows DKIM's v= version tag pattern for the DNS TXT record format and adopts similar key rotation conventions. However, ARP uses Ed25519 rather than RSA, reflecting more modern cryptographic practice.

Implementation Notes for Developers ​

The draft contains normative guidance that goes beyond the community specification:

  • additionalProperties in the JSON Schema MUST be false to prevent property injection
  • Implementations MUST perform string normalization (NFC) before length checks
  • Implementations SHOULD cache reasoning.json responses according to HTTP caching headers
  • Implementations SHOULD re-fetch files when the cached version's verification.next_audit date has passed
  • Implementations MUST NOT retry failed fetches more than once per 24 hours per domain (rate limiting)

Current Status ​

The draft was submitted in April 2026. It has been assigned to the HTTPAPI working group for review. An initial review period of 90 days is expected before any revisions.

The community ARP specification (v1.2) will remain in sync with the IETF draft. When the RFC is published (if accepted), the community specification will update to reference the RFC number.