# 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):**

```json
{
  "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):**

```json
{
  "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](/hub/how-built/id-infra/did-method.md). For details on the credential data model, see [Core Concepts](/hub/how-built/credential-sys/core-concepts.md).

### 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)](/hub/what/zkkya/arc.md) 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](/hub/how-built/id-infra/zktls.md) 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:

<table><thead><tr><th width="270.46875">Protocol</th><th width="161.1484375">Status</th><th>Use Case</th></tr></thead><tbody><tr><td><p><strong>A2A</strong></p><p>(Agent-to-Agent Protocol)</p></td><td>Under evaluation</td><td>Direct agent-to-agent communication and credential exchange</td></tr><tr><td><p><strong>ACP</strong></p><p>(Agent Communication Protocol)</p></td><td>Under evaluation</td><td>Standardized agent messaging</td></tr><tr><td><strong>DIDComm v2</strong></td><td>Planned</td><td>Encrypted, authenticated messaging between DID-identified parties</td></tr></tbody></table>

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.zk.me/hub/how-built/agent-trust-gateway/supported-protocols.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.