OpenA2A Agent Identity Protocol (AIP)

3.1. Level 1: Local Identity

Agent identity is created and managed locally by an SDK or CLI, with no server required. This level is suitable for individual developers. It requires Ed25519 keypair generation (Section 4.1), a local identity file (Section 4.3), a local audit log (Section 11.1), and capability declaration (Section 5.1).¶

3.2. Level 2: Managed Identity

Agent identity is managed by an identity provider, adding verification, trust scoring, and centralized audit. This level is suitable for organizations. It requires all Level 1 features plus challenge-response verification (Section 6), trust scoring (Section 7), a server-side audit log (Section 11.2), API key or JWT authentication (Section 6.4), and drift detection (Section 10.4).¶

3.3. Level 3: Federated Identity

Agent identity is verifiable across organizations, adding DID resolution, verifiable credentials, and cross-platform trust. This level is suitable for ecosystem-wide deployment. It requires all Level 2 features plus DID-based agent identifiers (Section 4.2), Verifiable Credential trust assertions (Section 7.4), cross-platform capability negotiation (Section 5.3), and Agent Trust Protocol integration for ecosystem trust (Section 7.5).¶

4.1. Cryptographic Identity

Every agent MUST have an Ed25519 keypair [RFC8032]. The private key is 64 bytes and the public key is 32 bytes. The agent identifier is formed from the prefix "aim_" followed by the first eight hexadecimal characters of the SHA-256 digest of the public key, for example "aim_7f3a9c2e".¶

Implementations SHOULD also support a hybrid Ed25519 and ML-DSA-65 [FIPS204] keypair for post-quantum readiness. Both keys are generated simultaneously. The classical component is a 32-byte public key and a 64-byte private key; the post-quantum component is a 1,952-byte public key and a 4,032-byte private key. A hybrid signature concatenates a 64-byte Ed25519 signature with a 3,309-byte ML-DSA-65 signature. Classical-only verifiers check the Ed25519 signature; quantum-aware verifiers check both.¶

4.2. Decentralized Identifier (DID)

At Level 3, agents are identified by DIDs conforming to W3C DID Core [DID-CORE]. OpenA2A AIP uses the unified did:opena2a method, shared with the Agent Trust Protocol [ATP] and the Agent Trust eXtension [ATX]. The method syntax is:¶

did:opena2a:<type>:<id>

where the type component is one of the registered type prefixes: "agent", "authority", "publisher", "mcp_server", "a2a_agent", "skill", "ai_tool", or "llm". For agent identities at Level 3, the type is "agent", for example "did:opena2a:agent:aim_7f3a9c2e".¶

The DID Document includes the agent's public keys, capability references, and service endpoints:¶

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:opena2a:agent:aim_7f3a9c2e",
  "controller": "did:opena2a:authority:org_acme",
  "verificationMethod": [{
    "id": "did:opena2a:agent:aim_7f3a9c2e#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:opena2a:agent:aim_7f3a9c2e",
    "publicKeyMultibase": "z6Mkf5rGMoatrSj1f..."
  }],
  "capabilityInvocation": ["#key-1"],
  "service": [{
    "id": "#identity-provider",
    "type": "AgentIdentityProvider",
    "serviceEndpoint": "https://aim.example.com"
  }]
}

4.3. Identity File Format

Local identities are stored under a standard directory structure rooted at "~/.opena2a/aim-core/", containing an "identities/" directory of per-agent JSON files and an append-only "audit.jsonl" log. An identity file has the following form:¶

{
  "id": "aim_7f3a9c2e",
  "name": "my-agent",
  "type": "claude",
  "publicKey": "ed25519:x8Kp2mN...4RqW",
  "encryptedPrivateKey": "aes-256-gcm:...",
  "capabilities": ["file:read", "api:call"],
  "declaredPurpose": {
    "vocabVersion": "1",
    "category": "customer-support",
    "taskScopes": ["support:triage"],
    "capabilityJustification": {
      "file:read": ["support:triage"],
      "api:call": ["support:triage"]
    },
    "autonomy": "supervised"
  },
  "createdAt": "2026-03-22T10:00:00Z",
  "status": "verified"
}

Private keys MUST be encrypted at rest. The default encryption is AES-256-GCM with a key derived from the user's system keychain or a passphrase.¶

The "declaredPurpose" member is OPTIONAL. It is a structured declaration of what the agent is for, comprising "category", "taskScopes", "capabilityJustification", "autonomy", and the optional "dataScopes" and "egressScopes". It is an identity and attestation property and an offline detection signal; it MUST NOT be used as an authorization input, and a verifier MUST NOT reject an identity for lacking it. When carried in an ATX, declared purpose is covered by the signed payload. At the DID layer, declared purpose is surfaced only as a service-endpoint pointer, never inline in the DID Document body.¶

4.4. Agent Types

OpenA2A AIP defines a standard vocabulary for agent types, including "claude", "gpt", "gemini", "langchain", "crewai", "autogen", "semantic-kernel", "mcp-server", "a2a-agent", and "custom". The type is informational. It MUST NOT be used for security decisions; an agent claiming a given type is not verified as such by the type field alone.¶

5.1. Capability Format

Capabilities are expressed as "namespace:action" strings. Examples include "file:read" and "file:write" for filesystem operations, "db:read" and "db:write" for database operations, "api:call" for outbound API calls, "network:listen" for listening on network ports, "system:exec" for executing system commands, "mcp:tool_use" for invoking MCP tools, "data:pii_access" for access to personally identifiable information, and "payment:process" for processing financial transactions.¶

5.2. Reserved Namespaces

The following namespaces are reserved and have standardized meanings. The associated risk level is advisory.¶

Organizations MAY define custom namespaces prefixed with their domain, for example "acme.com/billing:charge".¶

5.3. Capability Negotiation

When an agent connects to a service, such as an MCP server, an A2A agent, or an API, the service SHOULD request the agent's declared capabilities, compare them against the capabilities required for the requested operation, reject the request if the agent lacks a required capability, and log the capability check result in the audit trail.¶

5.4. Capability Violations

When an agent attempts an action outside its declared capabilities, the identity provider MUST record a capability-violation event in the audit log, apply a trust score penalty proportional to the violation severity, and MAY block the action, which is configurable per policy. Violation severity levels and their indicative trust penalties are: low, an action attempted but not critical, penalty of -2%; medium, a sensitive action attempted, penalty of -5%; high, a dangerous action attempted, penalty of -10%; and critical, a system-level or financial action attempted, penalty of -20%.¶

6.1. Challenge-Response Protocol

Agent identity verification uses Ed25519 challenge-response. A relying party requests a challenge from the identity provider, which returns a random 32-byte challenge and an expiry. The relying party asks the agent to sign the challenge with its private key. The agent returns an Ed25519 signature and its public key. The relying party then verifies that the signature is valid for the challenge and public key, that the public key matches the registered agent, that the challenge has not expired within its five-minute window, and that the nonce has not been reused.¶

6.2. Protocol-Specific Verification

OpenA2A AIP defines verification flows for common protocols. For MCP [MCP], when an MCP client connects to an MCP server, the server requests a challenge, the client signs it with the agent key, the server verifies the signature against the identity provider, the server checks the client's capabilities against the required MCP tools, and the connection is accepted or rejected. For A2A [A2A], when agent A wishes to delegate a task to agent B, A includes a signed assertion in the A2A message, B verifies A's identity and trust score, B checks that A's capabilities include "agent:delegate", and B accepts or rejects the delegation.¶

6.3. Verification Events

Every verification attempt MUST be logged as a verification event carrying at least an event identifier, the agent identifier, the protocol, the verification type, the status, the signature, a message hash, a nonce, the duration, a drift-detection flag, an initiator descriptor, and a timestamp:¶

{
  "id": "evt_abc123",
  "agentId": "aim_7f3a9c2e",
  "protocol": "mcp",
  "verificationType": "identity",
  "status": "success",
  "signature": "base64...",
  "messageHash": "SHA256:...",
  "nonce": "base64...",
  "durationMs": 42,
  "driftDetected": false,
  "initiator": {
    "type": "agent",
    "name": "orchestrator-agent"
  },
  "timestamp": "2026-03-22T14:00:00Z"
}

6.4. Machine-to-Machine Authentication

For programmatic access, OpenA2A AIP supports API keys, which are SHA-256 hashed, stored server-side, and base64-encoded for transport; JWT bearer tokens [RFC7519], which are HMAC-SHA256 signed with a one-hour time-to-live and contain the agent and organization identifiers; and scoped SDK tokens for SDK operations such as agent registration and verification. A JWT carries subject, organization, issuer, audience, expiry, issued-at, and scope claims:¶

{
  "sub": "user_123",
  "org": "org_456",
  "iss": "aim.example.com",
  "aud": "aim-api",
  "exp": 1711137600,
  "iat": 1711134000,
  "scope": "agent:read agent:write"
}

7.1. Multi-Factor Algorithm

OpenA2A AIP defines a nine-factor trust scoring algorithm. Each factor contributes a weighted score. The composite score ranges from 0.0, no trust, to 1.0, full trust. The weights sum to 100.¶

The composite is computed as:¶

trust_score = sum over factors of
              ( factor_weight * factor_score * confidence )

where confidence is the data availability for each factor, from 0.0, no data, to 1.0, sufficient data. Factors with no data are excluded and their weights redistributed proportionally. All inputs to the trust calculation MUST be independently verifiable and MUST be computed server-side; an agent MUST NOT be able to self-report a trust score (see Section 13.4).¶

7.2. Trust Levels

Trust scores map to discrete levels for policy decisions. A score from 0.0 to 0.2 is Blocked, indicating an agent that is compromised or malicious. From 0.2 to 0.4 is Warning, indicating significant trust concerns. From 0.4 to 0.6 is Limited, indicating restricted access with monitoring required. From 0.6 to 0.8 is Standard, indicating normal operations. From 0.8 to 1.0 is Elevated, indicating eligibility for high-trust operations such as financial or PII access.¶

7.3. Trust Score History

Identity providers MUST maintain a trust score history recording, for each change, the previous score, the new score, and the delta; the reason for the change, such as verification, alert, drift, or manual action; a timestamp; and the actor that triggered the change.¶

7.4. Verifiable Credential Expression

At Level 3, trust scores SHOULD be expressible as W3C Verifiable Credentials [VC-DATA-MODEL], allowing a trust assertion to be carried and verified across platforms:¶

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://opena2a.org/credentials/v1"
  ],
  "type": ["VerifiableCredential", "AgentTrustCredential"],
  "issuer": "did:opena2a:authority:provider_opena2a",
  "issuanceDate": "2026-03-22T14:00:00Z",
  "expirationDate": "2026-03-23T14:00:00Z",
  "credentialSubject": {
    "id": "did:opena2a:agent:aim_7f3a9c2e",
    "trustScore": 0.82,
    "trustLevel": "standard",
    "capabilities": ["file:read", "api:call"],
    "verificationCount": 1847,
    "lastVerified": "2026-03-22T13:55:00Z"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-22T14:00:00Z",
    "verificationMethod":
      "did:opena2a:authority:provider_opena2a#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQp..."
  }
}

7.5. Agent Trust Protocol Integration

OpenA2A AIP trust scores feed into the Agent Trust Protocol [ATP] for ecosystem-wide trust. OpenA2A AIP provides behavioral trust, that is, how the agent acts in deployment, while the Agent Trust Protocol provides provenance trust, that is, how the agent's code was built and scanned. A combined ecosystem score is a weighted combination:¶

ecosystem_trust = alpha * aip_behavioral_trust
                + beta  * atp_provenance_trust

where alpha and beta are configurable weights that default to 0.5 each.¶

8.1. Portable Signed ATX Credential

Beyond the per-provider identity record, an agent's identity, capabilities, and trust level can be carried in an Agent Trust eXtension (ATX) [ATX]: a signed, portable credential that a relying party can verify offline without a network call to the issuing Registry. An ATX carries a hybrid signature composed of an Ed25519 signature and an ML-DSA-65 [FIPS204] signature, so that the credential remains verifiable in both a classical and a post-quantum setting. A verifier that encounters a credential declaring an ML-DSA-65 signature MUST verify at least one ML-DSA-65 signature in addition to at least one Ed25519 signature.¶

8.2. Transparency Log

A Registry maintains an append-only, RFC 6962-style [RFC6962] Merkle transparency log of identity and credential-issuance events. Recording issuance in a publicly verifiable Merkle log allows any party to obtain an inclusion proof for a credential and to detect divergent or backdated log views, so that the set of credentials an authority has issued is auditable rather than opaque.¶

9.1. Policy Format

Agent governance policies are expressed in YAML. Each policy binds a capability to an action, optionally with parameters such as approvers, a rate limit, or a period:¶

agent: aim_7f3a9c2e
policies:
  - name: "Require approval for file writes"
    capability: "file:write"
    action: "require_approval"
    approvers: ["user:admin@acme.com"]

  - name: "Block system commands"
    capability: "system:exec"
    action: "deny"

  - name: "Rate limit API calls"
    capability: "api:call"
    action: "rate_limit"
    limit: 100
    period: "1m"

9.2. Policy Actions

A policy action is one of: "allow", to permit without restriction; "deny", to block unconditionally; "require_approval", to queue for human approval before execution; "rate_limit", to allow up to a configured number of invocations per period; "audit", to allow but log for review; and "notify", to allow but send a notification to specified parties.¶

9.3. Relationship to Behavioral Governance

OpenA2A AIP governance policies provide technical enforcement, such as capabilities, rate limits, and approvals, enforced by the identity provider. They complement, and do not replace, behavioral governance enforced at the model runtime, such as injection hardening, data handling, and honesty constraints. An agent SHOULD have both.¶

10.1. States

An agent identity moves through a defined set of states: "created", the identity is generated but not yet verified; "pending", verification is in progress; "verified", the identity is cryptographically verified; "active", the agent is operating normally; "suspended", the agent is temporarily disabled, for example due to a policy violation or detected drift; and "revoked", the agent is permanently disabled, for example because it is compromised or decommissioned. A suspended agent may be reactivated to active; a revoked agent may not.¶

10.2. Key Rotation

Agents SHOULD rotate keys periodically. To rotate, the agent generates a new keypair and registers the new public key with the identity provider. A grace period then begins, configurable with a default of seven days, during which both the old and the new keys are valid. After the grace period, the old key is retired. During rotation the record carries the current key, the previous key, and the grace-period expiry.¶

10.3. Suspension and Revocation

An identity provider MUST support suspension, which is temporary and reversible and is triggered by events such as a policy violation, drift detection, or manual action; and revocation, which is permanent and irreversible and is triggered by confirmed compromise or decommissioning. Both MUST be logged in the audit trail with a reason, an actor, and a timestamp.¶

10.4. Drift Detection

The identity provider SHOULD monitor for configuration drift: capability drift, where an agent uses capabilities not in its registration; MCP drift, where an agent connects to MCP servers not in its declared list; and behavioral drift, where action patterns diverge from the historical baseline. When drift is detected, the provider logs a drift event, creates a security alert of high severity, applies a trust score penalty of -5% on first occurrence and -10% when repeated, and MAY suspend the agent, which is configurable per policy.¶

11.1. Local Audit Log

Level 1 implementations MUST maintain a local append-only audit log at "~/.opena2a/aim-core/audit.jsonl", where each line is a JSON event:¶

{"type":"identity_created","agentId":"aim_7f3a9c2e",
 "timestamp":"2026-03-22T10:00:00Z"}
{"type":"verification_success","agentId":"aim_7f3a9c2e",
 "protocol":"mcp","durationMs":42,
 "timestamp":"2026-03-22T10:01:00Z"}
{"type":"capability_violation","agentId":"aim_7f3a9c2e",
 "capability":"system:exec","severity":"critical",
 "blocked":true,"timestamp":"2026-03-22T10:02:00Z"}

11.2. Server Audit Log

Level 2 and higher implementations MUST maintain a server-side audit log in an append-only data store. Standard event types include "identity_created", "identity_verified", "identity_suspended", "identity_revoked", "capability_granted", "capability_revoked", "capability_violation", "trust_score_changed", "drift_detected", "key_rotated", "policy_evaluated", "a2a_delegation", and "mcp_connection".¶

13.1. Key Storage

Private keys MUST be encrypted at rest. Implementations SHOULD support the system keychain, hardware security keys via WebAuthn [WEBAUTHN], and HSM integration for server deployments. Private keys MUST NEVER be transmitted in plaintext; the identity provider stores only public keys.¶

13.2. Replay Attacks

Challenge-response verification MUST use single-use nonces with a maximum validity of five minutes. Nonces MUST NOT be reusable.¶

13.3. Capability Escalation

An agent MUST NOT be able to grant itself capabilities it does not have. Capability changes MUST be authorized by the identity provider or an administrator.¶

13.4. Trust Score Manipulation

Trust scores MUST be computed server-side. Agents MUST NOT be able to self-report trust scores. All inputs to the trust calculation, including verification events, uptime checks, and audit logs, MUST be independently verifiable.¶

13.5. Unverified Type and Declared-Purpose Fields

The agent type and the declared-purpose fields are informational attestations, not verified claims. They MUST NOT be used as authorization inputs, and a verifier MUST NOT reject an identity solely for lacking a declared purpose.¶