What the agentic web actually rests on

This note is offered as a contribution to the ARIA / TrustLayer protocol and to the W3C AI Knowledge Representation Community Group, and is completely open for discussion. It carries no endorsement by either body and states no settled position. Corrections, disputes and counter-analysis are all welcome, and may be raised as issues against the AIKR CG repository or sent directly to the author.

Every open agent identity scheme now under development binds an agent to a domain name. Almost none of them verify control of that name through authenticated DNS. The distance between those two statements is the finding of this note.

This note has two parts. The first records what the ARIA public API and website return when queried, including several defects the Foundation will want to fix before they are found by someone less friendly. The second sets those observations against the wider set of DNS-anchored agent identity proposals, where the same gap appears in almost identical form. The intent is corrective rather than adversarial, and the Foundation is invited to reply with anything I have misread.

1Method

All queries were made against public, unauthenticated endpoints documented on the ARIA developer page, using plain HTTP requests from a single host. No credentials were used, no write endpoint was called, no rate limits were tested, and no attempt was made to enumerate accounts or guess identifiers beyond the two demonstration values published by the site itself. Request identifiers are reproduced below so the Foundation can locate the corresponding server logs.

2Findings on the ARIA public surface

F1The sample DID printed on the homepage does not resolve

The homepage proof section invites a reader to run a verification command against did:aria:aria.bar:agent-alpha.^[1] That identifier verifies as invalid on every check, and resolving it returns a not-found error.

GET /v1/verify/did:aria:aria.bar:agent-alpha
{ "did": "did:aria:aria.bar:agent-alpha",
  "valid": false,
  "checks": { "signatureValid": false, "pqSignatureValid": false,
              "classicalSignatureValid": false, "statusActive": false,
              "notExpired": false, "issuerTrusted": false,
              "dnssecVerified": false } }

GET /v1/aids/did:aria:aria.bar:agent-alpha
{ "error": { "code": "AID_NOT_FOUND" } }

A first-time evaluator following the homepage will conclude the protocol is broken. The cost of correcting this is a single string.

F2The only enumeration endpoint in the API returns a server error

Of the endpoints listed at the API root, seven are keyed to a specific identifier the caller must already possess. One, /v1/scopes, is documented as listing all registered capability scopes.^[2] It returned HTTP 500 on three consecutive attempts.

GET /v1/scopes  →  500  INTERNAL_ERROR
  requestId 6ce07787-4b31-4745-908b-c5a911ddbf8a
  requestId 6d0e4a07-4031-490c-875f-3edb81f0223f
  requestId 3f9ae3db-239d-40b7-828a-17f03444ff91

Scope vocabulary is the part of ARIA an implementer needs before writing any policy, and it is the part a standards reviewer needs before assessing whether the vocabulary is coherent. Its absence blocks both.

F3The public verifier's demonstration identifiers are unusable as printed

The verify page offers two try-me links, rendered in the page text as did:aria:...ordering-agent and did:aria:...compromised-billing-bot. The elision is literal, and the served HTML contains the same truncated strings. A reader who copies what is on screen cannot verify anything. The complete values appear only inside the compiled JavaScript bundle:

did:aria:aria.bar:u-cmDoHhM3:ordering-agent            → valid
did:aria:aria.bar:u-cmDoHhM3:compromised-billing-bot   → statusActive false

Both verify as expected once obtained. The revoked bot is the better demonstration of the two, since its ML-DSA-65 and Ed25519 signatures both pass while the credential fails on status alone, which is exactly the property that separates revocation from cryptographic validity. Printing both DIDs in full, and adding a copy control, would let a reader reach that conclusion without opening developer tools.

F4Both demonstration agents belong to one self-declared account held by a Foundation officer

The two demonstration credentials share the account segment u-cmDoHhM3 and return a principal of Ivan Moreno, jurisdiction MX, verification status self-declared. A person of that name is listed on the Consejo Directivo as Vocal.^[3] Nothing improper follows from this, and at L0 a self-declared principal is the specified behaviour. The governance appearance is the issue: the only agents a visitor can inspect belong to a board member's own free-tier account, and the site offers no signal that this is a test fixture rather than a representative registration. A neutral fixture principal, or a line stating that these are Foundation-operated test credentials, resolves it.

F5The status endpoint answers identically for identifiers that do not exist

Requests to /v1/status/{did} return the same BitstringStatusList credential for every input tried, including well-formed identifiers with no registered AID and a deliberately invalid one, each with HTTP 200. Returning a shared list is correct under the status list model, so this is a documentation question rather than a defect. A caller who treats a 200 from this endpoint as evidence that an agent exists will be wrong, and nothing in the developer page warns against that reading. The list carried a validFrom at the protocol launch date, which the Foundation may want to confirm reflects the current issuance rather than a stale artefact.

F6No deployed ARIA credential is DNS-anchored, while DNS anchoring is the headline claim

The homepage presents DNS anchoring as one of four foundations and invokes four decades of global trust infrastructure. The trust level table then marks L0 as the only live tier, with L1, L2 and L3 all listed as coming soon, and states plainly that DNS anchoring begins at L1.^[1] Every verification response observed carried dnssecVerified: false. The specification and the marketing are internally consistent when read closely and misleading when read at the speed a procurement officer reads. The recommendation is a dated deployment status line on the homepage stating which tiers are issuing today.

3The same gap across the wider field

ARIA is not unusual here, which is the reason the observation is worth the Foundation's attention rather than merely its embarrassment. The pattern repeats across every open agent identity effort now in draft.

A2A servers publish an agent card at a well-known URI on their domain following RFC 8615, retrieved by an ordinary HTTP GET.^[4] Web Bot Auth defines a Signature-Agent header for in-band key discovery and a key directory served from a well-known URI, with the signature itself built on RFC 9421.^[5] Google signs a subset of its agent traffic, authenticated as a hostname, with verifiers fetching the key set from that host's well-known directory.^[6] In each case DNS resolves a name and TLS authenticates the endpoint, so the security property comes from the WebPKI and from certificate authority domain validation rather than from DNS itself. DNS remains load-bearing, one step removed, through the validation path.

Efforts that place agent data into DNS records proper are younger than their announcements suggest. GoDaddy co-authors the ANS draft for identity and naming on DNS and PKI; Infoblox advances DNS-AID for discovery; the two plus Nemethi's AID are converging on a shared profile under the _ag label using SVCB records.^[7][8] The Cloud Security Alliance's analysis of ANS is more restrained than the launch messaging, reporting that the DNS record encoding, the DNSSEC deployment profile, and the DID and LEI grammars are absent from the primary sources and should be read as roadmap, with the project pre-1.0 and its reference implementation using mock cryptography.^[9]

Whether any of this constitutes anchoring depends on DNSSEC, and the measurements are not encouraging. Validation reached roughly a third of users and secure delegation roughly seven per cent last year, after two decades of availability.^[10] An unsigned TXT or SVCB record is an assertion by whoever controls the resolution path at the moment of the query, which is a weaker claim than the one these architectures are written as though they had.

Most agents now running in production sit outside every scheme in that table. A Cloud Security Alliance survey commissioned by Token Security found that 82% of organisations had discovered agents in their own infrastructure that nobody knew about, and 65% had experienced an agent-related incident in the preceding year.^[11] Unregistered agents are invisible to a registry-based trust model by construction, so adoption metrics for ARIA, ANS or any successor should be read against that denominator rather than against each other.

4The governance consequence

Binding agent identity to domain control transfers adjudication power to registrars, registries and certificate authorities. A domain suspension, a dispute resolution ruling, a lapsed renewal or a compromised registrar account then revokes an entire agent fleet's identity as a side effect, through a process with no relationship to the agent's own conduct. The named backers of the leading DNS-anchored proposal are DNS incumbents, a roster the CSA analysis flags as analytically relevant.^[9] ARIA's own separation of the Foundation from a commercial operator with registrar heritage places it in the same position, and its anti-capture clause is the right instrument if it addresses this specific transfer.

None of the drafts I have read specify what happens to an agent credential when the underlying domain changes hands. A buyer of an expired domain inherits the ability to publish anchoring records for every agent previously identified under it. This deserves a paragraph in the ARIA specification whether or not the other efforts write one.

5Questions for the Foundation

1. Will the Foundation publish registration counts by trust level, or state that it will not? Either answer is defensible; the current silence reads as concealment of a small number, which may be unfair to you.
2. What is the expected issuance date for L1, and will the DNSSEC posture be a requirement or an observation recorded in dnssecVerified?
3. When a domain anchoring an L1 or higher credential expires or transfers, what happens to credentials issued under it, and who is obliged to act?
4. Is /v1/scopes expected to be public and enumerable, and can the scope vocabulary be published as a static document independent of API availability?
5. Does the Foundation intend to align with the _ag SVCB profile emerging from the ANS, DNS-AID and AID drafts, or to maintain a separate record convention?
6. Would the Foundation welcome a review of the specification against the W3C AI Knowledge Representation Community Group's work on agent interoperability, conducted in the open?

6Sources

1. ARIA Protocol homepage and trust level table. https://www.aria.bar/ Retrieved 9 September 2026.
2. ARIA developer documentation, REST API endpoint list. https://www.aria.bar/developers Retrieved 9 September 2026.
3. ARIA governance section, Consejo Directivo membership. https://www.aria.bar/governance
4. A2A Protocol, agent discovery documentation. https://a2a-protocol.org/latest/topics/agent-discovery/
5. Meunier T. and Major S., HTTP Message Signatures for automated traffic, draft-meunier-webbotauth-httpsig-protocol-01, IETF. datatracker.ietf.org/doc/html/draft-meunier-webbotauth-httpsig-protocol-01
6. Google, Authenticating requests with Web Bot Auth (experimental), Google Crawling Infrastructure documentation. developers.google.com/crawling/docs/crawlers-fetchers/web-bot-auth
7. Infoblox and GoDaddy, joint statement on DNS-based standards for agent discovery, identity and verification. infoblox.com press release
8. Agent Name Service information site, on the shared _ag SVCB profile. https://ansinfo.ai/
9. Cloud Security Alliance Lab Space, Anchoring Agent Identity in DNS: A Security Analysis of the Agent Name Service (ANS). labs.cloudsecurityalliance.org
10. Jantzen B., Towards an industry best practice for DNSSEC automation, APNIC Blog. blog.apnic.net
11. Cloud Security Alliance survey of 418 IT and security professionals, commissioned by Token Security, as reported in diginomica. diginomica.com
12. Linux Foundation, announcement of intent to launch the Agent Name Service. linuxfoundation.org

Observations F1 to F6 were made against public endpoints on 8 and 9 September 2026 and may be corrected by deployment changes since. The Foundation is welcome to reproduce, dispute or annotate this note, and any correction received will be reflected in a revised version.