> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ANS Trust Card and trust registry

> How verifiable caller and agent identity anchors work: what the Agent Name Service (ANS) Trust Card publishes, where Orbit's own card lives, how the public tenant trust registry lookup answers 'is this caller really who it presents as', and how to raise your organization's attestation posture.

# ANS Trust Card and trust registry

A caller ID on its own proves nothing — any gateway can write any digits into
a SIP header. What gives a caller's identity weight is a **verifiable
anchor**: a published record an outside party can fetch and check
cryptographically, tied to a domain and to keys nobody else controls. Devotel
Orbit ships two such anchors today. The first is Orbit's own **ANS Trust
Card**, a well-known JSON document that declares the platform's
domain-anchored identity for the emerging agent-discovery ecosystem. The
second is a **public trust registry lookup** — a per-organization, opt-in
endpoint that lets anyone with the URL ask "is this agent or number really
who it presents as, and what is it delegated to do?" against your tenant's
own verification posture. This page is the model behind both.

***

## 1. Why caller identity needs a verifiable anchor

Brand spoofing is the cheapest attack on voice: vishing calls impersonate a
bank, a clinic, or a delivery firm, and the rendered caller ID looks right
because nothing in the PSTN ever checked it. Consumers have learned not to
answer unknown calls, which punishes every legitimate business caller — your
appointment reminders, delivery notifications, and fraud alerts compete
against thousands of forged "verified" brands.

The industry response spans two layers. **STIR/SHAKEN** signs the caller ID
on every call (see the [STIR/SHAKEN attestation
model](/concepts/stir-shaken-attestation-model)), which binds a phone number
to the organization that resolves it. **Agent identity** is the newer layer:
as calls and API traffic get answered by AI agents, the question "which
agent, run by which operator, delegated to do what?" needs the same
verifiable-answer treatment a voice caller ID gets — and that question is
asked before any call exists.

Orbit ships anchors for both layers, and the posture behind the registry is
**tenant-owned**: your organization decides whether to publish its
verification status publicly at all (opt-in per organization), which numbers
carry full attestation, and which scopes its agents delegate. The
organization-level controls below are yours to set; nothing in this model is
a platform-mandated gate.

***

## 2. The Agent Name Service in context

ANS is a draft standard ([draft-narajala-courtney-ansv2](https://datatracker.ietf.org/doc/draft-narajala-courtney-ansv2/),
April 2026) that anchors an AI agent's identity to a DNS domain verified via
ACME, with dual certificates (server + identity) and a transparency-log
receipt for when you need it. The [Linux
Foundation announced](https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-agent-name-service-to-establish-trusted-identity-infrastructure-for-ai-agents)
its intent in June 2026 to host ANS as the trusted identity infrastructure
for AI agents. Mechanically, an ANS name is a URI of the form
`ans://v{version}.{host}`, and the record behind it is a **Trust Card**
served at the well-known path `/.well-known/ans/trust-card.json`.

ANS **complements** the NANDA AgentFacts document — it does not replace it.
AgentFacts is a capability facts sheet (what an agent can do, for the NANDA
Index). ANS is a naming and trust layer (who an agent is, anchored to a
domain and keys). Orbit publishes both, and they cross-reference each other:
the Trust Card's endpoint metadata points at the AgentFacts URL, and
resolvers treat the pair as one identity with two views.

(A status note, in the same spirit as the shipped record: ANS is still a
draft. Its full resolution flow expects `_ans` / `_ans-badge` DNS records and
a transparency-log receipt that are not yet provisioned on the public zone —
the Trust Card says so plainly rather than fabricating a claim. Fetching and
verifying the card itself works today.)

***

## 3. Orbit's platform Trust Card

Orbit publishes its own Trust Card at two addresses serving the same record:

* `https://orbit.devotel.io/.well-known/ans/trust-card.json` — the canonical,
  static record on the marketing domain.
* `https://api.orbit.devotel.io/api/v1/public/.well-known/ans/trust-card.json`
  — the API twin, so machine clients that only reach the API host resolve the
  identical document.

Both are unauthenticated, rate-limited on the public-read plan, and
edge-cacheable for five minutes. The record declares:

* `ansName` — Orbit's ANS URI (`ans://v1.0.0.orbit.devotel.io`).
* `endpoints` — the protocol surfaces Orbit speaks (HTTPS API, MCP,
  Agent2Agent) with each surface's capability functions and metadata URL.
* `verifiableClaims` — the Ed25519 JWK Set Orbit's agents sign outbound HTTP
  requests with (HTTP Message Signatures, RFC 9421), so a resolver can match
  a signed request's key id against the published keys. Orbit mints no
  ANS-only keypair: the card reuses the same signing keys that already
  authenticate its outbound machine traffic.
* `resolverStatus` — which parts of the draft's full resolution flow are not
  yet live on the public zone (DNS records, transparency receipt), stated
  explicitly.

A resolver verifies the card in four steps:

```bash theme={null}
# 1. Fetch the Trust Card (either host; the document is identical).
curl -s https://orbit.devotel.io/.well-known/ans/trust-card.json

# 2. Confirm the name binds to the expected domain: ansName must be
#    ans://v<version>.orbit.devotel.io, and every endpoint URL must sit
#    under orbit.devotel.io / api.orbit.devotel.io.

# 3. Pull the signing keys the card points at.
curl -s https://api.orbit.devotel.io/api/v1/public/.well-known/http-message-signatures-directory

# 4. For any signed outbound request you received from Orbit's agents, match
#    its key id against a key in that directory and verify the RFC 9421
#    signature. A key id that resolves to no published key fails outright.
```

The verification is deliberately conventional — standard JSON, standard JWK
Set, standard HTTP signatures — so any PKI tooling you already trust can do
it without an ANS-specific client.

***

## 4. The tenant-facing trust registry lookup

The card publishes Orbit's identity. The **trust registry** resolves *your
organization's* posture publicly — per organization, and only when you turn
it on. It answers the carrier/enterprise question "is this caller or agent
really this brand, and what is it delegated to do?" by composing every
verification signal Orbit already computes for you into one public resolve.

The lookup is a single GET under the same public well-known scope:

```
GET https://api.orbit.devotel.io/api/v1/public/.well-known/ans/registry/lookup
  ?org=<organization-slug>
  &agentId=<your-agent-id>      // or &ans=ans://v1.<your-agent-id>, or &phone=+18585550100
```

One resolve fans out to three halves:

* **Brand identity** — the same unified brand-identity rollup your dashboard's
  brand-identity status hub renders (registration and verification status per
  channel — SMS registration, toll-free, WhatsApp, RCS, branded calling,
  number verification). The registry reports the rollup's overall state,
  trust score, and how many of the channels that apply to your organization
  are verified.
* **STIR/SHAKEN attestation** — resolved with the same attestation logic the
  dial path stamps on the egress INVITE, so the registry reports the
  egress-time decision, not a registry-side guess. Per ATIS-1000074 the tier
  reads as `full` (A — verified number ownership), `partial` (B — delegate
  certificate or active pool lease), or `gateway` (C — unattributable). With
  no `phone` parameter the lookup reports `unknown-until-resolve` until a
  number is supplied. Orbit only ever *signals* the level; Devotel's carrier
  of record signs the PASSporT itself — the lookup is read-only and crosses
  no carrier for outbound traffic.
* **Delegated capability scope** — the capability surface of your
  organization's active API keys, resolved through the same **default-deny**
  scope ledger the hosted MCP server enforces (a scope not granted means no
  access), de-duplicated across keys and frozen as a settled snapshot. The
  response enumerates capability scope strings and MCP tool names only —
  key ids, hashes, and key material never cross this boundary.

An abbreviated response for a hit:

```json theme={null}
{
  "organization": "acme",
  "agent": { "id": "agt_support", "name": "Support concierge", "knowledgeBases": ["kb_help"] },
  "brandIdentity": { "overallState": "verified", "trustScore": 92, "verifiedChannels": 4, "applicableChannels": 5 },
  "stirShaken": { "attestationTier": "A", "tiers": "full" },
  "delegatedCapabilities": { "scopes": ["agents:run", "numbers:read"], "mcpTools": ["agents.run", "numbers.lookup"] }
}
```

Two deliberate properties keep the surface safe to publish:

* **404 collapse.** An unknown organization, an organization that hasn't
  opted in, and a malformed lookup all collapse to the same `404
  AGENT_TRUST_NOT_FOUND` envelope. A probe can neither enumerate tenants nor
  learn which organizations publish — one fixed blind spot for all three
  failure classes.
* **Cacheable.** Resolved answers carry a 60-second edge cache — short
  enough that a newly revoked agent stops resolving within a minute, long
  enough to absorb lookup fan-out from the parties that need it.

Responses are capability and verification metadata only — there is no
credential in the envelope, on either side.

***

## 5. Improving your attestation posture

What the registry reports is the same posture the rest of the platform
enforces, so raising it uses the levers you already have:

1. **Move calling identity onto numbers you own.** Full attestation (A)
   requires the calling number to be in your organization's own Orbit
   numbering records — purchased or ported in. Pool leases and delegate
   certificates top out at partial (B). The worked examples in the
   [STIR/SHAKEN attestation model](/concepts/stir-shaken-attestation-model)
   name exactly which shape reaches which level.
2. **Complete brand verification per channel.** The public trust score is
   the same roll-up the [brand identity and trust
   score](/concepts/brand-identity-trust-score) concept page describes; every
   verified channel (SMS campaign registration, toll-free verification, RCS
   branded agent, branded calling) lifts it.
3. **Register delegate certificates for BYON numbers.** A bring-your-own
   caller ID with a registered delegate certificate moves from gateway (C)
   to partial (B) — the delegated-attestation path, capped at B by design.
4. **Tighten delegated scope.** Keep API-key scopes minimal; the registry's
   capability surface is exactly the union of your *active* keys' scopes, and
   revoked keys drop out within one cache TTL.
5. **Turn on publication.** The registry answers for an organization only
   when its public trust-registry flag is enabled; the platform card requires
   no per-tenant action.

Set your target level and delegate registry on the [attestation
posture](/compliance/attestation) page; the same levers change what the
public lookup reports, because both read the one posture.

***

## 6. Cross-links

* [The STIR/SHAKEN attestation model](/concepts/stir-shaken-attestation-model) — levels A/B/C, the PASSporT flow, and remediation.
* [Attestation posture](/compliance/attestation) — your target level, delegate registry, and posture snapshot.
* [Brand identity and trust score](/concepts/brand-identity-trust-score) — the per-channel verification rollup the registry reports.
* [Hosted MCP server](/concepts/mcp-hosted-server) — the default-deny scope ledger behind the delegated-capability half.
* [A2A federation](/agents/a2a-federation) — the other public agent surface: per-agent discovery and signed task delegation.
* [Agent identity governance](/compliance/agent-identity-governance) — the tenant-owned inventory of every AI-agent identity the registry's delegated-capability half draws from.