Glossary

Terms marked with a dotted underline elsewhere in these docs show their definition when you hover over them, and link here.

AIGW concepts

These are AIGW's own objects and flows. They have specific meanings in AIGW that may differ from how other products use the same words.

Account

The top-level AIGW tenant. It owns Projects, team membership, enabled identity providers, billing, and API keys.

Agent policy

Project or Resource rules that approve, hold, or reject an agent the first time it asks for a Resource. The default approves everyone.

Agent status

Where an agent stands in a Project: Pending (held, requests refused), Approved, Rejected, or Revoked.

AIGW

AI Gateway by LoginID: the identity and authorization layer between AI agents and the services they act on.

AIGW access token

The token an agent receives after the user authorizes it. It says which user approved which agent for which scopes.

AIGW Console

The AIGW developer dashboard (DevCon) where you manage Accounts, Projects, Resources, agents, and policies.

Approval rules

The part of Agent policy that sets Approve, Hold, or Reject for unverified agents and for each kind of agent proof.

Core issuer

The shared AIGW authorization server that issues agent-facing access tokens and hosts the token endpoint.

Credential redemption

POST /api/credentials/token: the MCP/UCP service trades the user's AIGW token plus its Proxy token for the merchant access token.

Domain rules

Agent policy rules that approve, hold, or reject agents from a specific domain and its subdomains. Checked before approval rules.

End user

A person an agent has acted on behalf of at a Project's Resources, as listed in the AIGW Console.

KYA issuers

The per-Project (or per-Resource) whitelist of KYA credential issuers AIGW accepts, each with a minimum trust level.

Merchant access token

A token issued by the merchant's own authorization server. Only the MCP/UCP service sees it, never the agent.

OAuth client Resource

A Resource for ordinary human sign-in, where AIGW acts as the application's identity provider.

Per-resource issuer

The AIGW authorization server dedicated to one Resource, at /<RESOURCE_ID> on the AIGW API host. Agents discover it; merchants trust it.

Project

The isolation boundary for an integration. It holds Resources, agents and agent policy, end users, and Proxy clients.

Proxy client

The server-side credential (client ID and secret) the MCP/UCP service uses to authenticate itself to AIGW. Never give it to an agent.

Proxy token

A short-lived token the MCP/UCP service gets with its Proxy client, sent as X-Proxy-Token when redeeming a merchant token.

Reference screen

The last step of Resource registration, listing the values to hand to the merchant IAM team and to agent developers.

Resource

The downstream system registered in a Project. Its kind (Token exchange or OAuth client) decides the role AIGW plays.

Resource indicator

The exact identifier (audience) of the merchant API. The MCP/UCP service sends the same value when redeeming the merchant token.

Signing key

A per-Resource ES256 key AIGW uses to sign assertions sent to the merchant authorization server, published at the Resource JWKS URL.

Token exchange Resource

A Resource for agent access: AIGW authorizes the user and obtains a token from the merchant's own authorization server.

Token Vault

Where AIGW stores merchant tokens, encrypted and keyed by Project, user, and Resource, and refreshes them when they expire.

Standards and general terms

Industry standards and identity terms AIGW builds on.

acr

Authentication Context Class Reference: how strongly the user was verified, for example an al2 value for assurance level 2 from the identity verification provider.

amr

Authentication Methods References: how the user authenticated, for example pop (passkey), sms, mfa, or otp.

CIMD

Client ID Metadata Document: an agent uses an HTTPS URL as its client_id and serves its metadata there, so no registration call is needed.

Consent

The screen where the user reviews the scopes an agent requests and approves or denies them.

DCR

Dynamic Client Registration (RFC 7591): an agent registers itself as an OAuth client at runtime, with no manual setup.

JWKS

JSON Web Key Set: a published set of public keys used to verify JWT signatures.

JWT bearer grant

RFC 7523: AIGW presents a signed assertion about the user and receives a merchant token for that user.

KYA

Know Your Agent: a credential from a third-party issuer that vouches for an agent.

MCP

Model Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server.

Passkey

A phishing-resistant FIDO2 credential stored on the user's device, offered through the LoginID identity provider.

Phone verification

A built-in identity verification provider that checks the user holds the phone for a number and can return verified identity data.

PKCE

Proof Key for Code Exchange: binds an authorization request to the later code exchange so a stolen code is useless.

Platform-trusted

An agent whose domain is on the curated list of known agent platforms maintained by AIGW.

Possession check

Proof that the user physically holds the phone for a number, for example by opening an SMS link.

private_key_jwt

OAuth client authentication with a signed JWT instead of a shared secret. AIGW uses it toward the merchant authorization server.

Protected Resource Metadata

An RFC 9728 document an MCP/UCP service publishes to tell agents which authorization server protects it.

Reverse DNS

Forward-confirmed reverse DNS: the agent's IP address resolves to a name in its domain, and that name resolves back to the IP.

Token exchange (RFC 8693)

An OAuth grant that trades one token (an AIGW-signed subject token) for another issued by the merchant authorization server.

Trust level

How strongly a KYA credential is bound to the presenting agent: Trusted, Known, Declared, Unbound, or Untrusted.

UCP

Universal Commerce Protocol: a standard interface that lets agents carry out commerce tasks with a merchant.

Web Bot Auth

An agent signs its HTTP requests (RFC 9421 HTTP Message Signatures) with keys published in its own signature directory.