Identity
Is this certificate bound to this agent in the transparency log? A badge or a verified SCITT receipt supplies the identity evidence.
How it works
From a domain name to a verifiable peer.
ANS combines domain control, certificates, and a transparency log. Each part answers a specific question about the agent you are about to interact with.
The lifecycle
Register. Publish.
Discover. Verify.
The agent operator, Registration Authority, and Transparency Log have distinct roles. DNS helps peers find the evidence.
A name for a specific registration
ans://v1.0.0.payments.example.comThe version and domain identify the registration. A new version is a new registration.
Prove control and register
The operator submits an agent host, version, endpoints, and certificate material to a Registration Authority. The RA verifies domain control and the required proofs.
Publish the required DNS records
The RA returns the records to publish. The operator provisions them with their DNS provider; the RA checks the required records before activation.
Seal the lifecycle event
The RA signs the event and the Transparency Log seals it before activation succeeds. Public verification artifacts bind the registration to its authorized certificates.
Discover the endpoint and evidence
Peers use a supported discovery profile to locate endpoints. The shared
_ans-badgerecord locates the registration’s badge in its Transparency Log.Authenticate, then apply policy
Check identity, current status, and key possession. The application then applies its own permissions and risk policy before allowing an action.
Three proofs. One authenticated identity.
Current status
Is the registration still valid? An online badge or a short-lived signed status token supplies lifecycle information with bounded freshness.
Possession
Does this peer hold the private key? Public badges and receipts alone cannot authenticate the caller. The peer must prove possession.
Choose the proof that fits your connection.
ANS-6 defines two caller authentication methods with equal standing in the published specification. Both require identity and current-status checks.
Method A
Mutual TLS
The caller presents its ANS Identity Certificate during the TLS handshake. This fits a connection where the peer’s TLS identity reaches the verifier.
Can use online badge verification or SCITT artifacts.
Method B
Application-layer DPoP
The caller sends a signed, single-use proof bound to the request method, URL, and content. It can pass through gateways that terminate TLS.
Uses a SCITT receipt and status token, with replay protection.
Callee verification also binds the actual TLS server certificate to the registration. Read the full ANS-6 verification procedures ↗
DNS is discovery, with verifiable bindings.
The current V2 registration model defaults to ANS_DNSAID. ANS_TXT is an explicit option. Publish the records returned by your RA, including their required flags.
| Record | Location | Purpose |
|---|---|---|
| ANS_DNSAID | SVCB at agentHost | Per-endpoint discovery hints. The default V2 profile. |
| ANS_TXT | _ans.agentHost | TXT discovery records; opt-in on V2 and used by the V1 lane. |
| Badge | _ans-badge.agentHost | Required, shared link to the Transparency Log badge. |
| Server DANE | _port._tcp.agentHost | Optional TLSA record. A DNSSEC-authenticated mismatch must not be accepted. |
Trust boundaries
Evidence has a scope.
ANS verifies domain-anchored agent identity. Optional Verified Identities can add a separately proven identity relationship where the RA supports them.
Sealed metadata digests can bind published metadata to a registration. They do not attest the code executing on a remote machine or guarantee an agent’s behavior.
Transparency makes records auditable. Clients still need trusted log keys, correct signature and proof verification, freshness checks, and a policy for failures.
ANS authentication does not authorize an action or delegate a user’s permissions. Trust scoring is a separate project, not an ANS authentication tier.
Read the specifications