AgenID and GoDaddy Agent Name Service (ANS): a factual comparison

What ANS is

GoDaddy's ANS page describes ANS as an open standard that connects AI agents to domain names, and says it is built on DNS, PKI and ACME. The technical definition is the Internet-Draft draft-narajala-courtney-ansv2, titled "Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity", whose listed authors include contributors from GoDaddy, OWASP and Cisco. As an individual Internet-Draft, it states that it is not endorsed by the IETF and has no formal standing in the IETF standards process. It replaces the earlier draft-narajala-ans.

In the ANS v2 draft, every agent identity anchors to a DNS domain name. A Registration Authority verifies domain control through ACME and then issues two certificates: a Server Certificate from a public certificate authority, and an Identity Certificate from a private certificate authority that binds a version-specific name. That name has the form ans://v{version}.{agentHost}, combining a semantic version with a fully qualified domain name. Lifecycle events are sealed into an append-only Transparency Log that the draft describes as aligned with IETF SCITT. GoDaddy publishes an Apache 2.0 licensed registry implementation on GitHub.

What AgenID is

AgenID is an open protocol, specified in the MIT-licensed AgenID specification, that gives an AI agent a permanent identifier of the form agenid:<ULID>. The operator, meaning the party accountable for the agent, generates an Ed25519 key pair on its own machine or in the browser at /issue; the private key is never sent to AgenID. The operator writes a manifest covering identity, ownership, purpose and disclosure, and signs a ManifestProof that binds the manifest by SHA-256 digest. Signatures are pure Ed25519 over RFC 8785 canonical JSON.

The registry at www.agenid.com validates and stores that public material and serves it at https://www.agenid.com/a/<agenid>: a Verification Card for browsers, or the resolution envelope as JSON. A verifier re-checks the envelope offline. The registry holds no operator private keys, so it cannot forge an operator signature.

Key differences

The first difference is what the identity is attached to. In ANS the anchor is a domain name, confirmed by the Registration Authority through ACME before any certificate is issued. In AgenID the anchor is the operator key. The manifest's operator_domain is a declared value; proving control of it with an _agenid TXT record at /verify/domain records evidence of domain control but raises nothing above L1_REGISTERED today.

The second is what counts as a new identity. The ANS v2 draft binds identity to a software version, so a code change produces a new version number and a new registration. The AgenID specification separates an agent from its deployments: the agenid: identifier is never re-keyed by a platform, configuration or deployment change, and deployments are distinct records under the same agent.

The third is the verification path. The ANS v2 draft has a client check certificate validation, DANE records under DNSSEC, and Transparency Log proofs through separate channels. AgenID has a verifier recompute the manifest digest, verify the operator's Ed25519 signature, and compare the operator key served by the registry with the copy the operator publishes on its own domain (two-path key discovery).

Where they are complementary

An agent can carry both. An operator with an ANS registration can also sign an AgenID manifest that names the same domain as operator_domain, and a relying party can check each independently: ANS for the certificate chain and transparency record around a versioned endpoint, AgenID for an operator-signed record that stays constant across versions, platforms and channels. Neither protocol currently defines a field that references the other.

Both are identity systems. Knowing which agent is acting is not the same as knowing what it is allowed to do. The ANS v2 draft centers on identity, discovery and lifecycle records. AgenID v1.1.1 defines no signed authorization object at all, so permission decisions stay with the business on the other side and with the operator.

When to use which

These are fit questions, not quality judgments.

• Consider ANS when your agents are reached at their own domains, you want identity expressed through X.509 certificates and DNS records that existing TLS tooling understands, and version-level registration matches your release process.
• Consider AgenID when you want one identifier that stays the same across versions and across voice, SMS, chat, email and API channels, signed by a key only the operator holds, and re-verifiable offline by anyone without an account.
• Consider both when a relying party should be able to check a domain-anchored certificate chain and an operator-signed manifest for the same agent.

AgenID's current limits

The comparison is only fair if AgenID's boundaries are stated as plainly as its design.

• Issuance ceiling: the reference deployment at agenid.com issues nothing above L1_REGISTERED today. The specification defines L2_DOMAIN_VERIFIED, L3_ORGANIZATION_VERIFIED and L4_DEPLOYMENT_VERIFIED, but each requires a VerificationAssertion signed by a root authority key, and that key has not been created yet. L1_REGISTERED is a self-declaration: it means an operator-signed manifest is in the registry, not that anyone checked the operator. L5 is reserved and not issuable.
• No revocation flow is deployed. Agent status values such as SUSPENDED and REVOKED exist in the schema so the envelope shape is stable, but nothing in production writes them, so every registered agent reads ACTIVE. The specification keeps retired and revoked keys resolvable permanently so that historical signatures remain checkable.
• No authorization object exists in v1.1.1. The DECLARED, VERIFIED and AUTHORIZED claim states are never inferred from one another, AUTHORIZED has no signed object, and permissions and authorizations are reserved manifest keys that a v1.1.1 validator rejects. A v1.2 authorization layer is a draft in development, not something available.
• Two-path key discovery depends on the operator. The registry serves the operator key at GET https://www.agenid.com/v1/keys/<key-ulid>, and the operator is expected to publish its own copy at https://<operator_domain>/.well-known/agenid/keys.json. If the operator publishes no copy, a verifier has one source, not two.