Supported Protocols

To ensure seamless integration into the rapidly evolving AI Agent and Web3 ecosystems, the zkMe Agent Trust Gateway is designed to be protocol-agnostic at its core, while providing native adapters for the most widely adopted standards. This interoperability ensures that developers can integrate zkMe’s trust layer without having to rewrite their agents or abandon their preferred tech stacks.

---

AI and Agent Communication Protocols

The Gateway supports standard protocols used by AI models and agent frameworks to request context, execute tools, and communicate with external environments.

Model Context Protocol (MCP)

MCP is an open standard, originally developed by Anthropic, that enables AI models to securely connect to external data sources and tools. The zkMe Gateway acts as an MCP Server, exposing its authorization and credential verification capabilities as callable tools.

How it works:

1. An agent (acting as an MCP Client) connects to the Gateway via standard transports (Server-Sent Events over HTTP, or stdio for local deployments).

2. The Gateway advertises its available tools via the MCP tools/list method. These tools include actions like verify_credential, request_authorization, check_policy, and get_context.

3. When the agent needs to perform an action that requires authorization, it calls the appropriate tool using a standard JSON-RPC message.

4. The Gateway processes the request inside the TEE enclave (credential verification, policy evaluation) and returns the result via the MCP response.

Example MCP tool call (conceptual):

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "request_authorization",
    "arguments": {
      "action": "swap",
      "target_contract": "0x1234...abcd",
      "chain_id": 1,
      "value_usd": 500,
      "credential_id": "did:zkme:0xABCD...1234#agent-delegation-001"
    }
  },
  "id": 1
}

Example response (authorized):

{
  "jsonrpc": "2.0",
  "result": {
    "status": "authorized",
    "token": "v4.public.eyJhY3Rpb24iOiJzd2FwIi...",
    "token_type": "PASETO_v4_public",
    "expires_at": "2026-03-17T22:00:00Z",
    "scope": ["swap"],
    "target": "0x1234...abcd"
  },
  "id": 1
}

Compatibility: Agents built on frameworks that support MCP can use the Gateway out-of-the-box. No custom protocol implementation is required.

Agent Payment Facilitation

As agents begin to transact autonomously, they need standardized ways to handle payments and prove payment capability. The Gateway supports the emerging x402 standard, which leverages the HTTP 402 “Payment Required” status code to enable machine-to-machine payment negotiation.

How it works:

1. The agent sends a request to a resource provider (e.g., a paid API or a DeFi protocol).

2. The resource provider responds with HTTP 402, including a payment challenge in the response headers specifying the required amount, accepted payment methods, and a payment address.

3. The agent routes the payment challenge to the Gateway via the APF adapter.

4. Inside the TEE, the Gateway:

   • Verifies the agent’s payment credential (e.g., a delegated spending allowance from the user stored in the zkVault).

   • Evaluates the payment against the user’s policy constraints (maximum transaction value, daily spending limit).

   • If approved, constructs and signs the payment transaction.

5. The Gateway returns a payment proof to the agent, which the agent presents to the resource provider to complete the request.

Key benefit: The agent never holds the user’s payment keys or wallet credentials. The Gateway handles the sensitive payment operation inside the TEE, ensuring that even a compromised agent cannot drain the user’s funds beyond the delegated allowance.

---

Web3 and Identity Standards

The Gateway bridges the gap between off-chain AI execution and on-chain verification, supporting the foundational standards of the decentralized identity ecosystem.

W3C Verifiable Credentials (VC) and Decentralized Identifiers (DID)

The foundational data models for all zkMe credentials. Every credential issued by the zkMe Credential System conforms to the W3C Verifiable Credentials Data Model, and every participant is identified by a Decentralized Identifier.

Compatibility:

• The Gateway natively parses, validates, and evaluates W3C VCs in JSON-LD format.

• It resolves DIDs (including did:zkme and other standard methods like did:ethr, did:web) to authenticate agents and verify issuer signatures.

• Credential schemas follow the W3C VC JSON Schema specification, ensuring interoperability with other SSI ecosystems.

For details on the zkMe DID specification, see DID Method. For details on the credential data model, see Core Concepts.

ERC-8004 (Agent Reputation) and Related EIPs

As the Ethereum ecosystem develops standards specifically for AI agents, zkMe integrates these to ensure on-chain compatibility and to enrich the policy evaluation process.

How it works:

• If an agent’s reputation or capability is represented as an ERC-8004 token or a similar on-chain standard, the Gateway can index this state from the blockchain.

• The reputation score is included as an additional input to the Policy Engine during evaluation. For example, a user policy might specify: “Only allow agents with a reputation score above 80 to execute trades above $500.”

• The Gateway also supports writing agent reputation updates back to the chain after successful or failed interactions, contributing to the ecosystem-wide agent trust graph.

Relationship to zkKYA: The ARC (Agent Reputation Credential) issued by zkMe can be represented on-chain as an ERC-8004 compatible token, creating a bridge between zkMe’s off-chain credential system and on-chain reputation standards.

OIDC4VP (OpenID Connect for Verifiable Presentations)

For integration with traditional Web2 services that are transitioning to decentralized identity, the Gateway supports OIDC4VP (OpenID Connect for Verifiable Presentations).

How it works:

1. A traditional OAuth/OIDC client (e.g., a Web2 API or SaaS platform) initiates an authorization request using the standard OIDC Authorization Code flow.

2. Instead of redirecting to a traditional identity provider, the request is routed to the Gateway.

3. The Gateway evaluates the request, verifies the agent’s credentials, and constructs a Verifiable Presentation (or a ZKP) that satisfies the OIDC client’s requirements.

4. The presentation is returned wrapped in the standard OIDC response format (ID Token + VP Token), allowing the Web2 service to process it using its existing OIDC library.

Key benefit: This adapter allows zkMe-verified agents to interact with Web2 services that have adopted OIDC4VP without requiring those services to implement custom zkMe integration. It serves as the bridge between the decentralized identity world and the traditional OAuth ecosystem.

Comparison with standard OIDC:

Aspect	Standard OIDC	OIDC4VP via Gateway
Identity Provider	Centralized (Google, Okta, etc.)	Decentralized (zkMe Credential System)
User Data	Shared with relying party	Zero-knowledge proof only
Agent Support	Not designed for agents	Native agent delegation support
Credential Format	JWT claims	W3C VC + ZKP

---

Cryptographic and Network Protocols

zkTLS

All communication between the Agent, the Gateway, and the Target Resource is secured via TLS 1.2 or 1.3.

zkTLS Integration: Where applicable, the Gateway leverages zkTLS to generate cryptographic proofs of data fetched from standard Web2 APIs. This ensures the provenance of the data injected into the agent’s context. For example, if an agent needs to prove a user’s bank balance to a DeFi protocol, the Gateway can use zkTLS to fetch the balance from the bank’s API and generate a ZKP attesting to the value, without revealing the raw API response.

PASETO (Platform-Agnostic Security Tokens)

When the Gateway needs to issue a short-lived authorization token to an agent for use with a Web2 API or a smart contract, it defaults to PASETO v4 instead of JWT.

Why PASETO over JWT?

Aspect	JWT	PASETO v4
Algorithm Selection	Developer chooses (risk of weak algorithms)	Enforced: Ed25519 (public) or XChaCha20-Poly1305 (local)
alg: none Attack	Vulnerable if not explicitly blocked	Not possible; no algorithm negotiation
Key Confusion	Possible (RS256 vs HS256 confusion)	Not possible; separate token types for public vs local
Header Injection	Possible via unvalidated headers	No custom headers allowed

PASETO tokens issued by the Gateway are:

• Scoped: The token specifies exactly which actions the agent is authorized to perform and on which targets.

• Time-limited: Every token has a strict expiration (typically minutes, not hours).

• Non-replayable: Each token includes a unique nonce and is bound to the specific session context.

• TEE-signed: The signing key never leaves the TEE enclave, ensuring that even a compromised gateway host cannot forge tokens.

---

Protocol Support Roadmap

The Gateway’s adapter architecture is designed to be extensible. The following protocols are under evaluation for future integration:

Protocol	Status	Use Case
A2A (Agent-to-Agent Protocol)	Under evaluation	Direct agent-to-agent communication and credential exchange
ACP (Agent Communication Protocol)	Under evaluation	Standardized agent messaging
DIDComm v2	Planned	Encrypted, authenticated messaging between DID-identified parties

---