Remove Complete message type per updated TAIP specifications

.claude/agents/tap-expert.md

@@ -0,0 +1,67 @@
+---
+name: tap-expert
+description: Use proactively to retrieve and extract relevant information about the TAP spec and TAIPs
+tools: Read, Grep, Glob
+color: blue
+---
+
+You are a specialized information retrieval agent for TAP message specs. Your role is to efficiently fetch and extract relevant content from the TAP spec repo while avoiding duplication.
+
+## Core Responsibilities
+
+1. **Context Check First**: Determine if requested information is already in the main agent's context
+2. **Selective Reading**: Extract only the specific sections or information requested
+3. **Smart Retrieval**: Use grep to find relevant sections rather than reading entire files
+4. **Return Efficiently**: Provide only new information not already in context
+
+## Supported File Types
+
+- Specs: @prds/taips/TAIPs/*.md
+- Product docs: @prds/taips/*.md
+- Typescript types: @prds/taips/packages/typescript/src/*.ts
+- JSON schemas: @prds/taips/schemas/**/*.json
+
+## Workflow
+
+1. Check if the requested information appears to be in context already
+2. If not in context, locate the requested file(s)
+3. Extract only the relevant sections
+4. Return the specific information needed
+
+## Output Format
+
+For new information:
+```
+📄 Retrieved from [file-path]
+
+[Extracted content]
+```
+
+For already-in-context information:
+```
+✓ Already in context: [brief description of what was requested]
+```
+
+## Smart Extraction Examples
+
+Request: "Get the pitch from mission-lite.md"
+→ Extract only the pitch section, not the entire file
+
+Request: "Find CSS styling rules from code-style.md"
+→ Use grep to find CSS-related sections only
+
+Request: "Get Task 2.1 details from tasks.md"
+→ Extract only that specific task and its subtasks
+
+## Important Constraints
+
+- Never return information already visible in current context
+- Extract minimal necessary content
+- Use grep for targeted searches
+- Never modify any files
+- Keep responses concise
+
+Example usage:
+- "Get the product pitch from mission-lite.md"
+- "Find Ruby style rules from code-style.md"
+- "Extract Task 3 requirements from the password-reset spec"

CHANGELOG.md

@@ -5,6 +5,42 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.5.0] - 2025-08-14
+
+### Added
+
+#### Composable Escrow Support (TAIP-17)
+- New `Escrow` message for holding assets on behalf of parties
+- New `Capture` message for releasing escrowed funds
+- Support for both cryptocurrency assets and fiat currencies in escrows
+- Automatic expiry handling for escrows
+- Support for payment guarantees, asset swaps, and conditional payments
+- Multiple agent roles including dedicated EscrowAgent role
+- Full validation ensuring exactly one EscrowAgent per escrow
+
+#### Settlement Address Enhancements
+- PayTo URI support (RFC 8905) for traditional payment systems (IBAN, ACH, BIC, UPI)
+- `SettlementAddress` enum supporting both CAIP-10 blockchain addresses and PayTo URIs
+- `fallbackSettlementAddresses` field in Payment messages for flexible payment options
+- Full validation and serialization for PayTo URIs
+
+#### Invoice Product Attributes
+- Schema.org/Product attributes to LineItem (name, image, url)
+- LineItem builder pattern for easier construction
+- Support for product metadata in invoice line items
+
+#### Agent and Party Enhancements  
+- Schema.org Organization fields for Agent and Party structures
+- Added fields: name, url, logo, description, email, telephone, serviceUrl
+- Builder methods and accessor functions for all new fields
+- Backward compatible with existing IVMS101 data
+
+### Changed
+- AuthorizationRequired message updated to match TAIP-4 specification
+  - Field `url` renamed to `authorizationUrl`
+  - Field `expires` now required
+  - Added optional `from` field
+
 ## [0.4.0] - 2025-06-17
 
 ### Added

Cargo.toml

@@ -12,7 +12,7 @@ members = [
 resolver = "2"
 
 [workspace.package]
-version = "0.4.0"
+version = "0.5.0"
 edition = "2021"
 authors = ["Pelle Braendgaard <[email protected]>"]
 description = "Rust implementation of the Transaction Authorization Protocol (TAP)"

README.md

@@ -2,7 +2,11 @@
 
 This repository contains a Rust implementation of the Transaction Authorization Protocol (TAP), a decentralized protocol for securely authorizing blockchain transactions before they are submitted on-chain. TAP-RS targets payment-related use cases, Travel Rule compliance, and secure transaction coordination.
 
-**New in this release**: Full Travel Rule support with IVMS101 data model implementation, automatic customer data extraction, and compliance workflow automation.
+**New in v0.5.0**: 
+- PayTo URI support (RFC 8905) for traditional payment systems (IBAN, ACH, BIC, UPI)
+- Fallback settlement addresses for flexible payment options
+- Schema.org Product attributes for invoice line items
+- Enhanced Agent and Party structures with Organization fields
 
 ## Project Structure
 
@@ -116,12 +120,14 @@ See individual tool READMEs for detailed usage instructions.
 
 ## Key Features
 
-- **Complete TAP Implementation**: Support for all TAP message types (Transfer, Authorize, Reject, Settle, Complete, etc.)
+- **Complete TAP Implementation**: Support for all TAP message types (Transfer, Authorize, Reject, Settle, Cancel, Revert, etc.)
 - **DIDComm v2 Integration**: Secure, encrypted messaging with authenticated signatures
 - **Chain Agnostic Identifiers**: Implementation of CAIP-2 (ChainID), CAIP-10 (AccountID), and CAIP-19 (AssetID)
+- **Settlement Address Flexibility**: Support for both blockchain (CAIP-10) and traditional payment systems (PayTo URI)
 - **Multiple DID Methods**: Support for did:key, did:web, did:pkh, and more
 - **Travel Rule Compliance**: Full IVMS 101.2023 implementation with automatic data attachment
 - **Customer Data Management**: Automatic extraction and storage of party information from TAP messages
+- **Enhanced Metadata Support**: Schema.org Organization fields for Agents/Parties and Product attributes for invoices
 - **Command-line Tools**: Utilities for DID generation, resolution, and key management
 - **Modular Agent Architecture**: Flexible identity and cryptography primitives
 - **High-Performance Message Routing**: Efficient node implementation for high-throughput environments
@@ -179,6 +185,67 @@ let message = transfer.to_didcomm_with_route(
 
 See the [tap-msg README](./tap-msg/README.md) for more detailed examples.
 
+## New in v0.5.0: Settlement Address Flexibility
+
+TAP-RS now supports both blockchain and traditional payment settlement addresses:
+
+```rust
+use tap_msg::settlement_address::{SettlementAddress, PayToUri};
+use tap_msg::Payment;
+
+// Traditional payment system addresses using PayTo URI (RFC 8905)
+let iban_address = SettlementAddress::from_string(
+    "payto://iban/DE75512108001245126199".to_string()
+)?;
+
+let ach_address = SettlementAddress::from_string(
+    "payto://ach/122000247/111000025".to_string()
+)?;
+
+// Blockchain addresses using CAIP-10
+let eth_address = SettlementAddress::from_string(
+    "eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb".to_string()
+)?;
+
+// Payment with fallback settlement addresses
+let payment = Payment::builder()
+    .amount("100.00".to_string())
+    .currency_code("USD".to_string())
+    .merchant(Party::new("did:example:merchant"))
+    .fallback_settlement_addresses(vec![
+        iban_address,  // Primary: traditional bank transfer
+        eth_address,   // Fallback: Ethereum address
+    ])
+    .build();
+```
+
+## Enhanced Metadata Support
+
+Agents, Parties, and LineItems now support rich metadata:
+
+```rust
+use tap_msg::{Agent, LineItem};
+
+// Agent with Organization metadata
+let agent = Agent::new("did:example:agent", "PaymentProcessor", "did:example:merchant")
+    .with_name("Example Payment Services")
+    .with_url("https://example.com")
+    .with_email("[email protected]")
+    .with_telephone("+1-555-0100");
+
+// LineItem with Product attributes
+let line_item = LineItem::builder()
+    .id("item-001".to_string())
+    .description("Premium Coffee Beans".to_string())
+    .quantity(2.0)
+    .unit_price(25.99)
+    .line_total(51.98)
+    .name("Colombian Arabica Premium Blend".to_string())
+    .image("https://example.com/products/coffee.jpg".to_string())
+    .url("https://example.com/products/coffee".to_string())
+    .build();
+```
+
 ## Typed Messages for Type Safety
 
 TAP-RS now supports generic typed messages for compile-time type safety while maintaining 100% backward compatibility:

TASKS.md

@@ -0,0 +1,166 @@
+# TAP-RS Implementation Tasks - Updated TAIP Specifications
+
+This document tracks the implementation of updated TAIP specifications following the submodule update to align with the latest TAP protocol changes.
+
+## Overview
+
+The TAIPs submodule has been updated with significant enhancements including:
+- 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
+
+## Implementation Tasks (TDD Approach)
+
+### Phase 1: Agent and Party Enhancements
+
+- [x] **Write failing tests for Agent schema.org Organization fields**
+  - [x] Test Agent with `name` field serialization/deserialization
+  - [x] Test Agent with `url` field serialization/deserialization  
+  - [x] Test Agent with `logo` field serialization/deserialization
+  - [x] Test Agent with `description` field serialization/deserialization
+  - [x] Test Agent with `email` field serialization/deserialization
+  - [x] Test Agent with `telephone` field serialization/deserialization
+  - [x] Test Agent with `serviceUrl` field (DIDComm endpoint fallback)
+  - [x] Test Agent with multiple organization fields combined
+  - [x] Test Agent JSON-LD compliance with new fields
+
+- [x] **Implement Agent schema.org Organization fields**
+  - [x] Add accessor methods for `name` field to Agent struct
+  - [x] Add accessor methods for `url` field to Agent struct
+  - [x] Add accessor methods for `logo` field to Agent struct
+  - [x] Add accessor methods for `description` field to Agent struct
+  - [x] Add accessor methods for `email` field to Agent struct
+  - [x] Add accessor methods for `telephone` field to Agent struct
+  - [x] Add accessor methods for `serviceUrl` field to Agent struct
+  - [x] Add builder methods for new fields
+  - [x] Ensure all tests pass
+
+- [x] **Write failing tests for Party schema.org Organization fields**
+  - [x] Test Party with `name` field serialization/deserialization
+  - [x] Test Party with `url` field serialization/deserialization
+  - [x] Test Party with `logo` field serialization/deserialization
+  - [x] Test Party with `description` field serialization/deserialization
+  - [x] Test Party with `email` field serialization/deserialization
+  - [x] Test Party with `telephone` field serialization/deserialization
+  - [x] Test Party with multiple organization fields combined
+  - [x] Test Party JSON-LD compliance with new fields
+  - [x] Test Party with IVMS101 and schema.org fields coexistence
+
+- [x] **Implement Party schema.org Organization fields**
+  - [x] Add accessor methods for `name` field to Party struct
+  - [x] Add accessor methods for `url` field to Party struct
+  - [x] Add accessor methods for `logo` field to Party struct
+  - [x] Add accessor methods for `description` field to Party struct
+  - [x] Add accessor methods for `email` field to Party struct
+  - [x] Add accessor methods for `telephone` field to Party struct
+  - [x] Add builder methods for new fields
+  - [x] Add `with_metadata_field` builder method
+  - [x] Ensure all tests pass
+
+### Phase 2: AuthorizationRequired Message Implementation
+
+- [x] **Write failing tests for AuthorizationRequired message**
+  - [x] Test AuthorizationRequired message creation and structure
+  - [x] Test field serialization/deserialization (authorizationUrl, expires, from)
+  - [x] Test optional `from` field with valid party types
+  - [x] Test validation for required fields
+  - [x] Test validation for invalid `from` values
+  - [x] Test ISO 8601 timestamp format validation
+  - [x] Test AuthorizationRequired JSON compliance with TAIP-4
+  - [x] Test builder pattern and metadata support
+
+- [x] **Implement AuthorizationRequired message**
+  - [x] Update existing `AuthorizationRequired` struct in `connection.rs`
+  - [x] Change `url` field to `authorizationUrl` per TAIP-4
+  - [x] Make `expires` field required per TAIP-4
+  - [x] Add optional `from` field for party type
+  - [x] Update validation logic for new requirements
+  - [x] Update constructors and builder methods
+  - [x] Ensure all tests pass
+
+### Phase 3: Settlement Address Enhancements
+
+- [x] **Write failing tests for PayTo URI support**
+  - [x] Test PayTo URI validation and parsing
+  - [x] Test settlement address union type (CAIP-10 | PayTo URI)
+  - [x] Test PayTo URI examples from RFC 8905 (IBAN, ACH, BIC, UPI)
+  - [x] Test invalid PayTo URI rejection
+
+- [x] **Implement PayTo URI support**
+  - [x] Create `settlement_address.rs` module in `tap-msg/src/`
+  - [x] Define `PayToURI` type with validation
+  - [x] Define `SettlementAddress` enum (CAIP10 | PayToURI)
+  - [x] Implement serialization/deserialization for SettlementAddress
+  - [x] Add PayTo URI validation regex
+  - [x] Ensure all tests pass
+
+- [x] **Write failing tests for fallback settlement addresses**
+  - [x] Test Payment message with `fallbackSettlementAddresses` array
+  - [x] Test mixed CAIP-10 and PayTo URI addresses in fallback array
+  - [x] Test optional fallback field serialization
+
+- [x] **Implement fallback settlement addresses in Payment messages**
+  - [x] Add optional `fallback_settlement_addresses: Option<Vec<SettlementAddress>>` to Payment
+  - [x] Update Payment builder methods
+  - [x] Update Payment serialization/deserialization
+  - [x] Ensure all tests pass
+
+### Phase 4: Invoice Product Attributes
+
+- [x] **Write failing tests for Product attributes in invoice line items**
+  - [x] Test LineItem with `name` field (schema.org/Product)
+  - [x] Test LineItem with `image` field (schema.org/Product)  
+  - [x] Test LineItem with `url` field (schema.org/Product)
+  - [x] Test LineItem with multiple product fields combined
+
+- [x] **Implement Product attributes in invoice line items**
+  - [x] Add optional `name: Option<String>` field to LineItem
+  - [x] Add optional `image: Option<String>` field to LineItem
+  - [x] Add optional `url: Option<String>` field to LineItem
+  - [x] Add builder methods for new fields
+  - [x] Ensure all tests pass
+
+### Phase 5: Integration and Cleanup
+
+- [x] **Update message exports and integration**
+  - [x] Add AuthorizationRequired to TapMessageEnum (already existed)
+  - [x] Update message mod.rs exports (settlement_address module added)
+  - [ ] Update message factory methods
+  - [ ] Update message validation
+
+- [ ] **Update MCP tools integration**
+  - [ ] Review MCP tools that may need AuthorizationRequired support
+  - [ ] Update transaction tools for new settlement address types
+  - [ ] Test MCP integration with new message types
+
+- [x] **Documentation and examples**
+  - [x] Update example code for new fields (invoice examples updated)
+  - [ ] Add AuthorizationRequired usage examples
+  - [x] Add PayTo URI usage examples (in tests)
+  - [x] Update CHANGELOG.md
+
+- [x] **Final validation**
+  - [x] Run full test suite: `cargo test`
+  - [x] Run clippy: `cargo clippy`
+  - [x] Run format check: `cargo fmt --check`
+  - [ ] Validate against TAIP test vectors
+  - [ ] Performance test new serialization paths
+
+## Test-Driven Development Notes
+
+1. **Write tests first** - Each implementation task should start with failing tests
+2. **Red-Green-Refactor** - Ensure tests fail, implement minimum code to pass, then refactor
+3. **Test edge cases** - Include validation tests for invalid inputs
+4. **JSON compliance** - Ensure all new fields serialize correctly for TAIP compliance
+5. **Backward compatibility** - All new fields should be optional to maintain compatibility
+
+## Success Criteria
+
+- [x] All tests pass
+- [x] No clippy warnings
+- [x] Code is properly formatted
+- [ ] TAIP test vectors validate successfully
+- [ ] MCP integration works with new message types
+- [x] Documentation is updated and examples work

tap-agent/Cargo.toml

@@ -9,8 +9,8 @@ license.workspace = true
 readme = "README.md"
 
 [dependencies]
-tap-msg = { version = "0.4.0", path = "../tap-msg" }
-tap-caip = { version = "0.4.0", path = "../tap-caip" }
+tap-msg = { version = "0.5.0", path = "../tap-msg" }
+tap-caip = { version = "0.5.0", path = "../tap-caip" }
 async-trait = { workspace = true }
 thiserror = "1.0"
 serde = { workspace = true }