Individual Submission A. Fane Internet-Draft OpenA2A Intended status: Standards Track 30 September 2026 Expires: 3 April 2027 OpenA2A Agent Identity Protocol (AIP) draft-fane-opena2a-aip-03 Abstract This document defines the OpenA2A Agent Identity Protocol (OpenA2A AIP), an open standard for creating, managing, and verifying cryptographic identities for AI agents. As AI agents proliferate across browsers, cloud platforms, and enterprise environments, systems need a standardized answer to the question of which agent is present, what it is permitted to do, and whether it should be trusted. OpenA2A AIP is distinguished by five elements that it places at the center of the design: a multi-factor behavioral trust score that is computed from independently verifiable signals; a portable signed credential, the Agent Trust eXtension, carrying a hybrid Ed25519 and ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log for identity and credential issuance; agent identifiers expressed as W3C Decentralized Identifiers, provider-scoped as a did:web profile at the identity- provider layer and ecosystem-scoped under the registered did:opena2a method at the trust-fabric layer; and a structured capability vocabulary with reserved namespaces. On top of these, the protocol specifies challenge-response verification, behavioral governance policies, a lifecycle model, and an append-only audit log. The qualifier "OpenA2A AIP" is used throughout this document because the abbreviation "AIP" is shared by other Internet-Drafts. OpenA2A AIP is framed as complementary to agent communication protocols such as A2A and the Model Context Protocol, and to identity and credential standards such as OpenID Connect, WebAuthn, and the W3C Verifiable Credentials Data Model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Fane Expires 3 April 2027 [Page 1] Internet-Draft OpenA2A AIP September 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 6 3.1. Level 1: Local Identity . . . . . . . . . . . . . . . . . 6 3.2. Level 2: Managed Identity . . . . . . . . . . . . . . . . 6 3.3. Level 3: Federated Identity . . . . . . . . . . . . . . . 6 4. Agent Identity . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Cryptographic Identity . . . . . . . . . . . . . . . . . 7 4.2. Decentralized Identifier (DID) . . . . . . . . . . . . . 7 4.3. Identity File Format . . . . . . . . . . . . . . . . . . 10 4.4. Agent Types . . . . . . . . . . . . . . . . . . . . . . . 11 5. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Capability Format . . . . . . . . . . . . . . . . . . . . 11 5.2. Reserved Namespaces . . . . . . . . . . . . . . . . . . . 11 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . 12 5.4. Capability Violations . . . . . . . . . . . . . . . . . . 12 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Challenge-Response Protocol . . . . . . . . . . . . . . . 13 6.1.1. Challenge Body (Identity Provider to Relying Party) . . . . . . . . . . . . . . . . . . . . . . . 13 Fane Expires 3 April 2027 [Page 2] Internet-Draft OpenA2A AIP September 2026 6.1.2. Response Body (Agent to Relying Party) . . . . . . . 14 6.1.3. Canonical Signing Form . . . . . . . . . . . . . . . 14 6.1.4. Verification Rules . . . . . . . . . . . . . . . . . 15 6.1.5. Conformance Fixtures . . . . . . . . . . . . . . . . 15 6.2. Protocol-Specific Verification . . . . . . . . . . . . . 16 6.3. Verification Events . . . . . . . . . . . . . . . . . . . 16 6.4. Machine-to-Machine Authentication . . . . . . . . . . . . 16 7. Trust Scoring . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Multi-Factor Algorithm . . . . . . . . . . . . . . . . . 17 7.2. Trust Levels . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Trust Score History . . . . . . . . . . . . . . . . . . . 18 7.4. Verifiable Credential Expression . . . . . . . . . . . . 18 7.5. Agent Trust Protocol Integration . . . . . . . . . . . . 19 8. Portable Credential and Transparency Log . . . . . . . . . . 19 8.1. Portable Signed ATX Credential . . . . . . . . . . . . . 20 8.2. Transparency Log . . . . . . . . . . . . . . . . . . . . 20 9. Governance . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Policy Format . . . . . . . . . . . . . . . . . . . . . . 20 9.2. Policy Actions . . . . . . . . . . . . . . . . . . . . . 21 9.3. Relationship to Behavioral Governance . . . . . . . . . . 21 10. Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 21 10.3. Suspension and Revocation . . . . . . . . . . . . . . . 22 10.4. Drift Detection . . . . . . . . . . . . . . . . . . . . 22 11. Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Local Audit Log . . . . . . . . . . . . . . . . . . . . 22 11.2. Server Audit Log . . . . . . . . . . . . . . . . . . . . 22 12. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 13.1. Key Storage . . . . . . . . . . . . . . . . . . . . . . 23 13.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24 13.3. Capability Escalation . . . . . . . . . . . . . . . . . 24 13.4. Trust Score Manipulation . . . . . . . . . . . . . . . . 24 13.5. Unverified Type and Declared-Purpose Fields . . . . . . 24 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 15. Normative References . . . . . . . . . . . . . . . . . . . . 24 16. Informative References . . . . . . . . . . . . . . . . . . . 25 Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 28 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Fane Expires 3 April 2027 [Page 3] Internet-Draft OpenA2A AIP September 2026 1. Introduction AI agents increasingly act autonomously on behalf of users and organizations, connecting to services, invoking tools, and delegating tasks to one another. This raises a basic operational question for any party that an agent contacts: which agent is this, what is it permitted to do, and should it be trusted? The OpenA2A Agent Identity Protocol (OpenA2A AIP) provides a standardized answer. OpenA2A AIP leads with five elements that together characterize the protocol: 1. *Multi-factor behavioral trust score*: a composite score computed from independently verifiable behavioral and provenance signals, with discrete trust levels and a change history (Section 7). The inputs cannot be self-reported by the agent. 2. *Portable signed credential*: agent identity and trust can be carried in an Agent Trust eXtension (ATX) [ATX], a signed credential that carries a hybrid Ed25519 and ML-DSA-65 [FIPS204] signature for post-quantum readiness (Section 8). 3. *Transparency log*: identity registration and credential issuance events are recorded in an append-only, RFC 9162-style [RFC9162] Merkle transparency log maintained by the Registry (Section 8.2). 4. *Decentralized identity*: at the federated conformance level, agents are identified by W3C Decentralized Identifiers [DID-CORE]: provider-scoped identifiers issued and resolved by the identity provider as a did:web profile, with the ecosystem- scoped did:opena2a method naming trust-fabric participants (Section 4.2). 5. *Structured capability vocabulary*: capabilities are expressed in a namespace-and-action form over a set of reserved namespaces, rather than as opaque tool allowlists (Section 5). On top of these elements, OpenA2A AIP specifies challenge-response identity verification (Section 6), behavioral governance policies (Section 9), an identity lifecycle with key rotation, suspension, and revocation (Section 10), an append-only audit log (Section 11), and a discovery document (Section 12). OpenA2A AIP is designed to complement, rather than replace, existing protocols. Its identity fits into the A2A [A2A] agent card so agents can verify one another before task delegation; its capabilities map to Model Context Protocol [MCP] tool permissions and its challenge- response protocol lets a server verify a connecting client; its Fane Expires 3 April 2027 [Page 4] Internet-Draft OpenA2A AIP September 2026 machine-to-machine tokens relate to OpenID Connect [OIDC]; its key storage can use hardware authenticators via WebAuthn [WEBAUTHN]; and its trust scores can be expressed as W3C Verifiable Credentials [VC-DATA-MODEL] for cross-platform portability. Authorization concerns, that is, the scoped exercise of a capability and the confinement of credentials away from the agent, are addressed by the companion Agent Authorization Protocol [AAP]; OpenA2A AIP is concerned with identity, capability declaration, verification, and trust. The abbreviation "AIP" is shared by other Internet-Drafts. When OpenA2A AIP is referenced outside this document, the fully qualified name "OpenA2A AIP" is used; the relationship to those other drafts is described in Appendix A. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Agent An AI system that performs actions on behalf of a user or another agent. Identity Provider A server that creates and manages agent identities. Relying Party A system that verifies an agent's identity before granting access. Capability A permission declared in namespace-and-action form (for example, "file:read"). Trust Score A value from 0.0 to 1.0 computed from multiple behavioral and provenance signals. Governance Policy Constraints on agent behavior, expressing what an agent may and may not do. Audit Log An append-only record of agent actions and verification events. Agent Trust eXtension (ATX) A signed, portable credential carrying an agent's identity, capabilities, and trust level, as defined in [ATX]. Fane Expires 3 April 2027 [Page 5] Internet-Draft OpenA2A AIP September 2026 Registry / Root Authority A trust authority that issues ATX credentials, maintains a transparency log [RFC9162], and participates in the Agent Trust Protocol [ATP]. Decentralized Identifier (DID) A globally unique identifier conforming to W3C DID Core [DID-CORE]. OpenA2A AIP identities are provider-scoped did:web identifiers; the ecosystem-scoped did:opena2a method names trust-fabric participants (Section 4.2). 3. Conformance Levels OpenA2A AIP defines three conformance levels describing deployment topology, that is, what infrastructure operates the agent identity. 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. Agent Identity Fane Expires 3 April 2027 [Page 6] Internet-Draft OpenA2A AIP September 2026 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]. Two DID methods with distinct scopes participate in the OpenA2A stack; OpenA2A AIP identities use the first. OpenA2A AIP defines no DID method of its own. Provider-scoped: a did:web profile, the identity-provider layer. An OpenA2A AIP identity provider issues its agents identifiers under the did:web method [DID-WEB], with the provider's own host inside the identifier: did:web:[:]:agents: where the provider-host component is the DNS name of the issuing provider, the optional path component is zero or more colon-separated path segments under which the provider publishes DID Documents, and the id component is the provider-assigned identifier. The provider identifies itself as "did:web:". Resolution follows the did:web method: the DID Document is fetched over HTTPS from the host the identifier names, at "https:////agents//did.json" for an agent and "https:///.well-known/did.json" for the provider, so the identifier needs no method registration of its own and any resolver that speaks did:web resolves it. The provider's "didResolve" endpoint, advertised in the "/.well-known/aip" document (Section 12), serves the same document under the provider's API path. The reference implementation issues "did:web:aim.opena2a.org:agents:" and identifies itself as "did:web:aim.opena2a.org". A provider MUST reject resolution requests for identifiers it did not issue. Fane Expires 3 April 2027 [Page 7] Internet-Draft OpenA2A AIP September 2026 Deprecated alias. Revisions -00 through -02 of this document and the repository specification before 1.1 described a provider-scoped method under a name of OpenA2A AIP's own, and the reference implementation issued identifiers in that form (see the method name registration paragraph below). A provider that issued identifiers in the pre-1.1 form keeps resolving them for a migration window and lists the alias under "alsoKnownAs" in the agent's DID Document, so a verifier holding either form reaches the same document. Identifiers are opaque to verification (below), so credentials issued against an alias keep verifying. Ecosystem-scoped: did:opena2a, the trust-fabric method, informative in this document. The did:opena2a method [DID-METHOD-OPENA2A], with identifiers of the form "did:opena2a::", is shared by the Agent Trust Protocol [ATP] and the Agent Trust eXtension [ATX] and is anchored at an OpenA2A Registry, which operates its resolver. It names trust-fabric participants across providers: issuing authorities, publishers, and Registry-listed agents. Its resource- type prefixes are registered in that specification. An OpenA2A AIP identity provider does not serve did:opena2a. An agent acquires an ecosystem identifier when it is registered in a Registry, and a provider MAY record that binding in the agent's DID Document through "alsoKnownAs". Identifiers in OpenA2A AIP protocol messages, for example the "agentDid" field of the Section 6.1 transcript, are opaque strings bound to keys by the verifier's registration state or the resolved DID Document. Verification semantics do not depend on which method an identifier uses. The DID Document includes the agent's public keys, capability references, and service endpoints: Fane Expires 3 April 2027 [Page 8] Internet-Draft OpenA2A AIP September 2026 { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "id": "did:web:aim.opena2a.org:agents: 7f3a9c2e-1b2d-4c3e-9f10-a1b2c3d4e5f6", "controller": "did:web:aim.opena2a.org", "verificationMethod": [{ "id": "did:web:aim.opena2a.org:agents: 7f3a9c2e-1b2d-4c3e-9f10-a1b2c3d4e5f6#key-1", "type": "Ed25519VerificationKey2020", "controller": "did:web:aim.opena2a.org:agents: 7f3a9c2e-1b2d-4c3e-9f10-a1b2c3d4e5f6", "publicKeyMultibase": "z6Mkf5rGMoatrSj1f..." }], "capabilityInvocation": ["#key-1"], "service": [{ "id": "#identity-provider", "type": "AgentIdentityProvider", "serviceEndpoint": "https://aim.opena2a.org" }] } Identifier values longer than the line are folded across two lines in this and the later examples for formatting per [RFC8792]; each is a single JSON string on the wire. Method scoping note. Revisions -00 through -02 of this document said OpenA2A AIP itself uses the unified did:opena2a method. That never matched the reference implementation, which issues provider-scoped identifiers and rejects other methods at its resolver, and it conflated two trust domains: a self-hosted identity provider must not mint identifiers inside the ecosystem-shared namespace that a Registry anchors. The two-domain scoping stands: provider-scoped identifiers at the identity-provider layer, did:opena2a ecosystem- scoped at the trust-fabric layer. This revision changes only the form of the provider-scoped identifier, from a method name of OpenA2A AIP's own to the did:web profile above. Reference implementation status, source read 2026-09-08. The reference resolver serves the deprecated alias form only: it answers "did:aip:aim_" at its "didResolve" endpoint and rejects every other prefix. The did.json route of the did:web form is not implemented, and no code path resolves did:opena2a. This revision specifies the target; it does not change the resolver. Fane Expires 3 April 2027 [Page 9] Internet-Draft OpenA2A AIP September 2026 Method name registration. DID method names are registered in the W3C DID Extensions registry [DID-EXTENSIONS]. The name "opena2a" is registered there, and "web" is listed there as well. The name "aip" is also listed; that entry (methods/aip.json, added 2026-05-31) is not OpenA2A's. OpenA2A AIP defines no DID method; provider-scoped identifiers use "did:web"; pre-1.1 "did:aip:aim_" identifiers are deprecated aliases. Identifiers already issued are unaffected because verification treats them as opaque. 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 Fane Expires 3 April 2027 [Page 10] Internet-Draft OpenA2A AIP September 2026 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. Capabilities 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. Fane Expires 3 April 2027 [Page 11] Internet-Draft OpenA2A AIP September 2026 +===========+===========================+=============+ | Namespace | Description | Risk Level | +===========+===========================+=============+ | file | Filesystem operations | Medium-High | +-----------+---------------------------+-------------+ | db | Database operations | Medium-High | +-----------+---------------------------+-------------+ | api | External API calls | Medium | +-----------+---------------------------+-------------+ | network | Network operations | High | +-----------+---------------------------+-------------+ | system | System-level operations | Critical | +-----------+---------------------------+-------------+ | mcp | MCP protocol operations | Medium | +-----------+---------------------------+-------------+ | data | Data access and handling | High | +-----------+---------------------------+-------------+ | payment | Financial operations | Critical | +-----------+---------------------------+-------------+ | user | User data operations | High | +-----------+---------------------------+-------------+ | agent | Agent-to-agent operations | Medium | +-----------+---------------------------+-------------+ Table 1 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%. Fane Expires 3 April 2027 [Page 12] Internet-Draft OpenA2A AIP September 2026 6. Verification 6.1. Challenge-Response Protocol Agent identity verification uses Ed25519 [RFC8032] 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 applies the verification rules of Section 6.1.4. The wire bodies, the canonical signing form, and the replay rule in this section were first pinned by the aip-conformance suite (v0.2) and are normative here. A transcript that verifies against this section produces the same verdict as that suite's reference verifiers. 6.1.1. Challenge Body (Identity Provider to Relying Party) { "challenge": "ClvWi9D7pyXv3ttNMoKSQIct2T6MCf6Eme9f06GC6wY", "agentDid": "did:opena2a:agent:agent_conformance_test_001", "nonce": "nJKmKdgYM3lMNkzxAGiNdA", "issuedAt": "2026-05-27T23:58:00Z", "expiresAt": "2026-05-28T00:03:00Z", "issuerDid": "did:opena2a:authority:opena2a.org" } The example is the conformance suite's challenge-response-valid fixture. All six fields are REQUIRED. The "challenge" field carries 32 random bytes and "nonce" 16 random bytes, each freshly generated from a cryptographically secure source per challenge and encoded as unpadded base64 [RFC4648]. The "agentDid" field is the agent identifier the challenge was minted for and "issuerDid" the identity provider's DID. Both timestamps are RFC 3339 [RFC3339] UTC, with "expiresAt" equal to "issuedAt" plus five minutes. The identifiers in this transcript ("agentDid", "issuerDid", and the "keyId" of Section 6.1.2) are ecosystem-scoped did:opena2a strings because the suite's test subject is a Registry-listed agent. A provider-scoped did:web identifier (Section 4.2) is carried in the same fields in the same way. The bytes are the pinned fixture and are unchanged by the method scoping: verification treats the identifier as opaque and binds it to a key through the verifier's registration state or the resolved DID Document (Section 6.1.4, rule 2). Fane Expires 3 April 2027 [Page 13] Internet-Draft OpenA2A AIP September 2026 6.1.2. Response Body (Agent to Relying Party) { "agentDid": "did:opena2a:agent:agent_conformance_test_001", "challenge": "ClvWi9D7pyXv3ttNMoKSQIct2T6MCf6Eme9f06GC6wY", "nonce": "nJKmKdgYM3lMNkzxAGiNdA", "issuedAt": "2026-05-27T23:58:00Z", "expiresAt": "2026-05-28T00:03:00Z", "signature": "8bno3dn0bwJ4/CiC9D8fq6ScFBdjVZAw8gp1I+gL6bUM dxoaKcyMt1h8SYteAWD1YZZnVuf7mUsBlw2dvB1TBw", "publicKey": "PUAXw+hDiVqStwqnTRt+vJyYLM8uxJaMwM1V8Sr0Zgw", "keyId": "did:opena2a:agent:agent_conformance_test_001#key-1", "signedAt": "2026-05-27T23:58:30Z", "algorithm": "Ed25519" } The example is the same fixture, a transcript that verifies. The "signature" value is folded across two lines here for formatting per [RFC8792]; it is a single JSON string on the wire. The agent echoes the five challenge fields it signs over and attaches the signature plus key metadata. The "signature" field is 64 bytes and "publicKey" 32 bytes, both unpadded base64. The "keyId" field is the fragment- qualified "#key-N" reference and "signedAt" is RFC 3339 UTC. 6.1.3. Canonical Signing Form The signature covers a pipe-delimited UTF-8 string of exactly five fields, in this order: |||| The field values are joined with a single "|" character (U+007C) with no surrounding whitespace. Before joining, "issuedAt" and "expiresAt" MUST be normalized to RFC 3339 UTC, Z-suffixed at second precision, so that an equivalent offset form ("+00:00") produces the same signed bytes. The "challenge", "agentDid", and "nonce" values are used byte-exactly as they appear in the challenge body. Binding "agentDid" and the identity-provider-issued "nonce" into the signed bytes is what prevents cross-relying-party replay: a signature produced for one relying party's challenge cannot be presented to another, because the other relying party's identity provider would have issued different bytes. Unsigned response fields are unauthenticated. The "publicKey", "keyId", "signedAt", and "algorithm" fields are NOT covered by the signature. A verifier MUST resolve the agent's key from its own Fane Expires 3 April 2027 [Page 14] Internet-Draft OpenA2A AIP September 2026 registration record or resolved DID document for the claimed "agentDid", and MUST NOT trust the response's "publicKey" field as the verification key on its own. A response that verifies only under its own embedded key proves possession of some key, not of the agent's bound key. JCS-canonical JSON signing [RFC8785] over the full response is a candidate hardening for a future major revision; the five-field form is normative for AIP 1.x. 6.1.4. Verification Rules A relying party MUST reject the transcript unless all of the following hold. The checks run in this order, and the first failure determines the reject category: 1. Signature: the Ed25519 signature verifies over the Section 6.1.3 canonical bytes under the response's "publicKey" (reject category SIGNATURE_INVALID). This proves possession of the presented key; rule 2 proves it is the right key. 2. Bound key: the presented "publicKey" matches the key bound to "agentDid" in the verifier's registration state or resolved DID document; for a provider-scoped did:web identifier that is the document the issuing provider serves (Section 4.2) (reject category UNTRUSTED_KEY). A transcript MUST NOT be accepted on rule 1 alone. 3. Freshness: the verifier's clock is before "expiresAt". The window is five minutes from issuance (reject category CHALLENGE_EXPIRED). 4. Nonce single-use: the nonce has not been consumed by a prior verification. Verifiers MUST record consumed nonces at least until the corresponding challenge's "expiresAt" (reject category NONCE_REPLAY). 5. Trusted issuer: "issuerDid" is in the verifier's trusted-issuer set. 6.1.5. Conformance Fixtures Byte-stable transcript fixtures for this section, covering valid, wrong-key, stale-challenge, and nonce-replay cases, each pinned by SHA-256 and verified by parity-gated Go and Python reference verifiers, are published at https://github.com/opena2a-standards/aip- conformance. An implementation claiming conformance to this section MUST produce the pinned verdict on every fixture. Fane Expires 3 April 2027 [Page 15] Internet-Draft OpenA2A AIP September 2026 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: Fane Expires 3 April 2027 [Page 16] Internet-Draft OpenA2A AIP September 2026 { "sub": "user_123", "org": "org_456", "iss": "aim.example.com", "aud": "aim-api", "exp": 1711137600, "iat": 1711134000, "scope": "agent:read agent:write" } 7. Trust Scoring 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. +=====================+========+=========================+ | Factor | Weight | Input | +=====================+========+=========================+ | Verification status | 25% | Signature verification | | | | success rate | +---------------------+--------+-------------------------+ | Uptime and | 15% | Health check | | availability | | responsiveness | +---------------------+--------+-------------------------+ | Action success rate | 15% | Action completion rate | +---------------------+--------+-------------------------+ | Security alerts | 15% | Active security alerts, | | | | weighted by severity | +---------------------+--------+-------------------------+ | Compliance | 10% | Framework adherence | +---------------------+--------+-------------------------+ | Execution isolation | 10% | Sandbox or process | | | | isolation posture | +---------------------+--------+-------------------------+ | Age and history | 5% | Operational history | +---------------------+--------+-------------------------+ | Drift detection | 3% | Behavioral consistency | | | | versus baseline | +---------------------+--------+-------------------------+ | User feedback | 2% | Explicit trust ratings | | | | from humans | +---------------------+--------+-------------------------+ Table 2 Fane Expires 3 April 2027 [Page 17] Internet-Draft OpenA2A AIP September 2026 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 five discrete levels, numbered 0 through 4, for policy decisions. A score below 0.25 is Level 0 (Blocked), indicating an agent that is compromised or malicious. From 0.25 to 0.50 is Level 1 (Warning), indicating significant trust concerns. From 0.50 to 0.75 is Level 2 (Limited), indicating restricted access with monitoring required. From 0.75 to 0.90 is Level 3 (Standard), indicating normal operations. From 0.90 to 1.00 is Level 4 (Elevated), indicating eligibility for high-trust operations such as financial or PII access. The trustLevel field of a credential carries this integer. This level is a behavioral tier computed by the identity provider and is distinct from the Agent Trust Protocol provenance scale ([ATP], Section 4.1), which shares the integer range 0 through 4 but not the level names or their meaning. 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. The sample below is an identity- provider layer credential: the identity provider that computes the score (Section 13.4) is the issuer, and the subject is the agent's provider-scoped DID (Section 4.2). An ecosystem-scoped trust assertion about a Registry-listed agent is the Agent Trust Protocol trust proof (Section 7.5), issued under did:opena2a by the ecosystem authority, not this credential. Fane Expires 3 April 2027 [Page 18] Internet-Draft OpenA2A AIP September 2026 { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://opena2a.org/credentials/v1" ], "type": ["VerifiableCredential", "AgentTrustCredential"], "issuer": "did:web:aim.opena2a.org", "issuanceDate": "2026-03-22T14:00:00Z", "expirationDate": "2026-03-23T14:00:00Z", "credentialSubject": { "id": "did:web:aim.opena2a.org:agents: 7f3a9c2e-1b2d-4c3e-9f10-a1b2c3d4e5f6", "trustScore": 0.82, "trustLevel": 3, "capabilities": ["file:read", "api:call"], "verificationCount": 1847, "lastVerified": "2026-03-22T13:55:00Z" }, "proof": { "type": "Ed25519Signature2020", "created": "2026-03-22T14:00:00Z", "verificationMethod": "did:web:aim.opena2a.org#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. Portable Credential and Transparency Log Fane Expires 3 April 2027 [Page 19] Internet-Draft OpenA2A AIP September 2026 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 9162-style [RFC9162] 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. Governance 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" Fane Expires 3 April 2027 [Page 20] Internet-Draft OpenA2A AIP September 2026 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. Lifecycle 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. Fane Expires 3 April 2027 [Page 21] Internet-Draft OpenA2A AIP September 2026 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. Audit 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". Fane Expires 3 April 2027 [Page 22] Internet-Draft OpenA2A AIP September 2026 12. Discovery An OpenA2A AIP identity provider MUST serve a discovery document at the well-known URI "/.well-known/aip". The document advertises the provider DID, the protocol version, the conformance level, the set of endpoint paths, the provider's public key, and the supported agent types, capability namespaces, and protocols: { "providerDid": "did:web:aim.opena2a.org", "version": "1.0", "conformanceLevel": 2, "endpoints": { "agents": "/api/v1/agents", "challenge": "/api/v1/agents/{agentId}/challenge", "verify": "/api/v1/agents/{agentId}/verify", "capabilities": "/api/v1/capabilities", "trustScore": "/api/v1/agents/{agentId}/trust", "audit": "/api/v1/agents/{agentId}/audit", "didResolve": "/api/v1/did/{did}" }, "publicKey": { "algorithm": "Ed25519", "publicKeyMultibase": "z6Mkf5rGMoatrSj1f..." }, "supportedAgentTypes": ["claude", "gpt", "gemini", "langchain", "crewai", "mcp-server", "a2a-agent"], "supportedCapabilityNamespaces": ["file", "db", "api", "network", "system", "mcp", "data", "payment"], "supportedProtocols": ["mcp", "a2a"] } The "providerDid" value is the provider's did:web self-identifier (Section 4.2). The "didResolve" endpoint answers for the identifiers the provider issued, including deprecated aliases during their migration window; the same DID Document is also published at the did:web path derived from the identifier. 13. Security Considerations 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. Fane Expires 3 April 2027 [Page 23] Internet-Draft OpenA2A AIP September 2026 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. 14. IANA Considerations This document requests no IANA action for DID methods. DID method names are registered in the W3C DID Extensions registry [DID-EXTENSIONS], not with IANA. OpenA2A AIP defines no DID method; provider-scoped identifiers use "did:web"; pre-1.1 "did:aip:aim_" identifiers are deprecated aliases (Section 4.2). The ecosystem- scoped did:opena2a method, shared across OpenA2A AIP, the Agent Trust Protocol [ATP], and the Agent Trust eXtension [ATX], is registered there and specified in [DID-METHOD-OPENA2A], which also holds the registry of its resource-type prefixes. The did:web method is specified in [DID-WEB] and listed in the same registry. This document anticipates registration of the "/.well-known/aip" well-known URI for identity-provider discovery, and a registry of standard capability namespaces ("file", "db", "api", "network", "system", "mcp", "data", "payment", "user", and "agent"). The concrete registration templates will be provided in a future revision of this document. 15. Normative References Fane Expires 3 April 2027 [Page 24] Internet-Draft OpenA2A AIP September 2026 [DID-CORE] World Wide Web Consortium, "Decentralized Identifiers (DIDs) v1.0", July 2022, . [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, May 2015, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, December 2021, . [VC-DATA-MODEL] World Wide Web Consortium, "Verifiable Credentials Data Model v2.0", 2025, . 16. Informative References [A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification", 2026, . Fane Expires 3 April 2027 [Page 25] Internet-Draft OpenA2A AIP September 2026 [AAP] Fane, A., "OpenA2A Agent Authorization Protocol (AAP)", 2026, . [ATP] Fane, A., "Agent Trust Protocol (ATP)", 2026, . [ATX] Fane, A., "Agent Trust eXtension (ATX) Credential Format", 2026, . [DID-EXTENSIONS] W3C Decentralized Identifier Working Group, "DID Extensions: DID method registry", 2026, . [DID-METHOD-OPENA2A] Fane, A., "The did:opena2a DID Method Specification", 2026, . [DID-WEB] W3C Credentials Community Group, "did:web Method Specification", 2026, . [MCP] Model Context Protocol, "Model Context Protocol Specification", 2026, . [NVIDIA-AIP] Cao and Arango, "Agent Identity Protocol", March 2026, . [OIDC] OpenID Foundation, "OpenID Connect Core 1.0", November 2014, . [PRAKASH-AIP] "Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems", 2026, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . Fane Expires 3 April 2027 [Page 26] Internet-Draft OpenA2A AIP September 2026 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, June 2020, . [SINGLA-AIP] Singla, "Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents", April 2026, . [WEBAUTHN] World Wide Web Consortium, "Web Authentication: An API for accessing Public Key Credentials Level 3", 2025, . Appendix A. Related Work The abbreviation "AIP" is shared by several Internet-Drafts titled "Agent Identity Protocol". One [NVIDIA-AIP] specifies an agent- identity registry and a Layer 2 policy and enforcement proxy; a second [SINGLA-AIP] addresses decentralized identity and delegation, is at revision -03 (2026-06-10), and introduces a DID method of its own; OpenA2A AIP defines no DID method (Section 4.2) and the two documents are independent of each other; a third [PRAKASH-AIP] addresses verifiable delegation across the Model Context Protocol and A2A. The qualified name "OpenA2A AIP" is used throughout this document precisely because the bare acronym is shared. OpenA2A AIP shares a common spine with the first of these, a Layer 1 agent- identity registry and a Layer 2 policy and enforcement surface, and differs in what it builds above that spine. Fane Expires 3 April 2027 [Page 27] Internet-Draft OpenA2A AIP September 2026 OpenA2A AIP has earlier provenance: its identity registry has been implemented since 2026-02-11, predating the -00 revisions of the drafts cited above. OpenA2A AIP differentiates on elements that those drafts do not define: agent identifiers expressed as W3C Decentralized Identifiers [DID-CORE], provider-scoped as a did:web profile at the identity-provider layer and ecosystem-scoped under the registered did:opena2a method at the trust-fabric layer (Section 4.2), rather than as host-prefixed UUIDs; signing keys with an ML-DSA-65 [FIPS204] hybrid component carried in the portable ATX credential [ATX] rather than Ed25519 alone; a structured capability vocabulary with reserved namespaces rather than tool allowlists only (Section 5); a multi-factor behavioral trust score with discrete levels and a change history (Section 7); and an append-only, RFC 9162-style [RFC9162] Merkle transparency log of identity and credential issuance (Section 8.2). These documents are author- namespaced and are intended to coexist on the Internet-Drafts record; the comparison here is offered for disambiguation, not as a claim against any author or vendor. Authorization concerns that are out of scope for OpenA2A AIP, namely the scoped exercise of a capability and the confinement of credentials away from an agent's reasoning context, are addressed by the companion Agent Authorization Protocol [AAP]. Appendix B. Changes from -02 This revision is a method-scoping decision. It changes what an identity provider issues and makes no change to the challenge- response wire format. * The DID section now states that OpenA2A AIP defines no DID method; provider-scoped identifiers use "did:web"; pre-1.1 "did:aip:aim_" identifiers are deprecated aliases. An identity provider issues and resolves identifiers of the form "did:web:[:]:agents:" and identifies itself as "did:web:"; did:opena2a is the ecosystem-scoped method an identity provider does not serve. The -02 text said OpenA2A AIP uses the unified did:opena2a method. Verification treats identifiers as opaque. A reference implementation status paragraph records that the resolver answers the alias form only as of 2026-09-08. * The DID Document, Verifiable Credential, and discovery examples carry did:web identifiers. The challenge-response transcript is the pinned conformance fixture and is unchanged; a note records that its identifiers are ecosystem-scoped. Fane Expires 3 April 2027 [Page 28] Internet-Draft OpenA2A AIP September 2026 * The Trust Levels section adds one informative sentence: the level is a behavioral tier distinct from the Agent Trust Protocol provenance scale. The field and the level names are unchanged. * The IANA section requests no DID method action: method names are a W3C registry, did:opena2a is registered there, did:web is specified by its own community group, and the name "aip" is held by a registration that is not OpenA2A's. * Informative references to the did:opena2a method specification, the W3C DID Extensions registry and the did:web method specification are added. Appendix C. Acknowledgments This specification was authored in the open and benefits from review of its identity, capability, and trust-scoring model by the OpenA2A community. Author's Address Abdel Fane OpenA2A United States of America Email: info@opena2a.org Fane Expires 3 April 2027 [Page 29]