Update docs

Author: pelle

authorization.md

@@ -43,30 +43,6 @@ The Authorize message indicates the beneficiary approves the transaction after c
 - Provides the originator legal clearance to execute the transaction
 - Creates an audit trail of approval for regulatory purposes
 
-### Complete
-
-The Complete message is specifically used in the Payment flow, sent by the merchant's agent to indicate the transaction is ready for settlement. It replaces the previously confusing use of Authorize for this purpose.
-
-**Business Implications**:
-- Clearly distinguishes merchant readiness for settlement from general authorization
-- Provides the settlement address where funds should be sent
-- Can specify an adjusted final amount (which must be less than or equal to the original requested amount)
-- Enables flexible payment scenarios like partial fulfillment or applied discounts
-- Creates a precise payment instruction for the customer's agent to follow
-
-```mermaid
-sequenceDiagram
-    participant Customer as Customer (Originator)
-    participant Merchant as Merchant (Beneficiary)
-    Merchant->>Customer: Payment (initial request)
-    Note over Customer: Customer reviews and decides
-    Customer->>Merchant: Authorize (accepts payment)
-    Note over Merchant: Process payment request
-    Merchant->>Customer: Complete (with settlement address, optional adjusted amount)
-    Note over Customer: Execute on-chain payment
-    Customer->>Merchant: Settle (with settlement proof and matching amount)
-```
-
 ### Reject
 
 The Reject message indicates the beneficiary cannot approve the transaction. A clear reason must be provided to help the originator understand the compliance issue.
@@ -94,7 +70,7 @@ The Settle message confirms that the originator has executed the authorized tran
 - Creates a record linking off-chain authorization to on-chain settlement
 - Enables reconciliation between compliance systems and blockchain transactions
 - Completes the authorization-settlement cycle for audit purposes
-- May include an amount field that must match any amount specified in a preceding Complete message
+- May include an amount field that must match any amount specified in a preceding Authorize message
 - Supports partial payment scenarios when used with the amount field
 
 ### Cancel
@@ -141,26 +117,26 @@ sequenceDiagram
 
 ### Payment Flow
 
-When using the Payment message type, the flow now includes the Complete message to clearly indicate settlement readiness.
+When using the Payment message type, the flow follows a request-response pattern where the merchant initiates and the customer responds.
 
 ```mermaid
 sequenceDiagram
     participant Customer as Customer (Originator)
     participant Merchant as Merchant (Beneficiary)
     Merchant->>Customer: Payment
     Note over Customer: Customer reviews and decides
-    Customer->>Merchant: Authorize (accepts payment)
+    Customer->>Merchant: Authorize (with settlementAsset)
     Note over Merchant: Process payment request
-    Merchant->>Customer: Complete (provides settlement address, optional adjusted amount)
+    Merchant->>Customer: Authorize (with settlementAddress)
     Note over Customer: Execute on-chain payment
-    Customer->>Merchant: Settle (with settlement proof and matching amount)
+    Customer->>Merchant: Settle (with settlement proof)
 ```
 
-This improved flow:
-- Clearly separates the customer's acceptance of the payment (Authorize) from the merchant's readiness to receive it (Complete)
-- Allows merchants to specify a final settlement amount that may differ from the original requested amount
-- Ensures the customer's wallet sends the correct amount specified in the Complete message
-- Creates a more intuitive payment experience that mirrors traditional payment flows
+This flow:
+- Allows the customer to specify which asset they'll use for payment (when multiple supportedAssets are available)
+- Enables the merchant to provide the settlement address after knowing which asset will be used
+- Creates a clear authorization chain before on-chain settlement
+- Mirrors traditional payment authorization flows
 
 ### Authorization with Travel Rule Information
 

messages.md

@@ -88,6 +88,7 @@ Initiates a virtual asset transfer between parties.
 | purpose | string | No | Draft ([TAIP-13]) | ISO 20022 purpose code indicating the reason for the transfer |
 | categoryPurpose | string | No | Draft ([TAIP-13]) | ISO 20022 category purpose code for high-level classification |
 | expiry | string | No | Review ([TAIP-3]) | ISO 8601 datetime indicating when the transfer request expires |
+| policies | array of [Policy](#policy) | No | Review ([TAIP-3]) | Array of policy objects defining requirements for the transaction |
 
 #### Examples
 
@@ -178,6 +179,7 @@ Initiates a payment request from a merchant to a customer.
 | merchant | [Party](#party) | Yes | Review ([TAIP-14]) | Party for the merchant (beneficiary) |
 | customer | [Party](#party) | No | Review ([TAIP-14]) | Party for the customer (originator) |
 | agents | array of [Agent](#agent) | Yes | Review ([TAIP-14]) | Array of agents involved in the payment request |
+| policies | array of [Policy](#policy) | No | Review ([TAIP-14]) | Array of policy objects defining requirements that must be satisfied by the customer's agent |
 
 #### Examples
 
@@ -391,6 +393,7 @@ Terminates an existing transaction or connection. When used with transactions, i
 |-----------|------|----------|---------|-------------|
 | @context | string | Yes | Review ([TAIP-4]) | JSON-LD context "https://tap.rsvp/schema/1.0" |
 | @type | string | Yes | Review ([TAIP-4]) | JSON-LD type "https://tap.rsvp/schema/1.0#Cancel" |
+| by | string | Yes | Review ([TAIP-4]) | The party of the transaction wishing to cancel it (e.g., "originator" or "beneficiary" for Transfer messages) |
 | reason | string | No | Review ([TAIP-4]) | Human readable reason for cancellation |
 
 #### Example Cancel Message
@@ -405,6 +408,7 @@ Terminates an existing transaction or connection. When used with transactions, i
   "body": {
     "@context": "https://tap.rsvp/schema/1.0",
     "@type": "https://tap.rsvp/schema/1.0#Cancel",
+    "by": "originator",
     "reason": "user_requested"
   }
 }
@@ -1067,6 +1071,7 @@ Terminates an existing connection.
 |-----------|------|----------|---------|-------------|
 | @context | string | Yes | Draft ([TAIP-4]) | JSON-LD context "https://tap.rsvp/schema/1.0" |
 | @type | string | Yes | Draft ([TAIP-4]) | JSON-LD type "https://tap.rsvp/schema/1.0#Cancel" |
+| by | string | Yes | Draft ([TAIP-4]) | The party of the transaction wishing to cancel it (e.g., "originator" or "beneficiary" for Transfer messages) |
 | reason | string | No | Draft ([TAIP-4]) | Human readable reason for cancellation |
 
 #### Example Cancel Message
@@ -1080,6 +1085,7 @@ Terminates an existing connection.
   "body": {
     "@context": "https://tap.rsvp/schema/1.0",
     "@type": "https://tap.rsvp/schema/1.0#Cancel",
+    "by": "customer",
     "reason": "User declined payment request"
   }
 }
@@ -1342,6 +1348,55 @@ Represents a service involved in executing transactions.
 }
 ```
 
+## Out-of-Band Message Initiation
+
+### Overview
+[TAIP-3], [TAIP-14] - Review
+
+When parties haven't established communication, TAP messages can be initiated using DIDComm Out-of-Band (OOB) messages. This enables sharing transaction requests through URLs or QR codes.
+
+### Requirements
+
+1. MUST use the `https://didcomm.org/out-of-band/2.0` protocol
+2. MUST include the appropriate goal_code:
+   - `tap.transfer` for Transfer messages
+   - `tap.payment` for Payment messages
+3. SHOULD be shared as URLs according to the [Out-of-Band message spec](https://identity.foundation/didcomm-messaging/spec/v2.1/#out-of-band-messages)
+4. MUST include the TAP message as a signed DIDComm message in the attachment
+
+### Example Out-of-Band Transfer
+
+```json
+{
+  "type": "https://didcomm.org/out-of-band/2.0/invitation",
+  "id": "2e9e257c-2839-4fae-b0c4-dcd4e2159f4e",
+  "from": "did:example:originator",
+  "body": {
+    "goal_code": "tap.transfer",
+    "goal": "Process transfer request",
+    "accept": ["didcomm/v2"]
+  },
+  "attachments": [{
+    "id": "transfer-1",
+    "mime_type": "application/didcomm-signed+json",
+    "data": {
+      "json": {
+        "payload": "eyJpZCI6IjU5OWY3MjIwLTYxNDktNGM0NS1hZGJiLTg2ZDk2YzhlMDYwOCIsInR5cGUiOiJodHRwczovL3RhcC5yc3ZwL3NjaGVtYS8xLjAjVHJhbnNmZXIiLCJmcm9tIjoiZGlkOmV4YW1wbGU6b3JpZ2luYXRvciIsImJvZHkiOnsiQGNvbnRleHQiOiJodHRwczovL3RhcC5yc3ZwL3NjaGVtYS8xLjAiLCJAdHlwZSI6Imh0dHBzOi8vdGFwLnJzdnAvc2NoZW1hLzEuMCNUcmFuc2ZlciIsImFzc2V0IjoiZWlwMTU1OjEvc2xpcDQ0OjYwIiwiYW1vdW50IjoiMTAwLjAwIn19",
+        "signatures": [{
+          "protected": "eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSIsImtpZCI6ImRpZDpleGFtcGxlOm9yaWdpbmF0b3Ija2V5LTEifQ",
+          "signature": "FW33NnvOHV0Ted9-F7GZbkia-vYAfBKtH4oBxbrttWAhBZ6UFJMxcGjL3lwOl4YohI3kyyd2LqvFHsEFk7R7Cg"
+        }]
+      }
+    }
+  }]
+}
+```
+
+The corresponding URL format would be:
+```
+https://example.com/tap?_oob=eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSJ9...
+```
+
 ## Message Flow Examples
 
 ### Basic Transfer Flow
@@ -1719,6 +1774,7 @@ Note that all messages in this flow share the same thread ID (`payment-123`) to
   "body": {
     "@context": "https://tap.rsvp/schema/1.0",
     "@type": "https://tap.rsvp/schema/1.0#Cancel",
+    "by": "customer",
     "reason": "User declined payment request"
   }
 }
@@ -1738,6 +1794,7 @@ Note that all messages in this flow share the same thread ID (`payment-123`) to
   "body": {
     "@context": "https://tap.rsvp/schema/1.0",
     "@type": "https://tap.rsvp/schema/1.0#Cancel",
+    "by": "originator",
     "reason": "User cancelled the request"
   }
 }
@@ -1755,6 +1812,7 @@ Note that all messages in this flow share the same thread ID (`payment-123`) to
   "body": {
     "@context": "https://tap.rsvp/schema/1.0",
     "@type": "https://tap.rsvp/schema/1.0#Cancel",
+    "by": "originator",
     "reason": "Service agreement terminated"
   }
 }

transactions.md

@@ -43,17 +43,9 @@ The **Payment** message type extends TAP to support merchant payment scenarios w
 - **Enhanced Metadata**: Supports additional information like invoices, items, and payment terms
 - **Customer Experience Focus**: Designed for consumer-friendly payment flows with clear merchant identification
 - **Merchant Classification**: Supports ISO 18245 Merchant Category Codes (MCC) for business type identification (e.g., restaurants, grocery stores)
-- **Flexible Settlement**: Supports optional partial payments through the **Complete** message, allowing merchants to adjust final amounts
+- **Flexible Settlement**: Supports flexible asset selection through the `supportedAssets` field, allowing customers to choose their preferred payment method
 - **Invoice Support**: Includes comprehensive invoice functionality as defined in [TAIP-16](/TAIPs/taip-16.md), supporting detailed line items, tax information, and payment terms
-
-### Complete Message
-
-The **Complete** message is a crucial part of the Payment flow, sent by the merchant's agent to indicate that the transaction is ready for settlement:
-
-- **Settlement Readiness**: Clearly signals that the merchant has finished all necessary checks and is ready to receive payment
-- **Address Provision**: Provides the blockchain address where funds should be sent
-- **Optional Amount Adjustment**: Allows merchants to specify a final amount (which must be less than or equal to the original requested amount), enabling scenarios like partial fulfillment or applied discounts
-- **Settlement Guidance**: When an amount is specified in the Complete message, the customer's agent must use that exact amount in the subsequent Settle message. If omitted, the full amount from the original Payment message is implied
+- **Policy Support**: Can include policy requirements (e.g., RequirePresentation) for customer information needed for the transaction
 
 ## Business Differences