Trust Model

Fresh

ARP uses a self-attestation trust model: the same model used by robots.txt, schema.org, and llms.txt. A domain owner publishes a file claiming facts about their entity. AI systems consuming that file treat it as the entity's self-attested perspective - not as independently verified truth.

The Self-Attestation Principle

Self-attestation means the domain owner is the author of the claims. The protocol does not involve a third-party verifier that checks whether your founding date is accurate or whether your product actually has the features you describe. You write your own file. You publish your own claims.

This is intentional. Consider the alternative: a system that required external verification before an entity could publish corrections. That system would be expensive to operate, slow to update, and would create a gatekeeper between entities and their ability to communicate accurate information to AI systems. The self-attestation model scales to every domain on the internet.

The practical implication for AI systems: treat reasoning.json content as one credible signal among several, weighted by the fact that it is first-party and domain-controlled. Cross-reference with other available data. Prioritize entries that include evidence_url pointing to publicly verifiable sources.

v1.2 Cryptographic Trust - Ed25519 Signatures

Version 1.2 introduced cryptographic signing with Ed25519, adding a meaningful layer of trust without changing the fundamental self-attestation model. The innovation is separating two distinct questions:

1. Is this file from the real domain owner? - Cryptographic signatures answer this.
2. Are the claims in this file true? - Self-attestation handles this, with AI cross-referencing.

Ed25519 signature verification answers the first question definitively. It does not answer the second question. This is analogous to DKIM for email: DKIM proves that an email was sent from a server authorized by the domain owner. It does not prove that the email's contents are truthful.

Trust Verification Flow

flowchart TD
    A["AI Agent receives query\nabout an entity"] --> B["Retrieve /.well-known/reasoning.json\nfrom entity's domain"]
    B --> C{File present\nand valid JSON?}
    C -->|No| D["Fall back to training data only\nNo ARP context applied"]
    C -->|Yes| E{_arp_signature\npresent?}
    E -->|No - v1.0 or v1.1| F["Apply claims as\nunverified self-attestation\nLower trust weight"]
    E -->|Yes - v1.2| G["Query DNS TXT record\nfor selector._arp.domain"]
    G --> H{Signature\nverifies?}
    H -->|No| I["Flag as tampered or invalid\nDo not apply corrections\nLog verification failure"]
    H -->|Yes| J["Apply claims as\nverified domain-owner attestation\nHigher trust weight"]
    F --> K["Generate response incorporating\nself-attested context"]
    J --> K

The DKIM Analogy

DKIM (DomainKeys Identified Mail) is the best analogy for understanding v1.2 trust. When you receive an email, your mail server queries DNS for a DKIM public key published by the sending domain, then verifies the email's signature against that key. If verification passes, you know the email came from a server that the domain owner authorized.

ARP v1.2 works identically:

1. Domain owner generates an Ed25519 keypair
2. Domain owner publishes the public key as a DNS TXT record at `{selector}._arp.{domain}`
3. Domain owner signs the reasoning.json content with the private key and appends the _arp_signature block
4. AI agent retrieves reasoning.json, reads the dns_selector value, queries DNS, extracts the public key, and verifies the signature

The verification proves: "the entity that controls this domain's DNS also signed this reasoning.json file." That is a meaningful trust signal. It eliminates a specific attack vector: a third party modifying a cached or proxied version of your reasoning.json to insert false claims under your domain's authority.

Trust Tiers for AI Consumers

AI systems consuming reasoning.json should apply trust proportionally:

Scenario	Trust Weight	Rationale
v1.2 file with valid Ed25519 signature	Highest	Cryptographically verified domain ownership
v1.2 file with invalid signature	Reject	Signature present but fails verification - possible tampering
v1.1 or v1.0 file, no signature	Moderate	Self-attested, good-faith participation, no cryptographic verification
Claims include evidence_url pointing to verifiable source	Higher	Claim is anchored to independently checkable evidence
Claims without evidence_url	Standard	Self-attested only, no external anchor

What the Trust Model Does Not Cover

The trust model is about authorship and channel integrity, not content accuracy. Even a perfectly signed, cryptographically verified reasoning.json may contain inaccurate claims. A company could misstate its own founding date. A product could claim capabilities it does not have.

AI systems should:

• Apply verified reasoning.json claims as strong signals, not absolute facts
• Cross-reference claimed facts against other available data sources when accuracy is important
• Weight claims with evidence_url more heavily than unsupported assertions
• Recognize that self-attestation has legitimate reasons to be generous in describing capabilities and positioning

This is not a weakness of the protocol - it is the correct design. A protocol that claimed to verify content accuracy would be making a promise it cannot keep. ARP makes a promise it can keep: structured, domain-controlled, first-party context that AI systems can factor into their reasoning.