Glossary

Words this landscape overloads

“Agent”, “p2p”, “token”, and even “authorization server” do not mean the same thing in every room. These definitions match how the bundled specs use them. On the boards, a token is a pass, a signature is a wax seal, Bearer is a photocopy, and DPoP is a pass glued to a key.

Access token: Credential the client presents to a resource server. In OAuth 2.0 it may be opaque; RFC 9068 profiles it as a JWT (typ at+jwt). It is not an ID Token.; JWT access tokens Bearer tokens
act (actor) claim: RFC 8693 JWT claim recording that the token presenter is acting for the subject. Nested act objects represent multi-hop delegation (A then B then C).; Token Exchange
Agent: In this landscape: software that iteratively calls a model and tools. IETF AIMS treats it as a workload. AAuth treats it as any HTTP client with its own key. DIDComm uses 'agent' for a wallet endpoint — not the same thing.; AIMS (agent auth BCP)AAuth
Agent Card: A2A JSON document at /.well-known/agent-card.json describing identity, skills, interfaces, and securitySchemes. Optional JWS proves integrity of the card, not of later requests.; A2A (Agent2Agent)
Agent token (AAuth): JWT of type aa-agent+jwt binding an agent identifier to a signing key (cnf.jwk). Presented via the Signature-Key header, not as a bearer Authorization token.; AAuth
Audience (aud): Who is intended to accept a token. Access tokens should be audience-restricted to the API (RFC 8707/9068). ID Tokens are audience-restricted to the client. Mix-ups here are a leading agent-security bug.; Resource Indicators JWT access tokens OpenID Connect Core
Authorization server (AS): OAuth role that authenticates the resource owner (often via OIDC), authenticates the client, and issues tokens. AAuth's 'access server' is the resource-side cousin in four-party mode.; OAuth 2.0 AAuth
Bearer token: A token that grants access to whoever presents it. RFC 6750. Contrast sender-constrained tokens (DPoP, mTLS, HTTP Message Signatures).; Bearer tokens DPoP mTLS sender-constrained tokens
CIBA: Client-Initiated Backchannel Authentication: the client starts auth/consent without a browser redirect; the user approves on another device.; CIBA
CIMD: Client ID Metadata Document: the client_id is an HTTPS URL the AS fetches. WG draft; MCP prefers this over Dynamic Client Registration.; Client ID Metadata Documents Dynamic Client Registration
client_id: Identifier of an OAuth client at one authorization server. Not a global agent identity. AAuth exists partly because this identifier does not travel.; OAuth 2.0 AAuth
Confidential vs public client: Confidential clients can keep a secret (or private key) on a server. Public clients cannot (browsers, many native apps, many local agents). OAuth 2.1 simplifies the distinction to 'has credentials or not'.; OAuth 2.1
Confused deputy: A client with delegated authority is tricked into using it at the wrong resource or for the wrong purpose. Audience restriction, PKCE, and actor claims are mitigations.; Resource Indicators PKCE Token Exchange
DPoP: Demonstrating Proof of Possession: per-request signed JWT binding an OAuth access token to a client key without requiring mTLS.; DPoP
Dynamic Client Registration (DCR): RFC 7591: POST metadata to mint a client_id at runtime. MCP 2026-07-28 deprecates it in favor of CIMD.; Dynamic Client Registration Client ID Metadata Documents
FAPI 2.0: OIDF high-security profile of OAuth (PAR, PKCE, sender-constrained tokens, …) used in open banking and other high-value APIs.; FAPI 2.0
GNAP: Grant Negotiation and Authorization Protocol (RFC 9635). A completed IETF alternative to OAuth, not an OAuth extension and not wire-compatible.; GNAP
ID Token: OpenID Connect JWT authenticating the user to the client. Never send it to an API as if it were an access token.; OpenID Connect Core
ID-JAG / XAA: Identity Assertion JWT Authorization Grant, informally Cross-App Access: IdP mints a JWT grant for another app's AS so an agent/app can call that API under enterprise policy.; Cross-App Access (ID-JAG)Identity chaining
Issuer (iss): Who minted a token or metadata document. Compare exactly. RFC 9207 puts iss in the authorization response to stop mix-up attacks.; AS issuer identification AS metadata
JWT: JSON Web Token (RFC 7519): a signed or encrypted claims container. Profiles (ID Token, at+jwt, WIT, aa-agent+jwt) decide the semantics.; JWT
MCP: Model Context Protocol: how model hosts expose and call tools. HTTP authorization is an OAuth 2.1 profile, not a new token type.; MCP authorization
MCP host: The application that owns the model session and is the OAuth client in MCP HTTP — Claude Desktop, an IDE, a custom runtime. Distinct from the MCP server, which is the tool/resource. Stdio MCP is a local pipe and does not use the HTTP OAuth profile.; MCP authorization
Mission (AAuth): Optional natural-language description of what the agent intends, approved at the person server and bound by SHA-256. Governance that cannot be reduced to static scopes.; AAuth
Mix-up attack: The client is tricked into mixing tokens or codes from two authorization servers. Mitigated by RFC 9207 iss and exact issuer metadata checks.; AS issuer identification
On-behalf-of (OBO): Pattern where a service calls downstream as itself acting for a user. In IETF terms this is Token Exchange (RFC 8693) with subject and actor, not a separate grant name.; Token Exchange
PAR: Pushed Authorization Requests (RFC 9126): POST the authorize parameters to the AS, redirect with a short request_uri.; PAR
Person server (PS): AAuth role representing the user: issues auth tokens, runs missions, permission, audit, and interaction. Orthogonal to which resource-access mode is in use.; AAuth
PKCE: Proof Key for Code Exchange (RFC 7636). Stops authorization-code interception. Required for authorization-code clients in OAuth 2.1.; PKCE OAuth 2.1
P2P (in this landscape): Overloaded. (1) AAuth identity-based or two-party access: agent↔resource with no AS. (2) A2A agent-to-agent communication. (3) did:peer / DIDComm pairwise identity. There is no IETF RFC titled 'P2P OAuth' in this cluster. The deployment matrix keeps those as separate rows.; AAuth A2A (Agent2Agent)did:peer
Protected Resource Metadata: RFC 9728 JSON document a resource publishes so clients can discover its authorization servers and capabilities.; Protected Resource Metadata
RAR: Rich Authorization Requests (RFC 9396): structured authorization_details instead of only scopes.; RAR AAuth R3
Resource owner: OAuth term for the entity that can grant access — usually a human, sometimes an organization or the client itself (client-credentials).; OAuth 2.0
Resource server (RS): The API or tool. In MCP HTTP, the MCP server is the RS. In AAuth, the 'resource' plays this role.; OAuth 2.0 MCP authorization
Scope: Space-delimited OAuth permission strings. Too coarse for many tool calls; see RAR and AAuth R3.; OAuth 2.0 RAR
Sender-constrained token: An access token that can only be used by a presenter who proves a key (DPoP, mTLS certificate, HTTP signature). Contrast bearer.; DPoP mTLS sender-constrained tokens HTTP Message Signatures
Sidecar (mesh): A helper process next to a workload that presents SPIFFE/WIMSE identity, usually via mTLS. The agent binary is still the workload; the sidecar is how identity is injected. Unattended: there is no OIDC user sub on this hop.; SPIFFE / SPIRE WIMSE architecture
SPIFFE / SPIRE: CNCF workload identity: SPIFFE IDs and SVIDs, typically issued by SPIRE from platform attestation. IETF WIMSE generalizes multi-system aspects.; SPIFFE / SPIRE WIMSE architecture
Step-up: RFC 9470: the resource demands a stronger or fresher user authentication before serving a request.; Step-up authentication
Transaction token (Txn-Token): Short-lived JWT propagating user, workload, and purpose across a call chain inside a trust domain. WG draft.; Transaction Tokens
Person token (AAuth): Editor's-copy JWT typ aa-person+jwt: a directed identifier of the person at one resource. Identifies, does not authorize. Absent from draft-10's four-mode table. Must not be accepted where an auth token is required.; AAuth
Signature-Key: HTTP header from draft-hardt-httpbis-signature-key that conveys or points at the public key for an RFC 9421 signature. AAuth puts the agent (or person/auth) JWT here with scheme=jwt.; HTTP Signature Keys AAuth
WIMSE: Workload Identity in Multi-System Environments: IETF WG architecture and credential drafts for workload identifiers, WIT/WIC, and proofs (WPT, HTTP signatures, mTLS).; WIMSE architecture
WIT / WPT: Workload Identity Token (credential) and Workload Proof Token (per-request PoP). WIMSE drafts; WIT must not be used as a bearer token.; WIMSE credentials WIMSE WPT
Workload: Software executing for a purpose, possibly many instances. AIMS: an agent is a workload. Distinct from the user it may serve.; WIMSE architecture AIMS (agent auth BCP)