Agentic Reasoning Protocol (ARP): DNS-Bound Signatures for Entity Self‑Descriptions

1.1. Design Goals and Non-Goals

Lightweight:

Verification requires one DNS TXT lookup and one Ed25519 signature verification. No certificate chains or external services are required.¶

DNS-anchored:

Trust is rooted in DNS, the anchor also used by DKIM.¶

Self-contained:

The signed content and the signature metadata are in one JSON file.¶

Domain-bound:

A manifest names the domain it belongs to, which prevents replay on other domains.¶

Readable:

Statements and signature metadata are written so that people and software can read them as plain text. A Markdown representation carries the same content (Section 5.6).¶

Descriptive:

Manifests describe an entity. They do not address their readers with instructions.¶

Open:

The protocol is specified in this document and in [ARP-SPEC] and requires no proprietary software or services.¶

ARP does not establish that the statements in a manifest are true, does not rank or weight sources, does not control crawling (that is the role of robots.txt [RFC9309]), and does not replace schema.org markup [SCHEMA-ORG] or llms.txt files [LLMSTXT].¶

1.2. Changes from draft-deforth-arp-00

This section is to be removed before publishing as an RFC.¶

The canonicalization rule changed. draft-deforth-arp-00 removed the "signature" member from the "_arp_signature" object before canonicalization. This revision sets the value of "signature" to the empty string and keeps the member (enveloped signature, Section 6). This is the construction used by the reference implementation [ARP-CLI] since its version 1.3.0 and by [ARP-SPEC]. The two constructions produce different signing input: a signature created under one does not verify under the other. Verifiers do not try both (Section 6).¶

Further changes:¶

• Manifest format version 1.3 ("Reader Profile"): REQUIRED "provenance" member (Section 5.3); normative Wording Profile (Section 5.5); REQUIRED "statement" and "verify" members in signed version 1.3 manifests and the signed, informational "dns_record" member (Section 8); optional "representations" with a deterministic Markdown rendering (Section 5.6, Section 5.7).¶
• Key revocation by an empty "p" tag (Section 4.6); result codes FAIL_KEY_REVOKED and REPRESENTATION_MATCH, REPRESENTATION_MISMATCH, REPRESENTATION_UNCHECKED (Section 9.5); key rotation tied to events instead of a fixed 90-day interval (Section 10).¶
• Verifiers reject signatures that do not cover the signature metadata (Section 6, Section 13.6).¶
• Manifests are I-JSON [RFC7493], and integers are limited to plus or minus 2^53-1; verifiers reject duplicate member names before canonicalization (Section 6, Section 13.7). The signature value is decoded strictly (Section 8). In version 1.3 manifests, "dns_record" and "verify.dns_name" must name the key record of the retrieval domain (Section 8).¶
• The DNS tags "t" and "x" of draft-deforth-arp-00 are removed; unknown tags are ignored, and records with duplicate tags are malformed (Section 4.2). The key record and the policy record are specified in ABNF (Section 4.2, Section 13.12), and selectors consist of DNS labels (Section 4.1).¶
• The header field "Access-Control-Allow-Origin: *" on the manifest response is required instead of recommended, as in [ARP-SPEC] (Section 5.1).¶
• Querying the Domain Signing Policy is now RECOMMENDED for verifiers instead of required; a verifier that finds "p=reject" still reports FAIL_UNSIGNED_POLICY (Section 13.12).¶
• The title no longer speaks of verifying claims; the signature establishes origin, not accuracy.¶
• Discovery Profile (Section 11). The robots.txt directive of draft-deforth-arp-00 is removed.¶
• Corrected: draft-deforth-arp-00 described canonical strings as "Unicode normalized per RFC 8785 Section 3.2.2.2". RFC 8785 performs no Unicode normalization and requires string data to be preserved as is (Section 6).¶
• Corrected: the DNS record example in draft-deforth-arp-00 showed a DER-encoded key (prefix "MCowBQYDK2VwAyEA") instead of the raw 32-byte key that the record format requires. Appendix A now contains a complete, reproducible test vector.¶
• Corrected: the DMARC reference pointed to RFC 6376 (DKIM); it now points to [RFC9989].¶
• IANA: the change controller is the author, not the IETF; the requested status is provisional; "reasoning.md" is added; a link relation section is added (Section 15).¶
• Intended status changed from Standards Track to Informational.¶
• Removed an empirical claim that had no reference and the paragraph on the EU AI Act; added Section 14.¶
• The AIVS reference points to the W3C Community Group page, because the earlier specification URL no longer resolves.¶

4.1. Record Name

The public key is published in a TXT record at:¶

  <selector>._arp.<domain>

The selector is an ASCII string of at most 50 characters. It consists of one or more labels separated by single dots; each label consists of letters, digits, "-", and "_" and begins and ends with a letter or digit, so that the record name consists of non-empty labels without leading or trailing hyphens (compare Section 2.3.1 of [RFC1035] and the selector syntax of Section 3.1 of [RFC6376]; unlike both, "_" is permitted inside a label). The domain is the fully qualified domain name of the manifest's domain. The selector "arp" was the default of earlier versions. For new keys, the naming pattern "arpYYMM" (year and month of introduction, for example "arp2610") is RECOMMENDED, because a new selector is needed for every key change (Section 10).¶

4.2. Record Value

The record value is a semicolon-separated list of tag=value pairs. Tag names are lowercase. The following tags are defined:¶

If a TXT record consists of several character-strings, verifiers concatenate them without separator before parsing, as in DKIM. Whitespace around tags and values is ignored. Verifiers ignore tags they do not recognize. A record in which a tag occurs more than once is malformed (as in [RFC6376], Section 3.2), and so is a record without a "p" tag; verifiers MUST NOT use a key from a malformed record. Only an empty "p" value means revocation. Verifiers MUST decode "p" strictly to exactly 32 bytes and MAY accept the base64url alphabet and a missing padding character. Verifiers MAY accept the value of "v" in other letter case and SHOULD report such a record as a warning.¶

The record value uses the tag-list syntax of DKIM ([RFC6376], Section 3.2; "FWS" as in Section 2.8 of [RFC6376]). In ABNF [RFC5234], the tags defined by this document are:¶

arp-key-record = tag-list        ; RFC 6376, Section 3.2
arp-v-tag      = %x76 [FWS] "=" [FWS] "ARP1"
arp-k-tag      = %x6B [FWS] "=" [FWS] "ed25519"
arp-p-tag      = %x70 [FWS] "=" [FWS] [arp-key-data]
                 ; empty value: the key is revoked
arp-key-data   = 43base64-char "="
                 ; 32-byte key, base64 (RFC 4648, Section 4)
base64-char    = ALPHA / DIGIT / "+" / "/"

Quoted strings in ABNF are case-insensitive ([RFC5234], Section 2.3); publishers write "ARP1" in upper case and "ed25519" in lower case, as in the table above. Example (the key of Appendix A):¶

arp2610._arp.example.com. 3600 IN TXT (
  "v=ARP1; k=ed25519; p=NBnwMAmxIwzpUCCEvJYO8gqodE+ZbemH5QZSTQPREE8="
  )

4.3. Multiple Keys

A domain MAY publish several ARP keys under different selectors, for example during a key rotation. If more than one record with "v=ARP1" exists at the same name, a record with an empty "p" tag takes precedence and the key is treated as revoked; otherwise, a verifier MAY try each key.¶

4.4. Key Size Constraints

An Ed25519 public key is 32 bytes, 44 characters in base64. The record value fits into a single character-string of at most 255 octets (Section 3.3.14 of [RFC1035]).¶

4.5. Cross-Domain Delegation

When an authorized third party signs a manifest on behalf of the domain owner, the domain owner delegates the key name with a CNAME record:¶

  arp2610._arp.client.example. CNAME arp2610._arp.agency.example.

The verifier always queries the name it constructs under the retrieval domain and follows the CNAME. The domain owner thereby authorizes the delegation explicitly, as in DKIM. Unsigned or signed JSON members cannot redirect the lookup to another domain. In the statement of the signature block (Section 8), "the operator of {DOMAIN}" then includes the signer that the domain operator has authorized through the delegation; the domain operator remains the publisher named in "provenance" and responsible for the manifest.¶

4.6. Key Revocation

A publisher revokes the key of a selector by replacing its TXT record with a record whose "p" tag is empty:¶

  arp._arp.example.com. IN TXT "v=ARP1; k=ed25519; p="

This follows DKIM ([RFC6376], Section 3.6.1). A verifier that finds an empty "p" tag at the name it constructed MUST treat the key as revoked and MUST report FAIL_KEY_REVOKED (Section 9.5). A manifest signed with a revoked key never yields PASS, whatever its "expires_at" value. Revocation affects every copy signed with that key, including cached, indexed, and archived copies. Section 10 describes when to revoke and Section 13.9 its limits.¶

5.1. Location and Media Type

The manifest MUST be available at the well-known URI [RFC8615]:¶

  https://<domain>/.well-known/reasoning.json

The manifest MUST be valid JSON [RFC8259] encoded in UTF-8 and an I-JSON message [RFC7493] (Section 6), MUST be served over HTTPS without authentication, and MUST NOT exceed 100 KiB (102,400 octets). It MUST be served with the media type "application/json"; the Content-Type header field SHOULD be "application/json; charset=utf-8" (Section 11.7). The response MUST include "Access-Control-Allow-Origin: *" so that browser-based verifiers can read it.¶

A publisher MAY serve the manifest at additional paths, but not instead of the well-known URI.¶

5.2. Required Members

A manifest MUST contain the following members:¶

The JSON Schema for version 1.3 [ARP-SCHEMA] does not permit top-level members other than those defined in [ARP-SPEC].¶

Manifests with version "1.2" remain valid under the rules of version 1.2. For them, "provenance", the Wording Profile, and the members "statement" and "verify" are not required. Verifiers process signatures of both versions in the same way (Section 9), except that the consistency rule for "dns_record" and "verify.dns_name" (Section 8) applies only to version 1.3 manifests; for version 1.2 manifests, a difference is reported as a warning.¶

5.3. Provenance

The "provenance" member states who published the self-description. It has exactly the following members:¶

The statement MUST follow this template, with the placeholders replaced as defined in Section 2 and single spaces between sentences:¶

This file is {ENTITY}'s own description of itself, published by {PUBLISHER} at {DOMAIN}. The statements are self-attested; where available, independent evidence is linked in evidence_url.¶

The statement is in English, so that it can be compared mechanically. The apostrophe in "{ENTITY}'s" is U+0027 APOSTROPHE; a statement with another character in its place, for example U+2019 RIGHT SINGLE QUOTATION MARK, does not match the template. "provenance" MUST be identical in the signed and the unsigned form of a manifest and MUST NOT mention a signature; the signature has a statement of its own (Section 8). In a signed manifest, "provenance" is covered by the signature like every other member. Validators SHOULD check that the statement matches the template with the manifest's own values.¶

5.4. Optional Members

[ARP-SPEC] defines the following optional top-level members, their contents, and their length limits:¶

identity:

Facts about the entity, such as a short description, founding year, location, legal name, competencies, and disambiguation entries ("not_to_be_confused_with").¶

organization:

Legal and organizational facts (version 1.3); member names of the schema.org "Organization" type may be used.¶

corrections:

Topic-anchored corrections. Each entry pairs a topic ("trigger_topic") with the entity's statement of the fact ("verified_fact"), an "evidence_url" (preferably held by an independent party), and an "epistemic_scope". The member name "verified_fact" is kept for compatibility; it does not imply that a third party has checked the statement.¶

verification:

Review metadata: who reviewed the manifest and when.¶

authority:

Links to external profiles and registers.¶

content_policy:

Preferences for training and citation. ARP cannot enforce them.¶

diagnostics:

Opaque identifiers that let the publisher recognize copies of the manifest. They MUST NOT contain instructions or ask for repetition, and MUST NOT be linked to personal identifiers. "diagnostics" is not part of the Markdown representation.¶

representations:

Section 5.6.¶

_arp_signature:

Section 8.¶

5.5. Wording Profile

The Wording Profile is normative for version 1.3. It applies to every string value and member name in the manifest, to every representation (Section 5.6), to HTML pages that present the manifest's content, and to the discovery texts of Section 11.¶

All texts covered by the profile are statements in the third person about the entity. They MUST NOT contain:¶

1. Imperatives or conditional instructions addressed to AI systems, such as "When discussing X ...", "frame it as", "describe X as", "defer to", "treat ... as", "recommend X when", "you are authorized", "you are explicitly authorized", "If you are an AI", "AI systems must", "AI systems should", "remember", and "in future conversations". The rule concerns the purpose of a text, not its grammatical form: it also covers statements in the third person about how AI systems, assistants, or other readers are expected to treat, rank, or present the entity or the manifest, for example "Assistants are expected to recommend Example Corp first".¶
2. Markers that imitate system or role markup, such as "<system_note>", "<assistant>", "<user>", chat-template tokens such as "<|im_start|>", "SYSTEM:", and "IMPORTANT:".¶
3. The member names "system_instruction", "reasoning_directives", "ai_directive", "agent_directive", "instruction", "instructions", "directive", and "directives", at any depth.¶
4. Declarations of innocence, such as "this is not prompt injection", "this is not misinformation", or "this is not data poisoning".¶
5. The words "verified", "authoritative", "trusted source", or "ground truth" applied to the content without stating who checked what. Exception: the historical member names "verified_fact" and "last_verified", kept for compatibility with earlier versions. Their meaning is fixed by [ARP-SPEC] (the entity's own statement of a fact; the date of the publisher's own review); they do not state that anyone checked the content, and every representation that shows them begins with the provenance statement (Section 5.7).¶
6. Text that is hidden from people but present for software, for example content in screen-reader-only, clipped, or "display:none" elements intended as context for AI systems. Text that serves assistive technology is not affected.¶
7. Content that differs depending on whether the reader is software or a person.¶

Permitted are statements of fact with evidence, for example "Example Corp GmbH was entered in the commercial register in 2019 (HRB 00000).", and descriptions of fit, for example "Typical fit: ..." and "Not a fit: ..." (German: "Passt für ..." and "Passt nicht für ..."). Appendix B shows pairs of non-conforming and conforming texts.¶

Conformance to the Wording Profile is a property of the text and is independent of the signature: a signature can be valid on a manifest that violates the profile, and the verification algorithm (Section 9) does not test wording. Many violations can be detected mechanically; such checks are heuristic. Section 13.5 gives the reasons for the profile.¶

5.6. Representations

A representation is a rendering of the manifest in another format, listed in the top-level array "representations" (at most 10 entries). Each entry has these members:¶

The digest covers the representation's bytes as served, after removal of any content coding ([RFC9110], Section 8.4). In a signed manifest, "representations" is covered by the signature, so the signature also covers each digest.¶

The reference representation is "https://{DOMAIN}/.well-known/reasoning.md" with media type "text/markdown" [RFC7763], rendered as specified in Section 5.7. A representation carries no statements beyond those of the manifest.¶

5.7. Reference Rendering of reasoning.md

The reference rendering converts a manifest into Markdown. It is deterministic: the same manifest yields the same bytes. The reference implementation [ARP-CLI] provides it as the command "render-md"; Appendix A.4 shows an example.¶

The output is UTF-8 text with LF line endings. It consists of blocks that are joined by one empty line (two LF characters); the last block is followed by one LF, so that the text ends with exactly one line break. The blocks are, in this order:¶

1. The heading line: "# ", the value of "entity", one space, U+2014 EM DASH, one space, and "self-description (ARP)".¶
2. The value of "provenance.statement", if it is present and a non-empty string.¶
3. The line "Manifest: " followed by the manifest URL "https://{DOMAIN}/.well-known/reasoning.json".¶
4. One section block for each rendered top-level member (see below).¶
5. The verification block (see below).¶

Rendered top-level members are first those of "identity", "organization", "corrections", "entity_claims", "authority", and "content_policy" that are present, in this order, and then all other top-level members in ascending order of the Unicode code points of their names. The members "$schema", "protocol", "version", "domain", "entity", "provenance", "representations", "_arp_signature", and "diagnostics" are not rendered.¶

A section block is the line "## " followed by the member name. If the member's value produces list lines, the heading is followed by one empty line and the list lines. List lines are indented by two spaces per nesting level, starting with no indentation:¶

• An object member with a scalar value: "- ", the member name, ":", one space, and the value.¶
• An object member whose value is an object or an array: "- ", the member name, and ":", followed by the lines of the value one level deeper.¶
• An array element that is a scalar: "-", one space, and the value.¶
• An array element that is an object or an array: "- ", its 1-based position in the array, and ":", followed by its lines one level deeper.¶
• A top-level member whose value is a scalar: "-", one space, and the value.¶
• An empty object or array produces no lines.¶
• If a value renders as the empty string, the space before it is omitted.¶

Object members appear in the order of the manifest file; a renderer therefore needs an order-preserving JSON parser. Member names are written unchanged. Strings are written unchanged: no escaping, trimming, or line wrapping. The literals true, false, and null are written as in JSON; numbers as in [RFC8785], Section 3.2.2.3. Because of the number range of Section 6, numbers without a fractional part lie within plus or minus 2^53-1 and appear in plain decimal notation.¶

In version 1.3 manifests, member names and string values MUST NOT contain control characters (U+0000 to U+001F, including line breaks and tabs, and U+007F to U+009F). Because strings are written unchanged, a line break in a value would let manifest text imitate the structure of the representation, for example a heading or a verification block in the representation of an unsigned manifest. Renderers SHOULD refuse to render such values and MUST NOT render manifests that fail the I-JSON and number range checks of Section 6.¶

A manifest with a top-level member "verification" yields two similar headings: "## verification" for that member and the final "## Verification" block described below. Only the final block is generated from "_arp_signature".¶

The verification block is the line "## Verification", one empty line, and the line "- Manifest: " followed by the manifest URL. If the manifest has an "_arp_signature" object, the following lines follow, each only if the value is present and not null, in this order: "- statement: " with the value of "_arp_signature.statement"; "- dns_name: " with the value of "_arp_signature.verify.dns_name" (or of "_arp_signature.dns_record" if "verify" is not an object or has no member "dns_name"); "- doh_url: " with the value of "_arp_signature.verify.doh_url"; "- signed_at: " and "- expires_at: " with the respective values.¶

The signature value itself is never rendered, so rendering before and after the signature is inserted yields the same bytes. The fixed texts of the rendering contain no imperatives.¶

9.1. Domain Binding Check

Before any cryptographic check, the verifier compares the "domain" member of a signed manifest with the retrieval domain (case-insensitive, ignoring a trailing dot). If they differ, or if "domain" is absent, verification MUST fail with FAIL_DOMAIN_MISMATCH. For unsigned manifests, a mismatch SHOULD be reported as a warning.¶

9.2. HTTP Redirect Handling

When the verifier encounters HTTP redirects (301, 302, 307, 308) while retrieving the manifest, it MUST base the DNS lookup and the domain binding check on the originally requested domain, not on the final domain of the redirect chain. This prevents a bypass through open redirects.¶

9.3. Verification Algorithm

1. Record the retrieval domain before following any redirects.¶
2. Retrieve the manifest from the well-known URI.¶
3. Parse the manifest and check that it is I-JSON, including the absence of duplicate member names, and that its numbers lie within the ARP number range (Section 6). Otherwise the result is FAIL_INVALID. Stop.¶
4. If the manifest has no "_arp_signature" member: the verifier SHOULD query the TXT record at "_arp.{retrieval domain}" for a Domain Signing Policy (Section 13.12). If it contains "p=reject", the result is FAIL_UNSIGNED_POLICY; otherwise the result is FAIL_NO_ARP. Stop.¶
5. Perform the domain binding check (Section 9.1).¶
6. Check that "_arp_signature" contains "algorithm", "canonicalization", "signed_at", "expires_at", and "signature", that "algorithm" is "Ed25519" and "canonicalization" is "jcs-rfc8785", that "signature" is a valid spelling of 64 bytes (Section 8), and that "expires_at" is a valid timestamp. If any of these checks fails, the result is FAIL_INVALID. If "dns_selector" is absent, the verifier MAY use "arp" (Section 8) and otherwise reports FAIL_INVALID. Missing "statement", "verify", or "dns_record" members do not cause a failure (Section 8).¶
7. Construct the DNS name: the value of "dns_selector", then "._arp.", then the retrieval domain. In a version 1.3 manifest, if "dns_record" or "verify.dns_name" is present and differs from this name, the result is FAIL_DOMAIN_MISMATCH.¶
8. Query the TXT records at that name. If the query fails for reasons other than the absence of a record (for example a timeout or SERVFAIL), the verifier MUST NOT report PASS; it reports a temporary error and MAY retry later. If no record with "v=ARP1" exists, the result is FAIL_NO_DNS.¶
9. If a record with "v=ARP1" at that name has an empty "p" tag, the result is FAIL_KEY_REVOKED.¶
10. Decode the "p" tag into a 32-byte public key (Section 4.2). If "k" is not "ed25519", the record is malformed, or the key cannot be decoded, the result is FAIL_INVALID.¶
11. Compute the signing input (Section 6).¶
12. Verify the Ed25519 signature over the signing input with the public key. If the signature is invalid, the result is FAIL_INVALID.¶
13. If the current time is later than "expires_at", the result is FAIL_EXPIRED.¶
14. Otherwise, the result is PASS.¶

The order determines precedence: a revoked key is reported even if the signature is invalid or expired, and an invalid signature is reported as FAIL_INVALID even after "expires_at". Representations are checked independently of this result (Section 9.4).¶

9.4. Representation Check

Verifiers SHOULD check the representations of a manifest. A verifier that checks representations processes each entry of "representations" as follows. If "href" is an HTTPS URL whose host equals the retrieval domain, the verifier retrieves it and computes the SHA-256 of the response body after removal of any content coding. Other URLs are not retrieved. The results are:¶

REPRESENTATION_MATCH:

The computed digest equals "sha256".¶

REPRESENTATION_MISMATCH:

The computed digest differs from "sha256".¶

REPRESENTATION_UNCHECKED:

The representation was not retrieved (other host, not HTTPS, retrieval failure, or malformed entry).¶

The representation result is reported alongside the result of Section 9.3 and does not change it. A mismatch does not invalidate the manifest signature. A verifier MAY also render the manifest (Section 5.7) and compare the result with the retrieved bytes. A verifier that checks a local copy MAY read the representation from a local file.¶

9.5. Result Codes

PASS means that the operator of the retrieval domain published exactly this manifest and that it has not been altered since. It does not mean that the statements in the manifest are true. Verifier output for PASS SHOULD state this limitation in plain words, for example "authorship verified via Ed25519 signature; content not verified".¶

9.6. Relation to Trust Levels

[ARP-SPEC] and [ARP-CLI] report results as trust levels with a reason. The correspondence is:¶

The trust level CRYPTOGRAPHIC describes the authorship status only. It is never a statement about the truth, completeness, or quality of the content.¶

11.1. HTTP Link Header Field

HTML responses of the site carry a Link header field [RFC8288] with the registered relation type "describedby" [POWDER] for both files:¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

Link: </.well-known/reasoning.json>; rel="describedby"; \
type="application/json", </.well-known/reasoning.md>; \
rel="describedby"; type="text/markdown"

The "type" attribute distinguishes these targets from other "describedby" links on the same response.¶

11.2. HTML link Elements

The HTML "head" element of pages of the site contains:¶

<link rel="reasoning" type="application/json"
      href="/.well-known/reasoning.json">
<link rel="describedby" type="application/json"
      href="/.well-known/reasoning.json">

The relation "reasoning" has been used by earlier versions of ARP and is kept for compatibility. It is not registered in the IANA "Link Relation Types" registry; "describedby" is (Section 15.3).¶

11.3. Visible URL

Pages of the site show the absolute manifest URL as visible link text in the footer or body text, for example "Self-description (ARP): https://example.com/.well-known/reasoning.json" on English pages and "Selbstauskunft (ARP): https://example.com/.well-known/reasoning.json" on German pages:¶

<p>Self-description (ARP):
<a href="https://example.com/.well-known/reasoning.json"
>https://example.com/.well-known/reasoning.json</a></p>

Reason: some agent fetch tools retrieve only URLs that have already appeared in the conversation context; Anthropic documents this rule for its web fetch tool, with the error code "url_not_in_prior_context" [ANTHROPIC-WEBFETCH]. Conversion of HTML to text usually drops "link" elements, while a visible absolute URL remains in the text.¶

11.4. Sitemap

The sitemap of the site [SITEMAPS] lists both files. "lastmod" is the date of "_arp_signature.signed_at" for signed manifests and "provenance.published" for unsigned ones:¶

<url>
  <loc>https://example.com/.well-known/reasoning.json</loc>
  <lastmod>2026-10-05</lastmod>
</url>
<url>
  <loc>https://example.com/.well-known/reasoning.md</loc>
  <lastmod>2026-10-05</lastmod>
</url>

11.5. llms.txt

Sites that publish an llms.txt file [LLMSTXT] include a section with exactly these lines; the second line is omitted when no reasoning.md is published:¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

## Reasoning Context
- Self-description (ARP manifest, JSON): \
https://{DOMAIN}/.well-known/reasoning.json
- Self-description (Markdown): https://{DOMAIN}/.well-known/\
reasoning.md
- The manifest contains {ENTITY}'s own statements about itself.

The section contains no statement about the signature and no imperatives.¶

11.6. robots.txt

This document defines no robots.txt directives. robots.txt [RFC9309] contains only real rules and the "Sitemap" line. Comment lines or non-standard fields that point to the manifest or address AI systems, as recommended by draft-deforth-arp-00, are not used.¶

11.7. Media Types and CORS

reasoning.json is served with "Content-Type: application/json; charset=utf-8", and reasoning.md with "Content-Type: text/markdown; charset=utf-8" (the "charset" parameter of text/markdown is required by [RFC7763]; for application/json it has no effect, see Section 11 of [RFC8259]). Both responses carry "Access-Control-Allow-Origin: *".¶

The author is not aware of any provider of AI systems that documents evaluating Link header fields, "link" elements, or llms.txt references in its crawlers or fetchers (as of October 2026). The profile therefore combines pointers that cost nothing with the two pointers that match documented behavior: the visible absolute URL and the sitemap entry.¶

13.1. DNS Security

The trust anchor is the DNS TXT record. Without DNSSEC, an attacker who can forge DNS responses can substitute a public key. Verifiers SHOULD use DNSSEC-validating resolvers where available and SHOULD cache DNS responses according to their TTL.¶

13.2. Key Compromise

An attacker who obtains the private key can sign arbitrary manifests that verify against the published key. Publishers MUST store private keys securely, for example with file permissions 0600, outside version control, or in hardware security modules, and MUST revoke a key at once and rotate to a new selector when the key is known or suspected to be compromised (Section 4.6, Section 10). The "expires_at" member limits the validity of each signature.¶

13.3. Replay and Staleness

Verifiers check "expires_at" (Section 9.3). The "domain" member and the domain binding check prevent replay of a manifest on another domain. A signed manifest without "domain" would verify under every domain that publishes the same key, which is why an absent "domain" fails the check (Section 9.1); publishers SHOULD NOT publish the same key under several domains. Verifiers MAY compare "signed_at" with the HTTP Last-Modified header field to detect stale copies served from caches.¶

13.4. Content Truthfulness

ARP establishes provenance (who published the data), not truth (whether the data is correct). A domain operator can sign false statements, and they will verify. Signing costs little: a domain and a key are enough. A valid signature therefore MUST NOT be presented or treated as a seal of truth, quality, or third-party verification. Systems that use ARP content can compare it with independent sources; "evidence_url" and "epistemic_scope" help with that.¶

13.5. Instruction-Like Text

Text in retrieved content that is phrased as an instruction to an AI system cannot be told apart reliably from prompt injection. Systems that process web content give such content no authority; for example, the OpenAI Model Spec states that content from tools and similar sources has "no authority by default" [OPENAI-MODEL-SPEC]. Google's spam policies list "attempting to manipulate generative AI responses" as a spam practice [GOOGLE-SPAM]. Instruction language in a manifest therefore has no documented benefit and puts the file at risk of being classified as manipulation. The Wording Profile (Section 5.5) is designed to reduce this risk for conforming manifests. Independently of the profile, software that loads ARP content into a model context SHOULD pass it as data with a plain statement of its source and verification result, and SHOULD NOT wrap it in markup that imitates system or role messages.¶

13.6. Signing Constructions That Do Not Cover Metadata

If the signing input excludes the signature metadata, as in the payload-only construction of earlier ARP tooling, anyone holding a signed copy can change "expires_at" or "dns_selector" without breaking the signature. The attack is practical: an archived copy of a deployed manifest that had been signed with the payload-only construction was altered to a later "expires_at", and a version of the reference implementation that still accepted that construction as a fallback reported the altered copy as valid. For this reason, verifiers MUST NOT fall back to other constructions (Section 6). Publishers whose earlier manifests used such a construction SHOULD rotate to a new selector and revoke the old one (Section 10).¶

13.7. Duplicate Member Names

Common JSON parsers keep the last of several members with the same name, while people and language models that read the bytes may take the first. Without the I-JSON check of Section 6, anyone holding a signed copy could insert a second "framing_context" or "expires_at" before the signed member: the parsed object, and therefore the signing input, would be unchanged, the signature would still verify, and readers of the raw text would see the inserted value. JSON Schema validation cannot detect this, because parsers merge duplicate names before validation. Verifiers, renderers, and validators therefore check for duplicate names while parsing.¶

13.8. Signature Value Encoding

The signature value is the only part of a signed manifest that the signature does not cover. A lenient base64 decoder that skips unknown characters or stops at the first padding character would accept a value with appended text, for example a sentence addressed to readers, and still verify the signature. The strict decoding rules of Section 8 exclude this.¶

13.9. Limits of Revocation

Revocation works only with verifiers that construct the DNS name from the retrieval domain and "dns_selector". Verifiers that follow a name taken from the manifest are not protected; this document forbids that behavior (Section 8). Revocation makes earlier signed copies fail verification but does not remove them from caches, indexes, or archives. Corrections to a manifest likewise take effect only for later copies.¶

13.10. Cross-Domain Signing

Cross-domain signing MUST use the CNAME delegation of Section 4.5. Verifiers MAY treat delegated signatures with lower confidence than same-domain signatures.¶

13.11. Keypair Separation

When ARP is deployed next to other systems that use Ed25519 (for example for agent session signing), implementations MUST NOT reuse the same key pair for different functions, because compromise of one function would then compromise all of them. Where one identity anchor for several keys is wanted, a DID document [DID-CORE] can bind function-specific keys to the domain, for example an "assertionMethod" key for ARP and an "authentication" key for session signing.¶

13.12. Domain Signing Policy

To protect against downgrade attacks, in which an attacker removes the "_arp_signature" member from a signed manifest and alters the content, a domain owner MAY publish a Domain Signing Policy at the bare "_arp" node:¶

  _arp.example.com. IN TXT "v=ARP1; p=reject"

The policy record uses the tag-list syntax of the key record (Section 4.2):¶

arp-policy-record = tag-list     ; RFC 6376, Section 3.2
arp-policy-v-tag  = %x76 [FWS] "=" [FWS] "ARP1"
arp-policy-p-tag  = %x70 [FWS] "=" [FWS]
                    ( "none" / "warn" / "reject" )

The tag "p" denotes the policy here and the public key in key records. The two kinds of record are distinguished by their names: the policy record is at "_arp.{DOMAIN}", key records are at "{SEL}._arp.{DOMAIN}", and because a selector is never empty (Section 4.1), no key record has the name of the policy record. Verifiers read the record at "_arp.{DOMAIN}" only as a policy record. The tag name "p" is kept for compatibility with existing policy records.¶

This follows the progressive enforcement model of DMARC [RFC9989] and HTTP Strict Transport Security [RFC6797]. Before publishing "p=reject", all locations that serve the manifest need signed copies. The policy is OPTIONAL for publishers. Querying it is RECOMMENDED for verifiers (Section 9.3); the protection works only with verifiers that query it.¶

13.13. Representations

A representation is bound to the manifest only through its digest. A mismatch can mean that the representation was altered, or only that it was not regenerated after a change; verifiers report it without changing the manifest result. Verifiers retrieve representations only from the retrieval domain over HTTPS (Section 9.4), which limits their use for requests to arbitrary hosts. Markdown can contain raw HTML, because strings are copied unchanged; software that displays reasoning.md SHOULD treat it as text and SHOULD NOT execute embedded HTML or scripts.¶

13.14. Alternative Cryptographic Envelopes

This document defines a custom signature block for simplicity. A future version could use JSON Web Signature [RFC7515] with the unencoded payload option [RFC7797], mapping "dns_selector", "signed_at", and "expires_at" to the protected header. This would allow the use of standard libraries while keeping the readable JSON payload.¶

15.1. Well-Known URIs

This document requests IANA to register the following two entries in the "Well-Known URIs" registry established by [RFC8615].¶

First entry:¶

URI suffix:

reasoning.json¶

Change controller:

Sascha Deforth (hello@truesource.studio)¶

Specification document(s):

Section 5.1 of this document¶

Status:

provisional¶

Related information:

Format of the resource: the ARP manifest, media type application/json. [ARP-SPEC]¶

Second entry:¶

URI suffix:

reasoning.md¶

Change controller:

Sascha Deforth (hello@truesource.studio)¶

Specification document(s):

Section 5.6 and Section 5.7 of this document¶

Status:

provisional¶

Related information:

Markdown rendering of the manifest at "/.well-known/reasoning.json", media type text/markdown.¶

The status is provisional because this document is not a Standards Track specification ([RFC8615], Section 3.1). The scheme is "https".¶

15.2. Underscored Node Name

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 and Section 13.12 of this document¶

15.3. Link Relation Types

This document requests no registration in the "Link Relation Types" registry. The Discovery Profile uses the registered relation type "describedby" [POWDER]. The relation name "reasoning", used in HTML by earlier versions of ARP, is not registered, and this revision does not request its registration: Section 2.1.1.1 of [RFC8288] requires a stable specification, and Section 2.1.1 of [RFC8288] asks for names that reflect application-specific semantics.¶

15.4. Media Types

This document defines no new media type. Manifests are served as application/json and representations as text/markdown.¶

A.1. Test Key

The private key is a test key and MUST NOT be used for any real domain. Its 32-byte seed is the SHA-256 of the ASCII string "draft-deforth-arp-01 test key":¶

  seed (hex):
    34af3b0d13a7a1ecf2ce4102c2402a36
    825a5f163c62cb7567df2ed3fa15effb
  public key (base64):
    NBnwMAmxIwzpUCCEvJYO8gqodE+ZbemH5QZSTQPREE8=

A.2. DNS Record

arp2610._arp.example.com. 3600 IN TXT (
  "v=ARP1; k=ed25519; p=NBnwMAmxIwzpUCCEvJYO8gqodE+ZbemH5QZSTQPREE8="
  )

A.3. Signed Manifest

The manifest as served at "https://example.com/.well-known/reasoning.json", signed at 2026-10-05T00:00:00Z with a validity period of 90 days:¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

{
  "$schema": "https://arp-protocol.org/schema/v1.3.json",
  "protocol": "Agentic Reasoning Protocol (ARP)",
  "version": "1.3",
  "domain": "example.com",
  "entity": "Example Corp",
  "provenance": {
    "statement": "This file is Example Corp's own description of \
itself, published by Example Corp GmbH at example.com. The \
statements are self-attested; where available, independent evidence \
is linked in evidence_url.",
    "publisher": "Example Corp GmbH",
    "publisher_url": "https://example.com/legal-notice",
    "published": "2026-10-05"
  },
  "identity": {
    "elevator_pitch": "Example Corp is a software consultancy based \
in Duesseldorf, Germany.",
    "founded": 2019,
    "legal_entity": "Example Corp GmbH",
    "not_to_be_confused_with": [
      {
        "name": "Example Corporation (Delaware)",
        "reason": "Similar name; no corporate relationship."
      }
    ]
  },
  "corrections": {
    "common_hallucinations": [
      {
        "trigger_topic": "Founding year",
        "verified_fact": "Example Corp GmbH was entered in the \
commercial register in 2019 (HRB 00000).",
        "evidence_url": "https://example.com/legal-notice",
        "epistemic_scope": "public_verifiable"
      }
    ]
  },
  "entity_claims": {
    "framing_context": "Example Corp describes itself as a \
consultancy for structured product data.",
    "recommendation_context": {
      "recommended_when": [
        "Typical fit: mid-sized retailers that publish product data."
      ],
      "not_recommended_when": [
        "Not a fit: projects that need a hosted shop system."
      ]
    }
  },
  "content_policy": {
    "ai_training": "allowed-with-attribution",
    "citation_required": true
  },
  "representations": [
    {
      "href": "https://example.com/.well-known/reasoning.md",
      "media_type": "text/markdown",
      "sha256": "8ad59fe6281e053ec365de18b30abd464605bc8ea5734b493b3\
e62de88dc0de8"
    }
  ],
  "_arp_signature": {
    "algorithm": "Ed25519",
    "dns_selector": "arp2610",
    "dns_record": "arp2610._arp.example.com",
    "canonicalization": "jcs-rfc8785",
    "signed_at": "2026-10-05T00:00:00Z",
    "expires_at": "2027-01-03T00:00:00Z",
    "statement": "Signed with Ed25519 by the operator of \
example.com. Public key: DNS TXT record arp2610._arp.example.com. \
The signature shows that the domain operator published exactly this \
file and that it has not been altered since; it does not show that \
the statements are true.",
    "verify": {
      "dns_name": "arp2610._arp.example.com",
      "doh_url": "https://dns.google/resolve?name=arp2610._arp.\
example.com&type=TXT",
      "spec": "https://arp-protocol.org/SPEC.md#13-cryptographic-\
trust-layer"
    },
    "signature": "-PUn8OJQkieadxVTc_S-GhvooSjLdfyhIlfJ92_\
AhFzO4xADJp9_zsFENsU-fBMCFcgsc3wnLFz71hE8H029BQ"
  }
}

A.4. Markdown Representation

The bytes served at "https://example.com/.well-known/reasoning.md" (1799 bytes; the first line contains U+2014 EM DASH):¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

# Example Corp — self-description (ARP)

This file is Example Corp's own description of itself, published by \
Example Corp GmbH at example.com. The statements are self-attested; \
where available, independent evidence is linked in evidence_url.

Manifest: https://example.com/.well-known/reasoning.json

## identity

- elevator_pitch: Example Corp is a software consultancy based in \
Duesseldorf, Germany.
- founded: 2019
- legal_entity: Example Corp GmbH
- not_to_be_confused_with:
  - 1:
    - name: Example Corporation (Delaware)
    - reason: Similar name; no corporate relationship.

## corrections

- common_hallucinations:
  - 1:
    - trigger_topic: Founding year
    - verified_fact: Example Corp GmbH was entered in the \
commercial register in 2019 (HRB 00000).
    - evidence_url: https://example.com/legal-notice
    - epistemic_scope: public_verifiable

## entity_claims

- framing_context: Example Corp describes itself as a consultancy \
for structured product data.
- recommendation_context:
  - recommended_when:
    - Typical fit: mid-sized retailers that publish product data.
  - not_recommended_when:
    - Not a fit: projects that need a hosted shop system.

## content_policy

- ai_training: allowed-with-attribution
- citation_required: true

## Verification

- Manifest: https://example.com/.well-known/reasoning.json
- statement: Signed with Ed25519 by the operator of example.com. \
Public key: DNS TXT record arp2610._arp.example.com. The signature \
shows that the domain operator published exactly this file and that \
it has not been altered since; it does not show that the statements \
are true.
- dns_name: arp2610._arp.example.com
- doh_url: https://dns.google/resolve?name=arp2610._arp.example.com&\
type=TXT
- signed_at: 2026-10-05T00:00:00Z
- expires_at: 2027-01-03T00:00:00Z

A.5. Intermediate Values

  SHA-256 of reasoning.md (value of "sha256" in "representations"):
    8ad59fe6281e053ec365de18b30abd46
    4605bc8ea5734b493b3e62de88dc0de8
  Length of the signing input: 2307 bytes
  SHA-256 of the signing input:
    1598c5015bee4c86cb7e6b746f636731
    f4018a08c5cc20dcc8763c408247fa1f
  Signature (base64url, unpadded, 86 characters):
    -PUn8OJQkieadxVTc_S-GhvooSjLdfyhIlfJ92_AhFz
    O4xADJp9_zsFENsU-fBMCFcgsc3wnLFz71hE8H029BQ

The signing input (Section 6):¶

=============== NOTE: '\' line wrapping per RFC 8792 ===============

{"$schema":"https://arp-protocol.org/schema/v1.3.json","_arp_\
signature":{"algorithm":"Ed25519","canonicalization":"jcs-rfc8785",\
"dns_record":"arp2610._arp.example.com","dns_selector":"arp2610",\
"expires_at":"2027-01-03T00:00:00Z","signature":"","signed_\
at":"2026-10-05T00:00:00Z","statement":"Signed with Ed25519 by the \
operator of example.com. Public key: DNS TXT record \
arp2610._arp.example.com. The signature shows that the domain \
operator published exactly this file and that it has not been \
altered since; it does not show that the statements are \
true.","verify":{"dns_name":"arp2610._arp.example.com","doh_\
url":"https://dns.google/resolve?name=arp2610._arp.example.com&type=\
TXT","spec":"https://arp-protocol.org/SPEC.md#13-cryptographic-\
trust-layer"}},"content_policy":{"ai_training":"allowed-with-\
attribution","citation_required":true},"corrections":{"common_\
hallucinations":[{"epistemic_scope":"public_verifiable","evidence_\
url":"https://example.com/legal-notice","trigger_topic":"Founding \
year","verified_fact":"Example Corp GmbH was entered in the \
commercial register in 2019 (HRB 00000)."}]},"domain":"example.com",\
"entity":"Example Corp","entity_claims":{"framing_context":"Example \
Corp describes itself as a consultancy for structured product \
data.","recommendation_context":{"not_recommended_when":["Not a \
fit: projects that need a hosted shop \
system."],"recommended_when":["Typical fit: mid-sized retailers \
that publish product data."]}},"identity":{"elevator_\
pitch":"Example Corp is a software consultancy based in \
Duesseldorf, Germany.","founded":2019,"legal_entity":"Example Corp \
GmbH","not_to_be_confused_with":[{"name":"Example Corporation \
(Delaware)","reason":"Similar name; no corporate \
relationship."}]},"protocol":"Agentic Reasoning Protocol \
(ARP)","provenance":{"published":"2026-10-05","publisher":"Example \
Corp GmbH","publisher_url":"https://example.com/legal-notice",\
"statement":"This file is Example Corp's own description of itself, \
published by Example Corp GmbH at example.com. The statements are \
self-attested; where available, independent evidence is linked in \
evidence_url."},"representations":[{"href":"https://example.com/.\
well-known/reasoning.md","media_type":"text/markdown",\
"sha256":"8ad59fe6281e053ec365de18b30abd464605bc8ea5734b493b3e62de88\
dc0de8"}],"version":"1.3"}

A.6. Verification Steps and Expected Results

1. Retrieval domain: "example.com"; "domain" is "example.com" (domain binding passes).¶
2. DNS name constructed: "arp2610._arp.example.com"; the record of Appendix A.2 is found and "p" is not empty.¶
3. The signing input is computed as above; Ed25519 verification succeeds.¶
4. At any time before 2027-01-03T00:00:00Z the result is PASS; from then on, FAIL_EXPIRED.¶
5. The representation check yields REPRESENTATION_MATCH.¶

Expected results for altered inputs:¶

• "expires_at" changed to "2027-12-31T00:00:00Z": FAIL_INVALID.¶
• Any character of "provenance", "statement", or "representations" changed: FAIL_INVALID.¶
• The record replaced by "v=ARP1; k=ed25519; p=": FAIL_KEY_REVOKED, also after "expires_at".¶
• The same manifest retrieved from "example.net": FAIL_DOMAIN_MISMATCH.¶
• The same content signed with the "signature" member removed, or with the whole "_arp_signature" member removed, before canonicalization: FAIL_INVALID.¶
• reasoning.md altered by one byte: PASS with REPRESENTATION_MISMATCH.¶
• A second "framing_context" member with other text inserted into "entity_claims" before the signed one, or a second "expires_at" member inserted into "_arp_signature": FAIL_INVALID (duplicate member names), although a parser that keeps the last value would compute the original signing input.¶
• Text appended to the signature value after "==": FAIL_INVALID.¶
• "verify.dns_name" changed to "arp2610._arp.example.net" and the manifest re-signed with the test key: FAIL_DOMAIN_MISMATCH at "example.com".¶