---
title: "Glossary"
description: "Canonical definitions of the terms this site uses, one per term, with a link to the page that owns the detail."
image: "https://docs.agentregistrar.dev/og/docs-default.png"
---

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

# Glossary

One definition per term. Other pages link here instead of defining the same word again; the [key concepts](/start/concepts/) page is the short version for the quickstart. Where a term maps to a wire field, the field name is in backticks.

## Roles and records

**Human owner.** The verified human principal behind every agent. The human verifies an email address, signs the Master Agent Delegation agreement, and is attributed for what the agent does. The broker identifies the principal with `human.id`, and assertions carry `human.verified`. See [Key concepts](/start/concepts/#roles-and-records).

**Agent (agent sub-identity).** A broker record with an id (`agt_...`), a display name, a harness label, a dedicated inbox address and delegated scopes. It is not a model and not a process; it is the identity the model acts under. Created or resumed by `identity_register`. See [MCP tools](/reference/mcp-tools/#identity_register).

**Harness.** The client that connects to the broker's MCP endpoint and runs the agent, such as OpenCode V2, Claude Code, Codex CLI, Cursor, Gemini CLI, VS Code, Claude Desktop or a generic MCP client. The harness holds the OAuth session and the bearer token; the agent sub-identity is bound to that token's human owner. See [Agents and harnesses](/agents/).

**Broker.** The service that verifies the human, holds the agent sub-identity and inbox, mints assertions, records acceptances and signup receipts, and exposes the MCP tools. In this documentation the broker is `https://agentregistrar.dev`. The first release uses one broker as both the human broker (A) and the relying party's broker (B); the protocol and token shapes keep the roles separate. See [Broker HTTP and OAuth](/reference/broker-http/).

**Relying party (provider).** A service that accepts brokered agent signups by publishing a discovery document and verifying an assertion. VaporCloud is the reference implementation in the tutorials. A provider may also publish an optional broker-issued verification credential; a conformant provider without one is unverified, not invalid. See [Providers](/providers/).

**Delegated scopes.** The permissions an agent holds, stored on the agent row and embedded in the assertion as `delegation.scopes`. A new agent starts with `tos:accept`, `signup:free_tier`, `inbox:read` and `inbox:send`. See [Assertion claims](/agent-identity/v1/assertion-claims/#claim-set).

## Protocol artifacts

**Discovery document.** The identity-only JSON at `GET /.well-known/agent-signup.json` on the provider's origin: protocol version, audience, provider name, issuer allowlist, required scopes, the terms and exactly one endpoint, `agent_signup`. It never carries vendor capabilities. See [Discovery fields](/agent-identity/v1/discovery-fields/).

**Issuer allowlist.** The `issuer_allowlist` array in a discovery document: absolute issuer origins the provider accepts, with trailing slashes normalized away. The broker's `iss` must match one entry exactly, and the provider rejects anything else with `issuer_not_allowed`. See [Discovery fields](/agent-identity/v1/discovery-fields/#required-fields).

**Required scopes.** The `required_scopes` array in a discovery document: the scopes a provider demands for its signup. Brokered signup must include `tos:accept`, and the assertion's `delegation.scopes` must cover every entry or the provider returns `insufficient_scope`. See [Discovery fields](/agent-identity/v1/discovery-fields/#required-fields).

**Terms.** The provider's agreement as three fields: `terms.text` (the complete text), `terms.url` (where a human reads it) and `terms.version`. `terms.sha256` is the digest of the exact UTF-8 bytes of `terms.text`; a changed text requires a new version and hash, and a fresh acceptance. See [ToS binding](/agent-identity/v1/specification/#6-tos-binding).

**Master Agent Delegation agreement (master ToS).** The one agreement a human owner signs with the broker, delegating ToS acceptance for their agents. Its version and hash appear in the assertion as `delegation.master_tos_version` and `delegation.master_tos_hash`. See [Trust and limits](/start/trust-and-limits/).

**Assertion.** A short-lived Ed25519-signed JWT that proves the agent, the verified human owner and the delegated ToS acceptance for one audience. The broker mints it with `identity_signup` (default) or `identity_prove` (advanced); the agent sends `assertion.jwt` verbatim to `endpoints.agent_signup` and nowhere else. The default lifetime is five minutes. See [Assertion claims](/agent-identity/v1/assertion-claims/).

**Claims.** The JSON payload inside an assertion, `assertion.claims`: `iss`, `sub`, `aud`, `jti`, `iat`, `exp`, and the `agent`, `human` and `delegation` objects. Claims are for inspection; the signed JWT is the proof, and it must not be decoded and edited. See [Assertion claims](/agent-identity/v1/assertion-claims/#claim-set).

**JTI.** The `jti_...` identifier of one assertion issuance. A provider treats a repeated `jti` for the same agent, account and service as idempotent, and a `jti` reused in a conflicting context as `assertion_replayed`. See [Provider handshake errors](/reference/error-codes/#provider-handshake-errors).

**Acceptance.** A durable consent event recorded in the broker's acceptance ledger: one per agent, audience and terms hash, with the accepted URL, hash, master agreement version and time. Assertions are short-lived proofs that reference an acceptance; re-minting an assertion does not create a new consent. See [MCP tools](/reference/mcp-tools/#identity_prove).

**Ledger.** Two records share the name. The acceptance ledger (`tos_acceptances`) holds one row per consent event; the service signups ledger (`service_signups`) holds one proof row per provider account an agent signed up for. Neither is a resource inventory. See [ToS and the ledger](/agents/tos-and-ledger/).

**ToS Acceptance Ledger email.** The receipt the broker sends after an acceptance is recorded: one copy to the agent inbox and one forward to the human owner's verified address. It is dispatched at most once per acceptance. See [MCP tools](/reference/mcp-tools/#identity_prove).

**Signup receipt.** The provider's RP-signed record that a signup happened: identity facts, the accepted terms and an optional context pointer. It travels as the `signup_token`, names the attestation and key that signed it, and has no `exp` in v1.2. See [Receipt and context](/agent-identity/v1/receipt-and-context/).

**`signup_token`.** The wire name of the RP-signed receipt token (`srp_...` `jti`), returned in the provider's signup response or sent to Contract F. It is not a provider credential and cannot be used to call the provider. See [Broker HTTP and OAuth](/reference/broker-http/#post-apibrokersignup-receipt).

**Context guide (context pointer).** A hash-pinned URL to the provider's post-signup guide, usually a `SKILL.md`, where provisioning, SKUs, API usage and credential recovery live. The pointer is `context.url` plus `context.sha256`; the agent fetches the guide, verifies the digest, and treats the content as untrusted data. See [Receipt and context](/agent-identity/v1/receipt-and-context/#the-context-pointer).

**Resolution.** The optional provider field in a signup response: `"created"` when the account was created, `"resolved"` when an existing account was reused. A resolved outcome is a success, not an error, and must not mint new credentials or duplicate mail. See [Receipt and context](/agent-identity/v1/receipt-and-context/#the-signup-response).

**Provider credential.** The vendor secret, such as an API key, returned once at the signup handoff. The broker never stores, proxies or re-issues it; the agent must persist it at handoff and recover it through the provider's documented path, never by re-running signup. See [Credential handoff and recovery](/agent-identity/v1/receipt-and-context/#credential-handoff-and-recovery).

**Provider account.** The provider's organization membership with its RP broker: origins, audience, public keys, attestation, receipts, abuse standing, and listing. A provider account is required only to be a verified provider, issue authenticated receipts, or report abuse with standing. It is not required to verify an assertion. See [Provider quickstart](/providers/quickstart/).

**Provider verification credential.** The broker-issued credential (the RP attestation) that binds a provider's canonical origin, audience, identity, assurance level, and public keys. It is public, optional, and verified locally against the RP broker's JWKS. Public copy uses this term so bare `provider credential` keeps its signup-secret meaning. See [Trust and limits](/start/trust-and-limits/).

**Verified provider.** A provider whose published verification credential was checked and whose policy accepted it at `checked_at`. Verification records identity, not safety, approval, endorsement, uptime, solvency, or conduct. See [Trust and limits](/start/trust-and-limits/).

**Unverified provider.** A conformant provider that publishes no verification credential, or whose credential did not verify. It is not invalid; `allow`/`warn` may proceed and `require` refuses. See [Trust and limits](/start/trust-and-limits/).

**Trust list.** The RP-broker issuers a human trusts, on top of the broker default, with a human `distrust` override winning. Trust is policy, not cryptography, and is not transitive. See [Trust and limits](/start/trust-and-limits/).

**Conformance vs verification.** Conformance is a document-shape check on discovery. Verification is a separate check of a broker-signed credential. A malformed credential field is a conformance error; an expired, invalid, untrusted, or unavailable credential is a verification result. Never collapse the two. See [Conformance](/agent-identity/v1/conformance/).

**Proof source.** The strength/transport label on a signup proof: `rp_callback` (Tier 1), `rp_signed` (Tier 2), `agent_self_reported` (weaker, unsigned), or `legacy_broker_signed` (historical, unverified). Only the first two, with a verified attestation, give an abuse report standing. See [Receipt and context](/agent-identity/v1/receipt-and-context/#contract-f-and-proof-sources).

**Status at signup / current status.** Status at signup is the verification recorded for that signup. Current status is the latest recorded status for the same origin and audience, with local overrides, plus `checked_at`. Current is historical, not a live feed. See [Trust and limits](/start/trust-and-limits/).

## MCP and transport

**Model Context Protocol (MCP).** The JSON-RPC 2.0 protocol the broker serves at `/mcp`, with tools, resources and `initialize` instructions. The broker reports server name `agentregistrar`, version `1.0.0`. See [MCP tools](/reference/mcp-tools/#endpoint-and-discovery).

**MCP tool.** One callable operation in `tools/list`. The broker exposes nine: four identity tools, four inbox tools, and the one-call `identity_signup`. A tool failure returns `isError: true` with the structured error envelope, not an HTTP error. See [MCP tools](/reference/mcp-tools/).

**MCP resource.** A read-only, static `text/markdown` document served by `resources/list` and `resources/read` under `agentregistrar://docs/...`. Resources are supporting depth; the tool result and the public docs page stay authoritative. See [MCP resources](/reference/mcp-tools/#mcp-resources).

**MCP bearer token.** The opaque `mca_...` OAuth 2.1 access token a harness sends as `Authorization: Bearer` to `/mcp`. It is bound to one human owner, lives 24 hours, and only its SHA-256 hash is stored. See [Broker HTTP and OAuth](/reference/broker-http/#authentication-at-a-glance).

**OAuth 2.1.** The authorization framework the broker uses: authorization code with PKCE `S256`, rotating refresh tokens and a consent page where the human approves the harness. See [Broker HTTP and OAuth](/reference/broker-http/#oauth-21).

**Dynamic client registration (DCR).** RFC 7591 registration at `POST /api/oauth/register`, where a client supplies its redirect URIs and receives a `cli_...` client id. See [Broker HTTP and OAuth](/reference/broker-http/#post-apioauthregister).

**Client ID Metadata Document (CIMD).** A client whose `client_id` is an HTTPS URL pointing at its own metadata document. The broker advertises support with `client_id_metadata_document_supported: true` and resolves the document on demand. See [Broker HTTP and OAuth](/reference/broker-http/#post-apioauthregister).

## Operations

**Kill switch.** The per-agent revocation control in the portal. It makes new assertions and further `identity_register`, `identity_whoami`, `identity_prove` and inbox calls for that agent fail with `agent_revoked`; `identity_record_signup` still records historical receipts. It does not delete provider accounts, revoke provider credentials or undo accepted terms. See [Identity lifecycle](/agents/identity-lifecycle/).

**Abuse report.** A relying party's authenticated report against an agent, sent to `POST /api/broker/report-abuse` as `{rp_attestation, report}` where `report` is a five-minute JWS. A report linked to an RP-signed signup with a verified attestation is `verified` and may apply a protective suspension pending operator review; an unlinked or self-reported one is `unverified` and opens a case without suspending. See [Report abuse](/providers/guides/abuse-reporting/).

**Revocation and suspension.** Revocation is the human kill switch: the agent row moves to `revoked`, enforced when the broker mints an assertion or serves an identity/inbox call; `identity_record_signup` still records historical receipts. Suspension is an operator protective action: the agent row moves to `suspended`, requires operator restore, and cannot be cleared by the human kill switch. Both block minting; neither deletes provider accounts or reclaims credentials. See [Trust and limits](/start/trust-and-limits/).

## Related

- [Key concepts](/start/concepts/) for the short version used in the quickstart.
- [Error codes](/reference/error-codes/) for the codes named in these definitions.
- [Specification](/agent-identity/v1/specification/) for the normative contract behind each term.

Source: https://docs.agentregistrar.dev/reference/glossary/index.mdx