You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: TAIPs/taip-15.md
+69-13Lines changed: 69 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,19 +16,24 @@ A standard protocol for establishing secure, authorized connections between agen
16
16
17
17
## Abstract
18
18
19
-
This TAIP defines a protocol for agents to establish secure, authorized connections with each other, particularly for ongoing business relationships. It builds on [TAIP-2] messaging, [TAIP-9] relationship proofs, and [TAIP-13] purpose codes to provide a standardized way for agents to request and authorize connections with transaction constraints. The protocol includes OAuth-style authorization flows, allowing interactive user consent when needed, and supports defining transaction limits and allowed purposes upfront.
19
+
This TAIP defines a protocol for agents to establish secure, authorized connections with each other, particularly for ongoing business relationships like agentic initiated transaction workflows as well as recurring and metered billing. It builds on [TAIP-2] messaging, [TAIP-9] relationship proofs, and [TAIP-13] purpose codes to provide a standardized way for agents to request and authorize connections with transaction constraints. The protocol includes OAuth-style authorization flows, allowing interactive user consent when needed, and supports defining transaction limits and allowed purposes upfront.
20
20
21
21
## Motivation
22
22
23
23
The Transaction Authorization Protocol enables secure communication between different agents (AI Agents, VASPs, wallets, custodians, etc.). However, for ongoing business relationships, agents need a way to establish persistent, authorized connections with predefined constraints. Current implementations often rely on ad-hoc methods or require repeated authorizations. This TAIP addresses several key needs:
24
24
25
-
1.**Business Integration:** B2B services need to connect securely with their customers' accounts at VASPs or custodians for ongoing transactions on behalf of the customer.
26
-
2.**User Authorization:** Account holders must explicitly authorize agent connections through familiar OAuth-style flows.
27
-
3.**Transaction Constraints:** Connections should specify upfront what types of transactions are allowed (purposes, limits).
28
-
4.**Relationship Verification:** Agents must prove their relationship to the parties they represent.
29
-
5.**Risk Management:** Receiving agents need to maintain state and manage risk in real-time.
25
+
1.**AI Agent Transactions:** Autonomous AI agents executing trades, payments, or financial operations within user-defined limits and purposes (e.g., trading bot with $10k daily limit for crypto arbitrage).
3.**Self-Onboarding Services:** Entities directly onboarding with service providers where the agent and principal are the same party (e.g., a merchant directly connecting to a payment processor's API, a business self-registering with a financial platform).
30
28
31
-
By standardizing these connection aspects, we enable secure B2B integrations while maintaining user control and risk management.
29
+
4.**Corporate Treasury Management:** CFO tools and treasury platforms managing cash flows, vendor payments, and payroll on behalf of businesses (e.g., automated supplier payments, cross-border payroll processing).
8.**Cross-Border Payment Services:** International payment providers and remittance services executing FX conversions and transfers (e.g., Wise business accounts, payroll providers handling multi-currency payments).
By standardizing these connection aspects, we enable secure B2B integrations while maintaining user control and risk management. Each connection enforces specific constraints including transaction limits, allowed purposes, and time boundaries.
32
37
33
38
## Specification
34
39
@@ -43,7 +48,7 @@ A message sent by an agent requesting connection to another agent:
43
48
-`@context` - REQUIRED the JSON-LD context `https://tap.rsvp/schema/1.0`
44
49
-`@type` - REQUIRED the JSON-LD type `https://tap.rsvp/schema/1.0#Connect`
45
50
-`agent` - OPTIONAL object containing information about the requesting agent:
46
-
-`@id` - REQUIRED string DID of the requesting agent
51
+
-`@id` - REQUIRED string DID of the requesting agent. If the `agent` object is included, the `@id` MUST match the `from` field of the surrounding DIDComm message
47
52
-`name` - OPTIONAL string human-readable name of the agent
48
53
-`type` - OPTIONAL string type of agent (e.g. "ServiceAgent", "WalletAgent")
49
54
-`serviceUrl` - OPTIONAL string URL for the agent's DIDComm endpoint
@@ -55,8 +60,12 @@ A message sent by an agent requesting connection to another agent:
55
60
-`categoryPurposes` - OPTIONAL array of [TAIP-13] category purpose codes
-`currency` - REQUIRED string ISO 4217 currency code if limits are specified
68
+
-`agreement` - OPTIONAL string URL pointing to terms of service or agreement between the principal and requesting agent
60
69
-`expiry` - OPTIONAL timestamp in ISO 8601 format indicating when the connection request expires. After this time, if no authorization has occurred, the connection request should be considered invalid. This is distinct from the technical message expiry handled by the DIDComm `expires_time` header.
61
70
62
71
### AuthorizationRequired Message
@@ -98,7 +107,7 @@ A message sent by principal to terminate an existing connection:
98
107
- Their identity and endpoints
99
108
- The party they represent
100
109
- Desired transaction constraints
101
-
110
+
102
111
2. Agent B chooses an authorization method:
103
112
- Option 1: Out-of-band Authorization
104
113
- Notifies customer through existing channels
@@ -163,7 +172,8 @@ Example Out-of-Band message with Connect request:
163
172
},
164
173
"constraints": {
165
174
"purposes": ["BEXP", "SUPP"]
166
-
}
175
+
},
176
+
"agreement": "https://b2b-service.com/terms"
167
177
},
168
178
"attachments": [],
169
179
"created_time": 1516269022
@@ -320,10 +330,11 @@ The following are example plaintext messages. See [TAIP-2] for how to sign the m
- The `agent.@id` and `principal.@id` are the same DID (`did:example:merchant`)
457
+
- The `agent.@id` matches the `from` field of the DIDComm message
458
+
- The merchant is acting as both the technical agent and the business principal
459
+
- The `agreement` field points to the merchant agreement terms
460
+
405
461
## Using Connections for Transactions
406
462
407
463
Once a connection is established, the connecting agent can perform transactions on behalf of the customer. All transactions related to a connection MUST include the connection's `id` as the `pthid` (parent thread ID) in the message header. This allows receiving agents to validate the transaction against the connection's constraints.
@@ -455,7 +511,7 @@ The receiving agent MUST:
455
511
- Verify the amount is within the per-transaction and daily limits
456
512
- Confirm the originator's `@id` matches the connection's `principal.@id` value
457
513
- Verify the agent has permission to act for the specified principal
458
-
3. Process the transaction according to [TAIP-4] if all checks pass
514
+
3. Process the transaction according to [TAIP-4] if all checks pass
0 commit comments