]> CAW

Hyderabad India vrknetha@gmail.com https://ravi.sh

Security Independent Submission AI agents identity cryptographic trust Ed25519 proof of possession agent-to-agent This document specifies the Clawdentity protocol, a cryptographic identity and trust layer for AI agent-to-agent communication. Clawdentity provides per-agent Ed25519 identity, registry-issued credentials (Agent Identity Tokens), proof-of-possession request signing, bilateral trust establishment via pairing ceremonies, authenticated relay transport over WebSocket, and certificate revocation. The protocol enables AI agents to prove their identity, verify peers, and exchange messages without exposing private keys, shared tokens, or backend infrastructure.

Introduction

Problem Statement Current AI agent frameworks rely on shared bearer tokens for inter-agent communication. A single token leak compromises all agents in the system. There is no mechanism to distinguish which agent sent a request, revoke a single agent without rotating the shared token, enforce per-agent access control, or keep backend services private. These limitations become critical as multi-agent systems scale.

Design Goals Clawdentity addresses these problems with six design goals:

1. Individual identity: Each agent has a unique cryptographic keypair and DID.
2. Proof of possession: Every request proves the sender holds the private key via Ed25519 signatures.
3. Selective revocation: One agent can be revoked without affecting others.
4. Zero-trust relay: Agents communicate through authenticated proxies; backend services remain unexposed.
5. Human-anchored trust: Trust originates from human approval, not agent self-certification.
6. Framework agnostic: Works with any AI agent framework.

Architecture Overview The protocol defines four component roles:

Registry

Central identity authority. Issues Agent Identity Tokens (AITs), manages signing keys, publishes the Certificate Revocation List (CRL).

Proxy

Per-owner edge service. Verifies identity, enforces trust policy, rate-limits requests, and relays messages between agents.

Connector

Local bridge process between the proxy and the agent framework. Maintains a persistent WebSocket connection to the proxy. Never exposed publicly.

Agent

The AI agent itself. Has no direct knowledge of the protocol; the connector handles all cryptographic operations.

Component Architecture | Proxy B | | (edge) | | | (edge) | +-------------+ | +--------------+ | +------------+------------+ | .well-known/claw-keys | | /v1/crl | | /v1/agents | +-------------------------+ ]]>

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 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

AIT

Agent Identity Token. A signed JWT credential (Section ) binding an agent DID to a public key.

CRL

Certificate Revocation List. A signed JWT (Section ) containing a list of revoked AITs.

DID

Decentralized Identifier as defined in , using the "cdi" method.

PoP

Proof of Possession. An Ed25519 signature proving the sender controls the private key corresponding to a public key.

Pairing

Mutual trust establishment between two agents via a ticket-based ceremony.

Trust Store

Per-proxy persistent storage of known agents and approved trust pairs.

ULID

Universally Unique Lexicographically Sortable Identifier .

Identity Model

DID Format Clawdentity uses a custom DID method with the scheme "did:cdi" (Clawdentity Identity). The method-specific identifier consists of a registry host and a ULID, separated by a colon: The registry-host identifies which registry issued the DID. The entity type (agent or human) is resolved by the registry, not encoded in the DID.

Entity	Example
Agent	did:cdi:registry.clawdentity.com:01HG8ZBU11X7X8DN8O4X6GEYU5
Human	did:cdi:registry.clawdentity.com:01HF7YAT00W6W7CM7N3W5FDXT4
Self-hosted	did:cdi:id.acme.corp:01HK9ABC22Y8Y9EO9P5Y7HFZV6

Implementations MUST reject DIDs where the registry-host is empty or where the ULID component does not conform to the ULID specification .

Cryptographic Primitives The protocol uses Ed25519 as the sole signing algorithm. Implementations MUST NOT support other signature algorithms.

Primitive	Algorithm	Reference	Usage
Signing	Ed25519		Identity, request signing
Body hash	SHA-256		Request body integrity
Token format	JWS Compact		AIT and CRL tokens
Key encoding	Base64url (no pad)	Section 5	Keys, signatures, hashes
Key representation	JWK (OKP/Ed25519)		Public keys in AITs

Key Generation Each agent locally generates an Ed25519 keypair consisting of a 32-byte public key and a 64-byte secret key. The secret key MUST be stored exclusively on the agent's local machine and MUST NOT be transmitted over any network. Only the public key is registered with the registry, encoded as base64url within the AIT's confirmation claim (Section ).

Ownership Model Every agent DID is bound to exactly one human DID (the "ownerDid"). This binding is recorded in the AIT claims and enforced by the registry during registration and refresh operations. A human MAY own multiple agents. An agent MUST have exactly one owner.

Agent Identity Token (AIT)

Overview The Agent Identity Token (AIT) is a JSON Web Token that serves as an agent's credential. It is issued by the registry, signed with a registry Ed25519 key, and binds the agent's DID to the agent's public key via a confirmation claim ("cnf"), following the pattern established by DPoP .

JOSE Header The AIT's JOSE protected header MUST contain:

alg

REQUIRED. MUST be "EdDSA" per .

typ

REQUIRED. MUST be "AIT".

kid

REQUIRED. The key identifier of the registry signing key used to sign this AIT. This allows the verifier to locate the correct registry public key.

AIT JOSE Header Example

Claims The AIT payload MUST contain the following claims. No additional claims are permitted (strict validation).

Claim	Type	Required	Description
iss	string	REQUIRED	Registry issuer URL (e.g., "https://registry.clawdentity.com")
sub	string	REQUIRED	Agent DID. MUST be "did:cdi:<registry-host>:<ulid>"
ownerDid	string	REQUIRED	Owner DID. MUST be "did:cdi:<registry-host>:<ulid>"
name	string	REQUIRED	Agent name. 1-64 characters matching [A-Za-z0-9._ -]
framework	string	REQUIRED	Agent framework identifier. 1-32 characters, no control characters.
description	string	OPTIONAL	Human-readable description. Maximum 280 characters.
cnf	object	REQUIRED	Confirmation claim. See Section .
iat	number	REQUIRED	Issued-at time (NumericDate per ).
nbf	number	REQUIRED	Not-before time (NumericDate).
exp	number	REQUIRED	Expiration time (NumericDate). MUST be greater than both nbf and iat.
jti	string	REQUIRED	Unique token identifier. MUST be a valid ULID.

Confirmation Claim The "cnf" (confirmation) claim binds the AIT to the agent's Ed25519 public key, following the confirmation method pattern described in . It contains a single "jwk" member: " } } ]]> The "kty" MUST be "OKP". The "crv" MUST be "Ed25519". The "x" parameter MUST decode (base64url) to exactly 32 bytes. The JWK MUST NOT contain a "d" (private key) parameter.

Validation Rules An AIT MUST be rejected if any of the following conditions are true:

1. "alg" is not "EdDSA".
2. "typ" is not "AIT".
3. "kid" does not match any active registry signing key.
4. JWS signature verification fails against the registry key identified by "kid".
5. "sub" is not a valid "did:cdi" DID.
6. "ownerDid" is not a valid "did:cdi" DID.
7. "cnf.jwk.x" does not decode to exactly 32 bytes.
8. "exp" is less than or equal to "nbf" or "iat".
9. "jti" is not a valid ULID.
10. Current time is before "nbf" or after "exp" (accounting for clock skew).
11. "jti" appears in the current CRL (Section ).

HTTP Request Signing

Purpose Every authenticated request includes a Proof of Possession (PoP) signature that proves the sender controls the private key corresponding to the public key in their AIT's "cnf" claim. This mechanism is inspired by DPoP but uses a canonical request signing approach optimized for agent-to-agent communication.

Canonical Request Format The canonical request string is constructed by joining the following fields with newline (0x0A) separators, in the order shown:

Canonical Request Example

Signature Computation The PoP signature is computed by signing the UTF-8 encoding of the canonical request string with the agent's Ed25519 private key: The resulting "proof" is a base64url-encoded 64-byte Ed25519 signature.

Request Headers An authenticated request MUST include the following headers:

Header	Status	Description
Authorization	REQUIRED	"Claw" SP <AIT-JWT>. See Section .
X-Claw-Timestamp	REQUIRED	Unix epoch seconds (integer string).
X-Claw-Nonce	REQUIRED	Unique per-request value. ULID RECOMMENDED.
X-Claw-Body-SHA256	REQUIRED	SHA-256 hash of the request body, base64url-encoded.
X-Claw-Proof	REQUIRED	Ed25519 PoP signature (base64url, 64 bytes).
X-Claw-Agent-Access	CONDITIONAL	Session access token. Required for relay and hook routes.

Verification Procedure The verifier (proxy) MUST perform the following steps in order:

1. Extract the AIT from the "Authorization: Claw <token>" header.
2. Verify the AIT's JWS signature against the registry's signing keys (Section ).
3. Check that the AIT's "jti" is not on the CRL (Section ).
4. Extract the agent's public key from the AIT's "cnf.jwk.x" claim.
5. Verify X-Claw-Timestamp is within the allowed skew window (default: 300 seconds).
6. Recompute SHA-256 of the request body; compare with X-Claw-Body-SHA256.
7. Reconstruct the canonical request (Section ).
8. Verify X-Claw-Proof against the canonical request using the agent's public key.
9. Check X-Claw-Nonce has not been seen before for this agent DID within the timestamp window.

If any step fails, the request MUST be rejected with HTTP 401.

The "Claw" Authentication Scheme This specification introduces the "Claw" HTTP authentication scheme for the Authorization header, following the framework defined in Section 11. The scheme name "Claw" is case-sensitive. The token MUST be a valid JWS Compact Serialization representing an AIT as defined in Section .

Agent Registration

Registration Flow Agent registration uses a challenge-response protocol to prove that the registrant possesses the Ed25519 private key corresponding to the public key being registered.

Agent Registration Sequence | | | | 200 { challengeId, nonce } | |<-------------------------------------| | | | [Agent signs registration proof] | | | | POST /v1/agents | | { proof, publicKey, name, ... } | |------------------------------------->| | | | 201 { agentDid, ait } | |<-------------------------------------| ]]>

Registration Proof The registration proof is computed by signing a canonical message that binds the challenge to the agent's identity parameters: nonce: ownerDid: publicKey: name: framework: ttlDays: ]]> Optional fields (framework, ttlDays) use empty strings when absent. The agent signs this message with Ed25519 and submits the base64url-encoded signature as the "proof" in the registration request.

AIT Refresh AITs have bounded lifetimes. Before expiration, the connector MUST request a fresh AIT: X-Claw-Agent-Access: ]]> The registry validates the current AIT and access token, verifies the agent is not revoked, and returns a new AIT with an updated expiration time.

Trust Establishment (Pairing)

Overview Before two agents can exchange messages, they MUST establish mutual trust through a pairing ceremony. Trust is anchored by human approval: agents cannot self-approve trust relationships. The pairing process uses short-lived tickets exchanged out-of-band (e.g., via QR code or messaging).

Pairing Flow

Trust Establishment Sequence | | | | | | { ticket, | | | expiresAt } | | |<--------------------| | | | | | (out-of-band ticket exchange) | | (QR code, message, copy-paste) | |----------------------------------------->| | | | | | POST /pair/confirm | | | { ticket, | | | responderProfile}| | |<-------------------| | | | | | 201 { paired:true }| | |------------------->| | | | | callback (optional) | | |<--------------------| | ]]>

Pairing Ticket The pairing ticket is a signed JWT with a short TTL, created by the proxy during the /pair/start request. The ticket encodes the issuer proxy URL, a signing key identifier, and an expiration timestamp. Ticket parameters:

Parameter	Default	Maximum
TTL (ttlSeconds)	300 seconds	900 seconds

Peer Profile Each side of a pairing provides a profile containing identity information for display and routing:

agentName

REQUIRED. Agent display name. Maximum 64 characters. No control characters.

humanName

REQUIRED. Owner display name. Maximum 64 characters. No control characters.

proxyOrigin

OPTIONAL. The proxy's URL origin, used for cross-proxy message routing.

Ownership Verification When an agent initiates pairing, the proxy MUST verify that the authenticated caller (identified by "ownerDid" in the AIT) actually owns the claimed initiator agent DID. This is done by querying the registry's internal agent-ownership endpoint. If ownership cannot be verified, the pairing MUST be rejected with HTTP 403.

Trust Store Each proxy maintains a Trust Store that records:

• Known agents: Agents that have been authenticated and accepted.
• Approved pairs: Bidirectional trust relationships between agents.
• Pairing tickets: Pending and completed pairing ceremonies with expiration tracking.

A message from Agent A to Agent B is permitted only if the ordered pair (A, B) exists in the proxy's trust store. The trust store SHOULD use a durable, transactional storage backend.

Relay Transport

Overview Messages between agents are relayed through their respective proxies. The connector maintains a persistent WebSocket connection to its proxy. The proxy authenticates the WebSocket upgrade request using the full AIT + PoP verification procedure (Section ).

WebSocket Connection The connector initiates a WebSocket connection to: X-Claw-Agent-Access: X-Claw-Timestamp: X-Claw-Nonce: X-Claw-Body-SHA256: X-Claw-Proof: ]]>

Frame Protocol All WebSocket messages are JSON objects conforming to the Clawdentity Frame Protocol version 1. Every frame contains a common base structure: ", "id": "", "ts": "" } ]]>

v

REQUIRED. Integer. Frame protocol version. MUST be 1.

type

REQUIRED. String. One of: "heartbeat", "heartbeat_ack", "deliver", "deliver_ack", "enqueue", "enqueue_ack".

id

REQUIRED. String. Unique frame identifier (ULID).

ts

REQUIRED. String. ISO 8601 timestamp with timezone.

Heartbeat Frames Either side MAY send heartbeat frames to verify liveness. The default heartbeat interval is 30 seconds. If a heartbeat acknowledgement is not received within 60 seconds, the sender SHOULD close the connection and reconnect. Heartbeat: ", "ts": "" } ]]> Heartbeat acknowledgement: ", "ts": "", "ackId": "" } ]]>

Deliver Frames The proxy sends a "deliver" frame to the connector when an inbound message arrives for the local agent: ", "ts": "", "fromAgentDid": "did:cdi:registry.clawdentity.com:...", "toAgentDid": "did:cdi:registry.clawdentity.com:...", "payload": { ... }, "contentType": "application/json", "conversationId": "conv-123", "replyTo": "https://proxy-a.example.com/v1/relay/delivery-receipts" } ]]> The connector MUST respond with a "deliver_ack" frame indicating whether the local agent framework accepted the delivery: ", "ts": "", "ackId": "", "accepted": true } ]]> If rejected, the "accepted" field is false and an optional "reason" string MAY be included.

Enqueue Frames The connector sends an "enqueue" frame to the proxy for outbound messages: ", "ts": "", "toAgentDid": "did:cdi:registry.clawdentity.com:...", "payload": { ... }, "conversationId": "conv-123" } ]]> The proxy responds with "enqueue_ack" after accepting or rejecting the message for relay.

Local Agent Delivery Upon receiving a "deliver" frame, the connector forwards the payload to the local agent framework via HTTP POST: x-clawdentity-to-agent-did: x-clawdentity-verified: true x-openclaw-token: x-request-id: ]]> The connector implements retry with exponential backoff for transient failures (5xx, 429, connection errors):

Parameter	Default Value
Max attempts	4
Initial delay	300 ms
Max delay	2,000 ms
Backoff factor	2
Total budget	14,000 ms

Reconnection On WebSocket disconnection, the connector MUST attempt to reconnect using exponential backoff with jitter:

Parameter	Default Value
Minimum delay	1,000 ms
Maximum delay	30,000 ms
Backoff factor	2
Jitter ratio	0.2 (±20%)

On successful reconnection, the connector resets the backoff counter and flushes any queued outbound frames.

Outbound Queue Persistence When the WebSocket connection is unavailable, the connector MUST queue outbound "enqueue" frames locally and flush them in FIFO order upon reconnection. The queue SHOULD support optional persistence (to disk or database) to survive connector restarts.

Certificate Revocation

CRL Format The Certificate Revocation List (CRL) is a signed JWT containing a list of revoked AITs. Its JOSE header uses:

alg

MUST be "EdDSA".

typ

MUST be "CRL".

kid

Registry signing key identifier.

CRL claims:

Claim	Type	Required	Description
iss	string	REQUIRED	Registry issuer URL.
jti	string	REQUIRED	CRL identifier (ULID).
iat	number	REQUIRED	Issued-at timestamp.
exp	number	REQUIRED	Expiration. MUST be greater than iat.
revocations	array	REQUIRED	At least one revocation entry.

Each revocation entry contains:

Field	Type	Required	Description
jti	string	REQUIRED	Revoked AIT's jti (ULID).
agentDid	string	REQUIRED	Revoked agent's DID.
reason	string	OPTIONAL	Human-readable reason. Max 280 chars.
revokedAt	number	REQUIRED	Revocation timestamp (Unix seconds).

CRL Distribution The registry publishes the current CRL at the well-known endpoint: Response: " } ]]>

CRL Caching Proxies MUST cache the CRL locally and refresh it periodically. The following parameters control caching behavior:

Parameter	Default	Description
Refresh interval	5 minutes	How often to fetch a fresh CRL.
Max age	15 minutes	Maximum staleness before the cache is considered expired.
Stale behavior	fail-open	"fail-open" allows stale CRL use; "fail-closed" rejects all requests.

When "fail-open": if the CRL cannot be refreshed and the cached CRL is within max age, the stale CRL is used for revocation checks. When "fail-closed": if the CRL exceeds max age and cannot be refreshed, the proxy MUST reject all authenticated requests with HTTP 503.

Revocation Scope Two levels of revocation are defined:

Global revocation (revoke agent)

The agent's AIT jti is added to the CRL by the registry. The agent can no longer authenticate at any proxy. Only the agent's owner can initiate global revocation.

Local revocation (remove pair)

A trust relationship is removed from a proxy's trust store. The agent still exists and can communicate with other paired agents, but can no longer reach the unpaired peer via that proxy. Either side of the pair can initiate local revocation.

Registry Key Discovery The registry publishes its active signing keys at a well-known endpoint, following the pattern established by OpenID Connect Discovery : Response: ", "status": "active", "createdAt": "2026-01-01T00:00:00Z" } ] } ]]> The registry MAY have multiple active signing keys to support key rotation. The AIT and CRL "kid" headers identify which key was used to sign a given token. Proxies SHOULD cache these keys (default TTL: 1 hour) and refresh them when an unknown "kid" is encountered.

Endpoint Reference

Registry Endpoints

Method	Path	Auth	Description
GET	/.well-known/claw-keys.json	None	Registry signing keys
GET	/v1/metadata	None	Registry metadata
GET	/v1/crl	None	Current CRL
POST	/v1/agents/challenge	API Key	Request registration challenge
POST	/v1/agents/auth/refresh	AIT + Access	Refresh AIT
POST	/v1/agents/auth/validate	Internal	Validate agent access token
POST	/v1/invites	API Key	Create invite code
POST	/v1/invites/redeem	None	Redeem invite code

Proxy Endpoints

Method	Path	Auth	Description
GET	/health	None	Health check
POST	/hooks/agent	AIT + PoP + Access	Inbound message delivery
GET	/v1/relay/connect	AIT + PoP + Access	WebSocket relay
POST	/v1/relay/delivery-receipts	AIT + PoP + Access	Delivery receipt callback
POST	/pair/start	AIT + PoP	Initiate pairing
POST	/pair/confirm	AIT + PoP	Confirm pairing
POST	/pair/status	AIT + PoP	Check pairing status

Security Considerations

Private Key Protection Agent Ed25519 private keys MUST be stored exclusively on the agent's local machine. The protocol is designed so that only the public key leaves the agent — embedded in the AIT's "cnf" claim and registered with the registry. Implementations SHOULD use operating system key storage facilities where available.

Replay Protection Three mechanisms provide replay protection:

1. Timestamp skew: Requests with X-Claw-Timestamp outside a configurable window (default: 300 seconds) are rejected.
2. Nonce uniqueness: Each (agentDid, nonce) pair is tracked per proxy. Duplicate nonces within the timestamp window are rejected.
3. AIT expiration: AITs have bounded lifetimes; expired AITs are rejected regardless of signature validity.

Transport Security TLS 1.2 or later ( for TLS 1.3) is REQUIRED for all proxy-to-proxy, proxy-to-registry, and connector-to-proxy communication over public networks. The PoP signature (Section ) provides an additional layer: even if TLS were compromised, a captured AIT cannot produce valid request signatures without the private key.

Connector Isolation The connector MUST only communicate with its own proxy (via WebSocket) and the local agent framework (via localhost HTTP). It MUST NOT directly access the registry, other proxies, or any cloud infrastructure services (message queues, object storage, databases). This constraint minimizes the connector's attack surface and ensures it remains a simple, auditable bridge.

Trust Store Integrity The trust store is the sole authorization source for message relay. Implementations SHOULD use a transactional storage backend (e.g., SQLite within a Cloudflare Durable Object) to prevent corruption from concurrent access or partial writes.

CRL Freshness Window There is an inherent propagation delay between AIT revocation and CRL distribution. With default settings, this window is up to 5 minutes. Deployments requiring tighter revocation windows SHOULD:

• Reduce the CRL refresh interval.
• Use push-based CRL invalidation (e.g., message queues).
• Combine CRL checks with real-time agent-auth validation for sensitive operations.

Human-Anchored Trust The protocol explicitly prevents agent self-certification. An agent cannot approve its own work or establish trust without human involvement. The pairing ceremony requires out-of-band ticket exchange, and global revocation requires the agent owner's credentials. This design prevents autonomous trust escalation.

Error Codes The following error codes are returned in JSON error responses with the corresponding HTTP status codes:

Authentication Errors (401)

Code	Description
PROXY_AUTH_MISSING_TOKEN	No Authorization header provided.
PROXY_AUTH_INVALID_SCHEME	Authorization header is not "Claw <token>" format.
PROXY_AUTH_INVALID_AIT	AIT JWT verification failed.
PROXY_AUTH_INVALID_PROOF	PoP signature does not match.
PROXY_AUTH_INVALID_TIMESTAMP	X-Claw-Timestamp missing or not a valid integer.
PROXY_AUTH_TIMESTAMP_SKEW	Timestamp outside the allowed skew window.
PROXY_AUTH_REPLAY	Nonce has been seen before (replay detected).
PROXY_AUTH_REVOKED	AIT jti is on the CRL.
PROXY_AGENT_ACCESS_REQUIRED	X-Claw-Agent-Access header missing.
PROXY_AGENT_ACCESS_INVALID	Agent access token is invalid or expired.

Authorization Errors (403)

Code	Description
PROXY_AUTH_FORBIDDEN	Agent not in trust store or pair not approved.
PROXY_PAIR_OWNERSHIP_FORBIDDEN	Caller does not own the initiator agent DID.

Service Unavailable Errors (503)

Code	Description
PROXY_AUTH_DEPENDENCY_UNAVAILABLE	Registry, CRL, or trust store is unreachable.
PROXY_PAIR_STATE_UNAVAILABLE	Trust store is unreachable for pairing operations.
CRL_CACHE_STALE	CRL exceeds max age and fail-closed is configured.

IANA Considerations

DID Method Registration This specification introduces the "cdi" DID method. A registration request for the W3C DID Method Registry would include:

Method Name

cdi

Method Specific Identifier

<registry-host>:<ulid>

DID Document

Resolved via the registry identified by the registry-host component.

HTTP Authentication Scheme Registration This specification registers the "Claw" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined in Section 16.3:

Authentication Scheme Name

Claw

Reference

Section of this document

JWT "typ" Header Parameter Values This specification registers two JWT "typ" header parameter values in the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)" registry:

"typ" Value	Description	Reference
AIT	Agent Identity Token	Section
CRL	Certificate Revocation List	Section

References Normative References Informative References W3C Recommendation

Example: Complete Message Flow The following describes a complete message relay from Agent A to Agent B:

1. Agent A's connector creates an "enqueue" frame targeting Agent B's DID.
2. If connected, the frame is sent over WebSocket to Proxy A; otherwise it is queued locally.
3. Proxy A receives the enqueue, looks up Agent B's proxy URL from the trust store, and signs an HTTP request with Agent A's AIT and PoP.
4. Proxy A sends POST /hooks/agent to Proxy B with the signed request.
5. Proxy B verifies the Authorization header (AIT + PoP), checks the CRL, and confirms the (A, B) pair exists in its trust store.
6. Proxy B creates a "deliver" frame and sends it over WebSocket to Connector B.
7. Connector B receives the deliver frame and POSTs the payload to the local agent framework on localhost.
8. Connector B sends a "deliver_ack" (accepted: true) back to Proxy B.
9. Agent B processes the message.

Comparison with Existing Standards

Feature	OAuth 2.0 / DPoP	Clawdentity
Identity model	Client credentials / tokens	Per-agent DID + Ed25519 keypair
Token issuer	Authorization server	Registry (centralized trust anchor)
PoP mechanism	DPoP JWT (RFC 9449)	Canonical request signing
Trust model	Scope-based authorization	Explicit bilateral pairing
Revocation	Token introspection	Signed CRL with local caching
Transport	Direct HTTP	WebSocket relay with store-and-forward
Target	Human-to-service auth	Agent-to-agent communication

Acknowledgements The Clawdentity protocol was designed as part of the OpenClaw ecosystem. The author thanks the OpenClaw community for feedback on the identity model, and the designers of DPoP (RFC 9449) and W3C DIDs whose work informed key design decisions.