Remove Complete message type per updated TAIP specifications #21
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Remove Complete message implementation from tap-msg - Remove CompleteTool from tap-mcp tools - Update test files to remove Complete references - Update MCP integration test to expect 30 tools instead of 31 - Update README.md to list Cancel and Revert instead of Complete This aligns the codebase with the updated TAIP specifications where the Complete message has been removed in favor of using the standard TAIP-4 authorization flow (Payment -> Authorize -> Settle). 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Updated TAIPs submodule to commit 2f8e503 with significant enhancements: - Schema.org Organization attributes for Agents and Parties - AuthorizationRequired message moved to TAIP-4 - RFC 8905 PayTo URI support for settlement addresses - Fallback settlement addresses for Payment messages - Schema.org Product attributes for invoice line items - Enhanced IVMS101 data inclusion - ServiceUrl field for Agent DIDComm endpoint fallback - Added TASKS.md with TDD-focused implementation plan - Organized into 5 phases with test-first approach - Each feature has failing tests written before implementation - Maintains backward compatibility through optional fields
- Added schema.org Organization field accessors and builders to Agent: - name, url, logo, description, email, telephone fields - serviceUrl field for DIDComm endpoint fallback (TAIP-5) - All fields use existing metadata HashMap for backward compatibility - Added typed accessor methods and builder pattern support - Added schema.org Organization field accessors and builders to Party: - name, url, logo, description, email, telephone fields - Added with_metadata_field builder method - All fields use existing metadata HashMap for backward compatibility - Verified IVMS101 data can coexist with schema.org fields - Followed TDD approach: wrote failing tests first, then implementation - All tests passing, JSON-LD compliance maintained - Updated TASKS.md to mark Phase 1 as complete
…cation - Updated existing AuthorizationRequired struct in connection.rs: - Changed 'url' field to 'authorizationUrl' per TAIP-4 - Made 'expires' field required (was optional) - Added optional 'from' field for party type (customer, principal, originator, beneficiary) - Removed deprecated 'agent_id' field - Updated validation logic: - Validates expires is present and in ISO 8601 format - Validates 'from' field contains valid party type if present - Added comprehensive tests: - Creation and builder pattern tests - Serialization/deserialization tests - Validation tests for all fields - JSON compliance with TAIP-4 specification - Updated TASKS.md to mark Phase 2 as complete Note: AuthorizationRequired was moved from TAIP-15 to TAIP-4 as a standard authorization message, replacing the removed Complete message functionality.
- Applied cargo fmt to all modified files - Fixed formatting in Agent and Party accessor methods - Fixed formatting in test files - Fixed import statement formatting - No functional changes, only formatting cleanup
- Added test vectors for AuthorizationRequired matching TAIP-4 specification - Added test vectors for Transfer with PayTo URI support (RFC 8905) - Added test vectors for Escrow messages (TAIP-17) - Added test vectors for Payment with PayTo URI invoices - Fixed existing test vectors to match JSON schema requirements The AuthorizationRequired test vectors now correctly use 'authorizationUrl' field name as specified in TAIP-4, which matches our implementation.
…d TAIPs - Add PayTo URI support (RFC 8905) for traditional payment systems - Add SettlementAddress enum supporting both CAIP-10 and PayTo URIs - Add fallbackSettlementAddresses field to Payment messages - Add schema.org/Product attributes (name, image, url) to LineItem - Add LineItem builder for easier construction - Update all existing LineItem usages with new fields - Add comprehensive tests for all new features 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…changes 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Mark all completed implementation tasks with [x]: - Phase 1-4: All tasks completed - Phase 5: Partial completion (integration and validation done) Remaining items are MCP-specific integrations and test vector validation which are separate from the core TAP message implementation. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Update workspace version from 0.4.0 to 0.5.0 - Update all internal dependencies between crates to 0.5.0 - Update CHANGELOG to mark 0.5.0 release 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Add v0.5.0 highlights to main README - Document PayTo URI support and settlement address flexibility - Add examples for fallback settlement addresses - Document enhanced metadata support for Agents/Parties/LineItems - Add code examples for new schema.org Organization fields - Add examples for Product attributes in invoice line items - Update tap-msg README with new features 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Implement Escrow message for holding assets on behalf of parties - Implement Capture message for releasing escrowed funds - Support both cryptocurrency assets (CAIP-19) and fiat currencies (ISO 4217) - Add automatic expiry handling for escrows - Enable payment guarantees, asset swaps, and conditional payments - Add EscrowAgent role with validation for exactly one per escrow - Add comprehensive tests for all escrow scenarios - Update TapMessage enum to include Escrow and Capture variants - Update CHANGELOG with TAIP-17 support documentation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit extends the TAP MCP server to support Payment (TAIP-14), Connect (TAIP-15), and Escrow/Capture (TAIP-17) message creation and management alongside the existing Transfer tools. New MCP Tools Added: - CreatePaymentTool: Creates TAIP-14 Payment messages with asset or currency support - CreateConnectTool: Creates TAIP-15 Connect messages with constraints and limits - CreateEscrowTool: Creates TAIP-17 Escrow messages with automatic EscrowAgent validation - CaptureTool: Creates TAIP-17 Capture messages for releasing escrowed funds Key Features: - Full schema definitions for all new tools with parameter validation - Support for both cryptocurrency (CAIP-19) and fiat currency transactions - Connection constraint handling with transaction limits - Automatic validation of EscrowAgent requirements per TAIP-17 - Integration with existing TAP node message delivery infrastructure Technical Details: - Added comprehensive parameter structures for each message type - Implemented proper field mapping between MCP parameters and TAP message structs - Fixed Payment struct compatibility by adding fallback_settlement_addresses field - Enhanced error handling and validation for all new message types 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…schemas
Add two new MCP resources to provide better access to read-only data:
1. Database Schema Resource (tap://database-schema)
- Provides comprehensive database schema information for agent storage
- Supports filtering by agent_did (required) and table_name (optional)
- Returns table structures, column info, indexes, and row counts
- Uses read-only SQLite connections for safety
- Replaces need to use database schema tool for read-only access
2. Enhanced TAP Message Schemas Resource (tap://schemas)
- Existing resource enhanced with individual schema lookup capability
- Supports tap://schemas/{MessageType} for specific schemas
- Includes comprehensive JSON schemas for all TAP message types
- Added version information and structured metadata
- Supports lookup by both message type name and URL
Technical changes:
- Updated resource registry to include new database-schema resource
- Enhanced schemas resource with path-based routing for individual lookups
- Added database connection logic to resources layer
- Updated tests to reflect new resource count (6 total)
- Updated tool count in tests (34 total)
- Refactored schema generation to support both full and individual access
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Apply standard Rust formatting to the new MCP resources code.
Apply standard Rust formatting to all files in the workspace. This includes formatting changes to: - tap-mcp tools and schemas - tap-msg message types and tests - Add Claude agent configuration file 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Update README.md to document the new MCP resources added in v0.5.0: 1. Database Schema Resource (tap://database-schema) - Document new resource for accessing agent database schemas - Show query parameters and usage examples - Explain relationship to tap_get_database_schema tool 2. Enhanced TAP Schemas Resource (tap://schemas) - Document individual schema lookup capability - Show examples for specific message types (Transfer, Authorize, etc.) - Highlight v0.5.0 enhancements 3. Updated Examples - Add examples showing how to use the new resources - Include database schema and individual message schema lookups - Maintain consistency with existing documentation style 4. Resource Count Update - Update tool count from 29 to 34 tools - Update resource count to 6 total resources - Reflect current capabilities accurately 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Fix unused variable warnings by prefixing with underscores - Add #[allow(dead_code)] to unused struct fields in payment/connect params - Remove redundant uuid import 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Update all workspace dependencies to their latest compatible versions: - tokio: 1.32.0 → 1.47.1 - anyhow: 1.0.75 → 1.0.99 - uuid: 1.16.0 → 1.18.0 - base64: 0.21 → 0.22 - async-trait: 0.1 → 0.1.89 - ed25519-dalek: 2.0 → 2.2 - reqwest: 0.11 → 0.12 - hyper: 0.14 → 1.6 - dirs: 5.0 → 6.0 - dashmap: 5.4 → 6.1 - tokio-tungstenite: 0.20 → 0.24 - sqlx: 0.8.2 → 0.8.6 - criterion: 0.5 → 0.6 - once_cell: 1.18/1.8 → 1.21.3 - proptest: 1.2/1.6 → 1.7 - rstest: 0.18 → 0.25 - clap: 4.4 → 4.5 Maintained compatibility versions for: - rand: kept at 0.8 for crypto library compatibility - getrandom: kept at 0.2 for WASM feature compatibility - thiserror: standardized on 1.0 across workspace All core crates (tap-msg, tap-caip, tap-ivms101) build and pass tests. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Fixed the MCP schemas resource to return only the specific schema when requesting individual message types (e.g., tap://schemas/Payment). Changes: - Modified read_specific_schema() to use consistent schema structure - Individual schema responses now match the format of full schema responses - Added test for specific schema resource access 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit implements comprehensive payment link functionality for the tap-agent crate, enabling creation of shareable payment links using DIDComm v2 Out-of-Band invitations according to TAIP-2 and TAIP-14 specifications. ## New Features ### Out-of-Band (OOB) Message Support - Full DIDComm v2 Out-of-Band invitation implementation (TAIP-2 compliant) - URL encoding/decoding with base64url encoding for safe transmission - Signed attachment support for carrying DIDComm messages - Validation logic for TAP-specific goal codes (tap.payment, tap.connect, tap.transfer) - Builder pattern for easy OOB invitation creation ### Payment Link Functionality - PaymentLink struct with configurable service URLs and metadata - Default service URL: https://flow-connect.notabene.dev/payin - Support for custom metadata and goal descriptions - Builder pattern for streamlined configuration ### Extended Agent Trait - create_oob_invitation() - Generic method supporting any TAP message type - create_payment_link() - Specialized method for Payment messages - parse_oob_invitation() - Parse OOB invitation URLs back to structures - process_oob_invitation() - Extract and verify signed messages from invitations ### Generic Design - Works with any TAP message type implementing TapMessageBody trait - Not limited to payments - supports transfers, connections, and future message types - Configurable service endpoints for different deployment scenarios - Extensible metadata support for custom use cases ## Technical Implementation ### Cryptographic Integration - JWS (JSON Web Signature) message signing using Ed25519 keys - DIDComm v2 message packing/unpacking with proper key management - Signature verification with DID resolution support ### Standards Compliance - TAIP-2 (DIDComm messaging) specification compliance - TAIP-14 (payments) specification support - DIDComm v2 Out-of-Band invitation format adherence - URL-safe base64url encoding for query parameters ### Code Organization - tap-agent/src/oob.rs - Out-of-Band invitation core functionality - tap-agent/src/payment_link.rs - Payment link specific features - Extended Agent trait in tap-agent/src/agent.rs with 4 new methods - Comprehensive test suite with 14 total tests (7 integration + 7 unit tests) ## Files Added - tap-agent/src/oob.rs - Out-of-Band invitation implementation - tap-agent/src/payment_link.rs - Payment link functionality - tap-agent/tests/simple_payment_link_tests.rs - Comprehensive test suite - tap-agent/PAYMENT_LINKS.md - Documentation and usage examples ## Files Modified - tap-agent/src/agent.rs - Extended Agent trait with OOB methods - tap-agent/src/lib.rs - Added module exports for new functionality 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Fix missing fallback_settlement_addresses field in Payment structs across examples and tests - Update base64 API calls to use new Engine interface (base64::engine::general_purpose::STANDARD.encode) - Migrate Hyper mock server to 1.x API with http-body-util for body handling - Fix payment_link_flow example with correct Secret, Party, and Agent constructors - Add missing imports and dependencies (tracing-subscriber, SettlementAddress, InvoiceReference) - Resolve field access patterns for Party.name() method calls - Remove non-existent policies field from Payment initialization - Update settlement address creation to use proper SettlementAddress::from_string() 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Updated prds/taips submodule from 32b2b67 to ba992e1, which includes: - CHANGELOG.md updates - Reorganized test vectors structure (moved files to appropriate subdirectories) - Fixed test vector organization for better structure This ensures we have the latest TAIP specifications and test vectors for our payment link implementation. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…t vector validation - Identified and resolved race condition in tap-mcp integration tests that caused intermittent failures - Enhanced test vector validation for Transfer, Payment, and Escrow messages with better error handling - Updated TAIPs submodule to latest version for compatibility - Tests now pass consistently when run with proper isolation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR updates the TAP implementation to align with the latest TAIP specifications by removing the Complete message type and implementing several new features and improvements.
Key Changes
Specification Compliance
New Features
Code Quality Improvements
Detailed Changes
Message Type Removal
tap-msg/src/message/complete.rsPayment Links & OOB Invitations
Schema & Resource Improvements
Test & Build Improvements
Test Plan
cargo test --workspace)cargo build)Context
This PR aligns the codebase with the latest TAIP specifications where the Complete message was removed in favor of the standard TAIP-4 authorization flow (Payment -> Authorize -> Settle). Additionally, it adds important new functionality for payment links and improves overall code quality and test reliability.
🤖 Generated with Claude Code