**Session Date/Time:** 28 May 2024 14:00

# [SATP](../wg/satp.html)

## Summary

This interim meeting of the Secure Asset Transfer Protocol (SATP) Working Group focused primarily on the architecture document, particularly a detailed discussion on the terminology used to describe a Gateway's interaction with an asset during transfer. There was a general consensus to adopt "control" over "own" or similar terms. The meeting also touched upon the status of the core protocol document and the process for handling pull requests and issues. A follow-up interim meeting was proposed to address outstanding changes to the core document.

## Key Discussion Points

### Welcome and Logistics

*   The chairs welcomed attendees and reviewed the IETF Note Well, emphasizing policies on patents and the code of conduct.
*   The meeting agenda included introductions, announcements, discussion of the architecture document, and the core document.
*   **Announcements**: Orie Steel was announced as the new Area Director, expressing interest in SATP work.
*   **IETF Process Reminders**: Discussions and decisions must occur on the mailing list or official public venues (including GitHub tickets/PRs linked to mailing list notices), not in side discussions. Agendas for meetings should be posted two weeks in advance.

### SATP Scope Review

*   The working group's scope is strictly the **asset network-to-network transfer**.
*   **Out of scope**: How a network guarantees its ability to perform a transaction (e.g., legal agreements for asset holding/locking). However, requirements for what an asset network *must* have (e.g., ability to ensure transaction completion) are in scope.
*   **Key points reiterated**:
    *   The protocol is designed for **omnidirectional transfer** (Network A to B, but unidirectional for version 1).
    *   It must be **agnostic to the underlying network technology** (e.g., not exclusively for blockchains, but also public and private ledgers, legacy systems).
    *   The yellow box in the scope diagram represents the in-scope interaction between two gateways bounding the network.
    *   Initial versions assume a **pre-existing legal relationship** between participating networks to establish trust.

### Architecture Document Discussion

*   **Status Update**: Thomas indicated the architecture document is largely ready for a Last Call, with two main outstanding points.
*   **Threat Analysis (Appendix A)**: Acknowledged that a future, dedicated document on threat analysis for the protocol might be beneficial for implementers, rather than expanding Appendix A significantly.
*   **Gateway Control/Ownership Terminology (Section 3.3)**:
    *   The term "own" for a Gateway's relationship to an asset during transfer was questioned by Anthony due to its legal connotations and potential for misinterpretation in a technical document.
    *   **Anthony's argument**: The Gateway could function more as a technical construct that passes signed assertions from the actual asset holder (e.g., a bank) rather than itself taking ownership or primary liability. He drew an analogy to SMTP, where the message handler isn't liable for message content.
    *   **Thomas's counter**: SATP involves state changes (burn and mint model) and implies a greater degree of responsibility than simple message passing. The Gateway operator (or the entity behind it) is financially and legally liable for the asset's state during transfer. Contracts would exist between the Gateway provider and the asset owner.
    *   **Claire's clarification**: The architecture assumes the Gateway is responsible for "locking" or "disabling" the asset in the origin network. How this is *proven* internally is out of scope. The initial version assumes a legal relationship between networks to trust that this disablement has occurred.
    *   **Rama's suggestion**: Soften "control" to "limited control" or "control subject to constraints."
    *   **Martin's input**: In systems like Swift, gateways are operated by members, and liability traces back to those members, not the network. This aligns with gateways being in control.
    *   **Proposed alternatives**: "Control," "assert," "demonstrate control." The term "demonstrate control" was considered too broad and potentially out of scope as it implies *proving* control in technically diverse ways, which is outside the protocol's current remit.
    *   **Sense of the room**: There was a general sense that "control" is a more appropriate and less legally loaded term than "own" for describing the Gateway's role during asset transfer. The specific wording would be refined on the mailing list.

### Core Document Discussion

*   **Editor Subgroup Proposal**: Thomas inquired about forming an editor subgroup to review GitHub issues and pull requests for the core document.
*   **Chairs' Guidance on Process**:
    *   Editors are responsible for applying editorial changes reflecting working group consensus.
    *   Substantial changes require discussion on the mailing list to establish consensus.
    *   GitHub issues and pull requests are valid venues for discussion, but contributors and editors should ensure significant discussions and resolutions are cross-posted or summarized on the mailing list to ensure broad visibility and participation. Tools can automate mailing list notifications for GitHub activity.
    *   Any individual is welcome to submit pull requests, but acceptance depends on WG consensus.
*   **Need for further discussion**: Several pull requests with potentially significant changes to the core document remain open and require thorough review.

## Decisions and Action Items

*   **Architecture Document Terminology**: The working group agreed that "control" is a more appropriate term than "own" (or similar) to describe the Gateway's role in relation to an asset during transfer.
    *   **Action**: Thomas (Editor) to propose specific wording changes in Section 3.3 (and potentially other sections) to replace "own" with "control" on the mailing list for final review and consensus.
    *   **Action**: Once this change is resolved and David's comments on Appendix A are addressed, the architecture document will proceed to Working Group Last Call.

*   **Core Document Review**: Given the number of open pull requests and the complexity of proposed changes, a dedicated interim meeting is needed.
    *   **Action**: Anthony to summarize the content of outstanding pull requests/issues on the mailing list to prepare the working group for discussion.
    *   **Action**: Chairs to schedule another interim meeting on or around **June 18th** (tentative, same time slot if available) to specifically discuss proposed changes and outstanding issues for the core document.
    *   **Action**: Editors of the core document to prepare a summary of discussion points and reading materials for the next interim meeting to facilitate focused discussion.
    *   **Action**: All contributors are encouraged to post notices or summaries to the mailing list for any active technical discussions occurring on GitHub issues or pull requests that might lead to significant changes in the documents.

## Next Steps

*   Thomas will circulate the proposed wording for the architecture document on the mailing list for final consensus, targeting Working Group Last Call soon thereafter.
*   Chairs will schedule an interim meeting for June 18th to discuss the core document.
*   Editors and contributors will prepare summaries of pull requests/issues for the core document and ensure mailing list visibility for GitHub discussions.