# Trust model

> The evidence supplied by a brand domain, a registry, and the support agent.

Open Service Directory (OSD) separates three sources of evidence: a brand’s endorsement, a registry’s admission checks, and the agent’s controls over customer access and operations. The assistant combines this evidence with its host’s trust policy to decide whether an agent fits the customer’s task.

## Brand endorsement

The brand publishes entries at `https://{osd:brandDomain}/.well-known/ard.json`. Each entry independently endorses the agent it describes. The agent and its card may be hosted on a support platform’s domain.

An endorsement applies solely to the specific entry listed. It does not cover:

- Other entries in the same manifest
- Other agents hosted on the same platform
- The registry that returned the candidate

OSD does not resolve confusing names or arbitrate brand legitimacy. The assistant must establish that the domain belongs to the business the customer meant.

## Registry admission checks

Each registry defines and documents its admission and maintenance checks. These may include domain and publication checks. Admission does not establish a business’s legitimacy, reputation, or service quality.

The assistant or its host chooses which registries to use. A registry’s earlier checks never replace the client’s own comparison with the brand’s published entry.

## Complete entry matching

A registry candidate is endorsed only when its complete entry structurally equals an entry in the
manifest retrieved from the intended brand’s domain. Every field participates, including optional
fields, nested values, and extension terms. Search annotations such as `score` and `source` do not.

A check has three outcomes:

| Outcome | Meaning |
| --- | --- |
| Match | The candidate equals a published entry. It carries the brand’s endorsement |
| Mismatch | The manifest is valid but no entry matches. The candidate has no endorsement. This may indicate a temporary propagation delay or an unauthorized listing. It is not definitive proof of fraud |
| Inconclusive | The manifest could not be retrieved or validated. Endorsement cannot be established |

Nothing else turns a mismatch or inconclusive result into a match: not a high relevance score, a familiar source, or several registries agreeing.

For a `url` entry, a match verifies the published reference. It does not establish that the fetched
card is unchanged or that the agent behaves safely. Inline `data` is compared too, but matching it
says nothing about the agent’s behavior either.

## Assessing trust evidence

`source` identifies the registry where the entry was indexed, and `score` is semantic relevance to the query. The assistant’s trust policy weighs these alongside endorsement, suitability, organizational rules, and the risk of the action.

ARD’s optional `trustManifest` carries identity, attestations, and signatures, and its [publisher-authority binding](https://agenticresourcediscovery.org/spec/#451-publisher-authority-binding) ties the trust identity to the publisher domain in the entry’s identifier. That answers a different question from OSD’s brand-domain endorsement. A structural match does not verify signatures or attestations. Those follow their declared trust framework. 

## Agent authorization

After discovery, the assistant connects through the agent’s native protocol. The protocol and the agent’s own controls govern authentication and authorization. The agent can limit operations, require customer confirmation, and reject requests regardless of discovery. The assistant also obtains any confirmation its host’s policy requires.