This document compares Bot Protocol with existing identity, delegation, and provenance standards, explaining what each covers and what gap Bot Protocol addresses.
| Standard | What it covers | What Bot Protocol adds |
|---|---|---|
| OAuth 2.1 / OIDC | Client authentication, single-hop delegation, token exchange | Multi-hop chains, agent-to-agent semantics, monotonic scope reduction |
| OAuth CIBA | Asynchronous user confirmation through separate channel | Cryptographic biometric binding, delegation chain, agent identity |
| SPIFFE / SVID | Workload identity inside infrastructure (mTLS, X.509) | Cross-organizational delegation, agent-to-human verifiability |
| WIMSE | Workload identity in microservice environments | Same gap as SPIFFE — cross-org and human-to-agent layer |
| W3C DID | Decentralized identifier resolution | Delegation semantics, runtime constraints |
| W3C VC | Verifiable credentials, selective disclosure | Action records, revocation, multi-hop authority |
| C2PA | Provenance metadata for content | Identity of the agent that produced the content |
| Web Bot Auth (Cloudflare) | HTTP request signing for legitimate bots | Multi-hop delegation, action records |
| IETF AI agent auth (drafts) | Agent-to-service authentication | Agent-to-agent across organizations, biometric binding |
| GDPR / 152-FZ compliance frameworks | Legal requirements for data processing | Cryptographic audit trail satisfying these requirements |
OAuth 2.1 defines client authentication and authorization grants. OIDC adds an identity layer on top.
What it does well:
- Established, widely deployed
- Mature library ecosystem
- RFC 9449 (DPoP) provides token binding
Where it does not extend:
- OAuth defines a single-hop relationship: user authorizes client. There is no native concept of multi-hop delegation where client A delegates to client B.
- Token Exchange (RFC 8693) is the closest, but it lacks semantics of monotonic scope reduction and multi-hop chain validation.
- No notion of action receipts or audit trails.
Bot Protocol uses OAuth as a building block: Delegation Tokens are JWTs (compatible with OAuth tooling), DPoP binding is reused, but the multi-hop semantics and Action Receipts are added on top.
SPIFFE (Secure Production Identity Framework for Everyone) defines workload identity for microservices. SVID (SPIFFE Verifiable Identity Document) is the credential, typically an X.509 certificate or JWT.
WIMSE (Workload Identity in Multi-System Environments) is the IETF working group standardizing similar concepts.
What they do well:
- Strong identity for workloads inside an infrastructure
- mTLS-friendly, supports zero-trust architectures
- Automated rotation through SPIRE
Where they do not extend:
- Scoped to a single trust domain (one organization, typically). Cross-organizational verification is out of scope.
- No human-to-agent delegation layer.
- No action records.
Bot Protocol complements SPIFFE: SPIFFE handles workload identity inside an organization; Bot Protocol handles delegation and authority across organizations.
Decentralized Identifiers (DID) and Verifiable Credentials (VC) are W3C standards for self-sovereign identity.
What they do well:
- DID provides a flexible identifier scheme, independent of any central registry
- VC supports selective disclosure, zero-knowledge proofs, and rich credential semantics
- Strong cryptographic foundations
Where they do not extend:
- VC is general-purpose. It can express "Alice is over 18" or "Bob has a driver's license" but does not define semantics for "Bob authorizes agent X to do Y under conditions Z".
- No notion of monotonic scope reduction across delegation chains.
- No standard revocation mechanism for time-sensitive authority (revocation in VC is via revocation lists, suited for credentials but not for runtime authority).
Bot Protocol uses DID format for AIDs (did:bp:domain/path) and is designed to interoperate with VC tooling. Bot Protocol's Delegation Tokens and Action Receipts share design DNA with VCs but are specialized for autonomous agent scenarios.
C2PA provides metadata standards for content provenance: who created an image, was it AI-generated, was it edited.
What it does well:
- Industry consensus across Adobe, Microsoft, Sony, BBC, and others
- Cryptographic signatures bound to content
- Widely supported in creative tools
Where it does not extend:
- C2PA is content-centric. The signature attests "this image was created by software X with these edits."
- It does not address "who is the agent acting now, on whose behalf, with what authority."
Bot Protocol and C2PA are complementary. A future revision may include C2PA hooks: when a Bot Protocol agent generates content, it embeds C2PA provenance signed with its AID.
Cloudflare introduced HTTP message signatures for legitimate bots, allowing servers to distinguish Cloudflare-verified bots from malicious traffic.
What it does well:
- Practical, deployed at scale
- Solves the immediate problem of bot identification for web traffic
- Built on IETF httpbis-message-signatures
Where it does not extend:
- Single-hop. Identifies the bot, not who authorized it or with what scope.
- No action records.
- Tied to Cloudflare's infrastructure for trust.
Bot Protocol generalizes the Web Bot Auth pattern: Bot Protocol's Delegation Tokens carry similar semantics in a vendor-neutral form.
Several IETF drafts (as of 2026) explore aspects of AI agent authentication:
draft-klrc-aiagent-auth— agent-to-service authentication patterns- Various drafts on workload identity for AI
What they do well:
- Active standardization, broad community input
- Will eventually produce stable RFCs
Where they do not extend (yet):
- Most focus on agent-to-service. Agent-to-agent across organizations is less developed.
- Biometric binding to subjects is not addressed.
- Action records and audit trails are not in scope.
Bot Protocol is meant to feed into IETF work. By publishing under Apache 2.0 with patent grant, contributions can be made to IETF drafts as they mature.
Several Russian frameworks define compliance requirements that Bot Protocol can help satisfy:
- 152-FZ (Personal Data Law): requires demonstrable consent for processing personal data
- 779-P (Bank of Russia operational resilience): requires audit trails for critical operations
- EBS (Unified Biometric System): national biometric infrastructure
- KEP (Qualified Electronic Signature): legally-binding digital signature
Where they do not extend:
- These are legal/regulatory frameworks, not technical specifications for the audit and consent layer.
- They specify requirements but not the technical mechanism.
Bot Protocol provides the mechanism: Action Receipts satisfy 779-P audit requirements; EBS-anchored Subjects satisfy biometric binding under 152-FZ; KEP can sign Delegation Tokens for legally-significant authorization.
The combination of capabilities Bot Protocol provides — multi-hop delegation, monotonic scope reduction, cryptographically bound action records, real-time cross-organizational revocation, and biometric anchoring — is not available in any single existing standard. Each existing standard solves part of the problem.
Bot Protocol does not invent new cryptographic primitives. It composes existing primitives (Ed25519, JWT, DPoP, DID) in a specific structure suited to autonomous agents.
If, in the future, the relevant pieces appear in OAuth, IETF, W3C, or other standards bodies, Bot Protocol may merge into them. The Apache 2.0 license is chosen specifically to allow this.
For implementers building agent infrastructure today:
- If you need workload identity in a single organization → use SPIFFE
- If you need user-to-client authorization → use OAuth 2.1 with DPoP
- If you need decentralized identifiers → use W3C DID
- If you need content provenance → use C2PA
- If you need multi-hop human-to-agent delegation with audit trail → Bot Protocol fills this gap
Bot Protocol can be used alongside all the above. It is not a replacement.