A Unified Delegation and Identity Framework for the Age of Agentic Payments
《信任标准层》—— 智能体支付时代的统一委托与身份框架
Every 15–20 years, the payments industry undergoes a paradigm shift — from cash to cards, cards to online, online to mobile. Each transition redefines the trust model that makes value transfer possible.
We are entering the fifth paradigm: agentic payments. For the first time in the history of commerce, the entity initiating a transaction is not a human being. Current protocols (ACP, AP2, x402) each solve pieces of the puzzle, but three structural gaps remain:
- No unified credential binding agent identity, delegation scope, and settlement capability
- No chain delegation protocol for multi-hop agent-to-agent delegation with budget inheritance and audit trails
- No settlement abstraction allowing a single credential to route across card networks, stablecoins, and real-time payment rails
The Trust Standard Layer is an open, settlement-agnostic protocol built on two core components:
- Agent Payment Credential (APC) — A composable, verifiable token that simultaneously answers: who is this agent, what can it do, and how does it pay?
- Chain Delegation Protocol (CDP) — A formal framework for multi-hop delegation with budget conservation, permission narrowing, and end-to-end auditability
Both are designed to operate across Visa/Mastercard tokenization, blockchain micropayments (x402), and real-time payment rails — without replacing any of them.
TSL is built on established international standards, not invented from scratch:
| Component | Standards Referenced |
|---|---|
| Agent identity | W3C DID v1.1, W3C Verifiable Credentials 2.0 |
| Entity identification | ISO 17442 LEI (Legal Entity Identifier) |
| Token format | IETF RFC 7519 (JWT), RFC 7515 (JWS), SD-JWT |
| Currency codes | ISO 4217 (fiat), ISO 24165 DTI (digital tokens) |
| Merchant categories | ISO 18245:2023 (MCC) |
| Country codes | ISO 3166-1 alpha-2 |
| Timestamps | ISO 8601 / RFC 3339 |
| Token exchange | IETF RFC 8693 (OAuth 2.0 Token Exchange) |
| Settlement messages | ISO 8583 (payment card messaging), ISO 20022 |
| Cryptographic signatures | RFC 8037 (Ed25519), updated by RFC 9864 |
| Revocation | RFC 5280 (CRL), W3C Bitstring Status List |
| Risk classification | FATF Risk-Based Approach (Recommendations 1, 16) |
| Selective disclosure | IETF SD-JWT (draft) |
trust-standard-layer/
├── README.md # This file
├── LICENSE # Apache 2.0
├── CONTRIBUTING.md # How to contribute
│
├── docs/ # Documentation & papers
│ ├── paper-en.md # Full paper (English)
│ ├── paper-zh.md # Full paper (中文)
│ ├── architecture-overview.md # Architecture diagrams & design rationale
│ └── glossary.md # Terminology definitions (bilingual)
│
├── specs/ # Protocol specifications
│ ├── apc-token-spec.md # APC Token (flow layer) specification
│ ├── apc-record-spec.md # APC Record (storage layer) specification
│ ├── cdp-spec.md # Chain Delegation Protocol specification
│ ├── kya-integration-spec.md # KYA provider integration specification
│ ├── settlement-binding-spec.md # Settlement rail abstraction specification
│ └── schemas/ # Machine-readable schemas
│ ├── apc-token.schema.json # APC Token JSON Schema
│ ├── apc-record.schema.json # APC Record JSON Schema
│ ├── conditions.schema.json # 7 core condition types schema
│ └── cdp-messages.schema.json # CDP protocol messages schema
│
├── registry/ # Maintained registries
│ ├── tsl-categories.json # TSL Category → ISO 18245 MCC mapping
│ ├── regional-defaults.json # Trust level default limits by country
│ ├── condition-types.json # Registered condition types
│ └── rail-types.json # Supported settlement rail definitions
│
├── examples/ # Usage examples
│ ├── consumer-shopping.md # Scenario: AI personal shopper
│ ├── agent-to-agent.md # Scenario: Agent hiring agent (M2M)
│ ├── enterprise-procurement.md # Scenario: Autonomous procurement
│ └── sample-apcs/ # Sample APC tokens for testing
│ ├── root-apc-visa.json # Root APC with Visa settlement
│ ├── root-apc-crypto.json # Root APC with USDC settlement
│ ├── child-apc-delegated.json # Chain-delegated child APC
│ └── multi-hop-chain.json # Complete 3-hop delegation chain
│
└── sdk/ # Reference implementations (future)
└── README.md # SDK roadmap
| Document | Status | Description |
|---|---|---|
| Paper (EN/ZH) | 🟡 Draft v1.0 | Position paper establishing the framework |
| Architecture Overview | 🟡 Draft | Design rationale and diagrams |
| APC Token Spec | 🟡 Draft | Flow-layer credential specification |
| APC Record Spec | 🔴 Planned | Storage-layer record specification |
| CDP Spec | 🟡 Draft | Chain Delegation Protocol specification |
| KYA Integration Spec | 🔴 Planned | How KYA providers issue attestations |
| Settlement Binding Spec | 🔴 Planned | Settlement rail abstraction |
| JSON Schemas | 🟡 Draft | Machine-readable APC and CDP schemas |
| TSL Category Registry | 🟡 Draft | Category ↔ MCC mapping table |
| Regional Defaults | 🟡 Draft | Trust level limits by country/region |
| Condition Types Registry | 🟡 Draft | 7 core + extensible condition types |
| Examples | 🔴 Planned | Walkthrough scenarios with sample APCs |
| SDK | 🔴 Planned | Reference implementation in TypeScript/Python |
-
Flow/Storage separation — APC Token (lightweight, for transaction flow) vs APC Record (complete, for audit). Inspired by the magnetic stripe card / issuer database separation in card payments.
-
Settlement-agnostic — The trust layer does not prescribe how money moves. A single APC can bind to Visa tokens, USDC wallets, or FedNow instructions.
-
Standards-first — Every field maps to an existing international standard where one exists. TSL only innovates where no standard covers the need.
-
Monotonic Narrowing — In any delegation chain, permissions and budgets can only get smaller, never larger. Formally: scope(child) ⊆ scope(parent), budget(child) ≤ budget(parent).
-
Approval Rule as first-class citizen — Every APC must define the human-machine boundary: what the agent can do autonomously, what requires human confirmation.
TSL builds on and complements several concurrent efforts:
- Google DeepMind "Intelligent AI Delegation" (arXiv:2602.11865, Feb 2026) — A general-purpose delegation framework proposing Delegation Capability Tokens (DCTs) with authority-responsibility-accountability transfer. TSL's CDP can be understood as an instantiation of their framework in the payment vertical, adding payment-specific semantics (budget conservation, MCC categories, settlement routing).
- "Authenticated Delegation and Authorized AI Agents" (arXiv:2501.09674, Jan 2025) — Extends OAuth 2.0 / OpenID Connect with agent-specific delegation tokens. TSL adds the settlement and budget layers that IAM-focused approaches lack.
- Kite (gokite.ai) — An AI payment blockchain with nested governance and cascading constraints. TSL provides the same delegation properties in a settlement-agnostic manner across card networks, RTP, and crypto.
- Industry protocols (ACP, AP2, x402, Visa TAP, Mastercard Verifiable Intent) — TSL is designed to operate above these protocols, not replace them. An APC's settlement binding can wrap any of them.
Start with the Architecture Overview for a visual introduction, then read the APC Token Spec for the core credential design.
We welcome contributions from the payments, AI, and crypto communities. See CONTRIBUTING.md for guidelines.
Priority areas:
- Review and feedback on APC/CDP specifications
- Regional default limit proposals (especially non-US/EU markets)
- MCC mapping validation for TSL Categories
- Security analysis and threat modeling
- Reference implementations in any language
This project is licensed under the Apache License 2.0.
杜宁 (Du Ning) — Senior payments industry expert with firsthand experience across all four paradigm shifts from cash to mobile payments. Former standards and policy contributor.
Contact: [email protected]
If you reference this work, please cite:
Du Ning, "The Trust Standard Layer: A Unified Delegation and Identity Framework
for the Age of Agentic Payments," 2026. Available: https://github.com/adu2077/trust-standard-layer