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 and ATP. The AAP broker is Secretless; did:opena2a resolution is the Registry.

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.

SOURCE · opena2a-org/agent-identity-management

Where the specs become real

The four specs above are paper. AIM is the working steel, the reference platform for AIP, ATX and ATP 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 stack without assembling it by hand. Two layers live elsewhere by design: did:opena2a resolution runs in the OpenA2A Registry, and the AAP credential broker runs in Secretless.

One platform, every layer

did:opena2aConsumed, not served: AIM names agents with did:aip: identifiers; did:opena2a DIDs are minted and resolved by the OpenA2A Registry.
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.
AAPSupplies the developer surface (@agent.perform_action) and 5-step fine-grained authorization; the grant:// credential broker is Secretless, the AAP reference implementation.
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 naming is aligning to ATX). AIM's own DID method is did:aip:; did:opena2a is the Registry-anchored method defined by its W3C-filed spec. 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), TypeScript (npm install @opena2a/aim-core), or Java (sdk/java in the AIM repo; Maven Central publication pending).

  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.