OpenA2A /specs
AIM1.0.0Reference implementation

Agent Identity Management

The reference platform that mints identities, issues credentials, runs 5-step authorization and keeps the audit trail, the working implementation of AIP, ATX, ATP, AAP and did:opena2a.

The question it answers

Where do all these specs actually run?

If you know one thing already

It’s like The CA software + IAM server for agents.

Where the specs become real

The four specs above are paper. AIM is the working steel, the reference platform that implements all of them behind a developer experience that fits on one line: secure("my-agent"). It mints identities, issues credentials, enforces authorization, and records everything, so a developer gets the entire stack without assembling it by hand.

One platform, every layer

did:opena2aMints agent identifiers and resolves DID Documents, the name and key for every agent.
AIPGenerates keypairs, runs challenge-response verification, and computes the 9-factor trust score (the TrustCalculator).
ATXIssues the signed, capability-scoped, time-bounded credential and verifies it locally on the way in.
ATPKeeps the immutable audit trail and trust-score history, every action, logged and queryable.
AAPEnforces authorization on every call through 5-step fine-grained authorization, gating access by trust.
Note

A note on names

AIM is the reference implementation and is converging on the spec vocabulary as the standards finalize (for example, the credential and DID-method names are aligning to ATX and did:opena2a). Treat the specs as the normative source; AIM as the place they run.

The developer workflow

From a developer's seat, the whole stack collapses into install, one call, and one decorator. Everything else happens underneath.

  1. 1
    1Install the SDK

    Python (pip install aim-sdk), Java (org.opena2a:aim-sdk), or TypeScript (@opena2a/aim-sdk), feature-parity across all three.

  2. 2
    2Register the agent

    secure("my-agent") generates an Ed25519 keypair, registers the public key, and returns an identity + DID. The private key stays local.

  3. 3
    3Declare a capability

    Wrap a function with @agent.perform_action(capability="db:read"). That declaration is what authorization checks against.

  4. 4
    4Call, and get verified

    On each call the SDK signs the request; the backend runs 5-step authorization before the function executes.

  5. 5
    5Everything is logged

    Outcome, trust-score update and audit entry are written automatically. Nothing extra to wire up.

The entire stack, from a developer's viewpython
from aim_sdk import secure

agent = secure("weather-agent")          # identity + DID, one line

@agent.perform_action(capability="weather:fetch", risk_level="low")
def get_weather(city: str):
    return requests.get(API, params={"q": city}).json()

get_weather("San Francisco")
# → request signed, 5-step authorization runs, action logged,
#   trust score updated, all automatically

5-step fine-grained authorization

This is AIM's implementation of AAP's enforcement, run on every action. Each step is fast and cheap; only the riskiest calls pay for the deepest check.

  1. 1
    1 · CapabilityIs this capability declared?< 10ms

    The agent must have declared the capability it is now invoking.

  2. 2
    2 · AttributeAre the request attributes allowed?< 10ms

    Fields, data classes and parameters checked against policy.

  3. 3
    3 · ContextDo the contextual rules pass?< 10ms

    Time, location, data sensitivity and similar conditions.

  4. 4
    4 · ChainIs the delegation chain valid?< 10ms

    For agent-to-agent calls: trust attenuates with each hop; depth is bounded.

  5. 5
    5 · IntentWhat is the agent trying to do?high-risk

    An intent classifier screens high-risk actions (exfiltration, privilege escalation) before they run.

Key idea

Trust gates access

Each capability carries a minimum trust threshold, low-risk actions need little, critical ones (payments, PII) need a high score. Trust from AIP, carried by ATX, is what these gates read.

What's in the box

  • Backend, the registration, authorization, trust-scoring and audit services.
  • SDKs, Python, Java and TypeScript, with auto-detection for popular agent frameworks.
  • Dashboard, agents, trust-score breakdowns, alerts, audit log, policies and webhooks.
  • Observability, OpenTelemetry traces over every authorization decision, plus SIEM adapters.
Tip

Two ways in

Start here is the five-minute tour; the layered stack explains why the order matters. For readers fluent in PKI, the web analogy maps every piece to something the web already uses.