Internet Engineering Task Force                              T. HardjonoInternet-Draft                                                       MITIntended status: Informational                             M. HargreavesExpires: 10 December 2024                                  Quant Network                                                                N. Smith                                                                   Intel                                                          V. Ramakrishna                                                                     IBM                                                             8 June 2024       Secure Asset Transfer (SAT) Interoperability Architecture                    draft-ietf-satp-architecture-04Abstract   This document proposes an interoperability architecture for the   secure transfer of assets between two networks or systems based on   the gateway model.Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions of BCP 78 and BCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is at https://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on 10 December 2024.Copyright Notice   Copyright (c) 2024 IETF Trust and the persons identified as the   document authors.  All rights reserved.Hardjono, et al.        Expires 10 December 2024                [Page 1]Internet-Draft              SAT Architecture                   June 2024   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents (https://trustee.ietf.org/   license-info) in effect on the date of publication of this document.   Please review these documents carefully, as they describe your rights   and restrictions with respect to this document.  Code Components   extracted from this document must include Revised BSD License text as   described in Section 4.e of the Trust Legal Provisions and are   provided without warranty as described in the Revised BSD License.Table of Contents   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   3.  Assumptions and Principles  . . . . . . . . . . . . . . . . .   5     3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   5     3.2.  Operational Assumptions . . . . . . . . . . . . . . . . .   5     3.3.  Assumptions Regarding Gateway Operators . . . . . . . . .   6   4.  Gateway Interoperability Modes  . . . . . . . . . . . . . . .   7   5.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   7     5.1.  Goal of Architecture  . . . . . . . . . . . . . . . . . .   7     5.2.  Overview of Asset Transfer  . . . . . . . . . . . . . . .   8     5.3.  Desirable Properties of Asset Transfer  . . . . . . . . .   9     5.4.  Event log-data, crash recovery and backup gateways  . . .  11     5.5.  Overview of the Stages in Asset Transfer  . . . . . . . .  11   6.  Pre-transfer Verification and Context Establishment           (Stage-0) . . . . . . . . . . . . . . . . . . . . . . . .  13   7.  Transfer Initiation and Commencement (Stage-1)  . . . . . . .  15   8.  Asset Lock Assertion and Receipt (Stage 2)  . . . . . . . . .  16   9.  Commitment Preparation and Finalization (Stage 3) . . . . . .  18   10. The Commitment sub-protocol . . . . . . . . . . . . . . . . .  20   11. Security Considerations . . . . . . . . . . . . . . . . . . .  21   12. Policy Considerations . . . . . . . . . . . . . . . . . . . .  21   13. Threat Analysis Considerations  . . . . . . . . . . . . . . .  22     13.1.  Multiple intentional aborts by the sender gateway  . . .  22     13.2.  Multiple intentional aborts by the receiver gateway  . .  22     13.3.  Failure to transmit ACK-Final Receipt  . . . . . . . . .  23     13.4.  Failure to extinguish asset  . . . . . . . . . . . . . .  23     13.5.  Identity impersonations  . . . . . . . . . . . . . . . .  23   14. Compatibility Considerations  . . . . . . . . . . . . . . . .  24   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24     15.1.  Normative References . . . . . . . . . . . . . . . . . .  24     15.2.  Informative References . . . . . . . . . . . . . . . . .  24   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26Hardjono, et al.        Expires 10 December 2024                [Page 2]Internet-Draft              SAT Architecture                   June 20241.  Introduction   This document proposes an interoperability architecture based on   gateways, which are points of interconnection between networks or   systems.   There are several services that may be offered by a gateway, one of   which being the direct transfer of a digital asset from one network   to another via pairs of gateways without a mediating third party.   A given network or system may have one or more gateways to perform a   unidirectional direct transfer of digital assets to another network   possessing one or more compatible gateway.   The peer gateways must implement a secure asset transfer protocol   that must satisfy certain security, privacy, atomicity and liveliness   requirements.   The purpose of this architecture document is to provide technical   framework within which to define the required properties of a gateway   that supports the secure asset transfer protocol.2.  Terminology   The current architcture specification borrows existing terminology   from NIST and ISO.  New terms have been introduced notably in   relation to the use of the gateways paradigm and commitment   subprotocols.   *  Asset network (system): The network or system where a digital      asset is utilized.   *  Asset Transfer Protocol: The protocol used to transfer (move) a      digital asset from one network to another using gateways.   *  Origin network: The current network where the digital asset is      located.   *  Destination network: The network to which a digital asset is to be      transferred.   *  Resource Domain: The collection of resources and entities      participating within an asset network.  The domain denotes a      boundary for permissible or authorized actions on resources.   *  Interior Resources: The various interior protocols, data      structures and cryptographic constructs that are a core part of an      asset network or system.Hardjono, et al.        Expires 10 December 2024                [Page 3]Internet-Draft              SAT Architecture                   June 2024   *  Exterior Resources: The various protocols, data structures and      cryptographic constructs that are outside of (external to) the      network or system.   *  Gateway: The collection of services which connects to a minimum of      one network or system, and which implements the secure asset      transfer protocol.   *  Entity public-key pair: This the private-public key pairs of an      entity, where the public-key is available and verifiable outside      the network.  Among others, it may be utilized for interactions      other entities (e.g. sign messages) from outside the network.  The      term is used to distinguish this public-key from other key-pairs      belonging to the same entity, but which is only available within      the (private) network.   *  Originator: Person or organization in an origin network seeking      the transfer of a digital asset to a beneficiary located in a      remote network.   *  Beneficiary: Person or organization in an destination network      seeking to receive the transfer of a digital asset to from an      originator located in a remote network.   *  Gateway device identity: The identity of the device implementing      the gateway functions.  The term is used in the sense of the DevID      (IEEE 802.1AR) [DevID] or the EK/AIK keys (in TPM1.2 and TPM2.0)      [TPMdevID].   *  Gateway owner: The entity that owns and operates a gateway within      a network.   *  Application Context-ID: The relevant identifier used by      originator's application and the beneficiary's application to      identify the context of the asset transfer at the gateway level.      The context identifier may also be used to bind the application to      selected gateway for the given transfer instance, identified by a      Session-ID.   *  Gateway Session-ID: This is the identifier used between the sender      gateway G1 and the recipient gateway G2 to identify the specific      transfer instance between them.  The Session-ID must be included      in all messages between the peer gateways.Hardjono, et al.        Expires 10 December 2024                [Page 4]Internet-Draft              SAT Architecture                   June 20243.  Assumptions and Principles   The following assumptions and principles underlie the design of the   current gateway architecture, and correspond to the design principles   of the Internet architecture.3.1.  Design Principles   *  Opaque network resources: The interior resources of each network      is assumed to be opaque to (hidden from) external entities.  Any      resources to be made accessible to an external entity must be made      explicitly accessible by a gateway with proper authorization.   *  Externalization of value: The asset transfer protocol is agnostic      (oblivious) to the economic or monetary value (if any) of the      digital asset being transferred.   The opaque resources principle permits the architecture to be applied   in cases where one (or both) networks are private (closed   membership).  It is the analog of the autonomous systems principle in   IP networking [Clar88], where interior routes in local subnets are   not visible to other external networks.   The value-externalization principle permits an asset transfer   protocol to be designed for efficiency, security and reliability --   independent of the changes in the perceived economic value of the   digital asset.  It is the analog of the end-to-end principle in the   Internet architecture [SRC84], where contextual information is placed   at the endpoints of the transfer.3.2.  Operational Assumptions   The following conditions are assumed to have occurred, leading to the   invocation of the asset transfer protocol between two gateways:   *  Application level context establishment: The transfer request from      an Originator utilizing an application (App1) in the origin      network is assumed to have occurred, and that some context-      identifier has subsequently been derived by the respective      applications (App1 and App2).  Furthermore, this context-      identifier is assumed to have been delivered by the each      application to its corresponding gateway, permiting each gateway      to internally bind the transfer session-identifier to that      context-identifier.   *  Identification of asset to be transferred: The applications at the      originator and the beneficiary are assumed to have identified the      digital asset to be transferred.Hardjono, et al.        Expires 10 December 2024                [Page 5]Internet-Draft              SAT Architecture                   June 2024   *  Identification of originator and beneficiary: The originator and      beneficiary are assumed to have been identified and that consent      has been obtained from both parties regarding the asset transfer.   *  Identification of origin and destination asset networks: The      origin and destination networks is assumed to have been      identified.   *  Selection of gateway: The two corresponding gateways at the origin      and destination networks is assumed to have been identified and      selected.3.3.  Assumptions Regarding Gateway Operators   The following conditions are assumed to have occurred, leading to the   invocation of the asset transfer protocol between two gateways:   *  Identification of gateway-owners: The owners of the two      corresponding gateways are assumed to have been identified and      their ownership status verified.   *  Gateway liabilities: Gateways and gateway-operators are assumed to      take on legal and financial liability for their transactions, and      gateways are assumed to operate under a well-defined legal      framework (e.g. contractual relationship).  Furthermore, the legal      framework is assumed to be supported by compatible legislation in      the relevant jurisdictions where the gateways are operating.   *  Gateway message signatures: All messages between gateways are      assumed to be signed and verified (e.g.  X.509).   *  Transitory control of asset by gateway: An asset being transferred      via SAT will technically be controlled by gateway throughout the      transfer duration to ensure the state of the asset is not modified      by another entity.  Gateway owners are liable for the asset      throughout this duration.   *  Network data: Gateways are assumed to have mechanisms in place to      trust data returned from their local networks.  This will depend      on the technical architecture and capabilities of each specific      network.   *  Gateways are trusted: The gateways are assumed to be trusted to      carry-out all the stages of the protocol described in this      architecture.Hardjono, et al.        Expires 10 December 2024                [Page 6]Internet-Draft              SAT Architecture                   June 20244.  Gateway Interoperability Modes   The current interoperability architecture based on gateways   recognizes several types of transfer flows:   *  Asset transfer: This refers to the transfer of a digital asset      from the origin network to a destination network, where a      successful asset transfer causes the asset to be extinguished      (burned) in the origin network and be regenerated (minted) at the      destination network.   *  Data transfer: This refers to the transfer of data only under      authorization, in such a way that the data can be verified by a      third party.  The data transfer mode addresses the use-cases where      the state update in one network or system depends on the existence      of state information recorded in a different network or system.   *  Asset exchange (swap): This refers to the case where two users are      present in two networks, and they perform concurrent and atomic      swaps of two assets in the two corresponding networks, without      transferring the assets outside (i.e. across) the networks.  The      gateways aid in coordinating the messages pertaining to the swap.   The remainder of this architecture document will focus on the asset   transfer flows.5.  Architecture5.1.  Goal of Architecture   The goal of the interoperability architecture is to permit two (2)   gateways belonging to distinct networks to conduct a transfer of   digital assets transfer between them, in a secure, atomic and   verifiable manner.   The asset as understood by the two gateways is expressed in an   standard digital format in a way meaningful to the gateway   syntactically and semantically.   The architecture recognizes that there are different networks   currently in operation and evolving, and that in many cases the   interior technical constructs in these networks maybe incompatible   with one another.   The architecture therefore assumes that in addition to implementing   the bilateral secure asset transfer protocol, a gateway has the role   of making opaque (i.e. hiding) the constructs that are local and   specific to its network.Hardjono, et al.        Expires 10 December 2024                [Page 7]Internet-Draft              SAT Architecture                   June 2024   Overall this approach ensures a high degree of interoperability   across these networks, where each network can operate as a true   autonomous system.  Additionally, this approach permits each network   to evolve its interior technology implementations without affecting   other (external) networks.   The current architecture focuses on unidirectional asset transfers,   although the building blocks in this architecture can be used to   support protocols for bidirectional transfers.   For simplicity the current architecture employs two (2) gateways per   transfer as the basic building block, with one gateway in the origin   and destination networks respectively.  However, the architecture   seeks to be extensible to address future cases involving multiple   gateways at both sides.   The abstract construct of the gateway is used to represent endpoints   that implement the asset transfer protocol interactions and the   business logic that coordinates the transfer protocol steps until   completion satisfying the ACID properties and ensuring liveliness of   the protocol interactions.  In classical distributed databases, this   business logic is often referred to as the transaction manager or the   transaction coordinator.  This architecture specification does not   prescribe any implementations of gateways.5.2.  Overview of Asset Transfer   An asset transfer between two networks is performed using a secure   asset transfer protocol implemented by the gateways in the respective   networks.  The two gateways implement the protocol in a direct   interaction (unmediated).   A successful transfer results in the asset being extinguished   (burned) at the origin network, and for the asset to be regenerated   (minted) at the destination network.   The secure asset transfer protocol provides a coordination between   the two gateways through the various message flows in the protocol   that is communicated over a secure channel.   The protocol implements a commitment mechanism between the two   gateways to ensure that the relevant properties atomicity,   consistency, isolation, and durability (ACID) are achieved in the   transfer.   The mechanism to extinguish (burn) or regenerate (mint) an asset   from/into a network by its gateway is dependent on the specific   network and is outside the scope of the current architectureHardjono, et al.        Expires 10 December 2024                [Page 8]Internet-Draft              SAT Architecture                   June 2024   specification.  The mechanisms used to provide cryptographic proofs   that an asset has been burned or minted in a given network is also   out of scope.   As part of the commitment mechanism, the sender gateway in the origin   network must deliver a signed assertion to the receiver gateway at   the destination network which states that asset in question has been   extinguished (burned) from the origin network.   Similarly, the receiver gateway at the destination network must in   return deliver a signed assertion to the sender gateway at the origin   network which states that the asset has been regenerated (minted) in   the destination network.   These two tasks must be performed in a synchronized fashion between   the two gateways, and the commitment mechanism must provide   sufficient evidence of the asset transfer that is verifiable by an   authorized third party.5.3.  Desirable Properties of Asset Transfer   The desirable features of asset transfers between two gateways   include, but not limited, to the following:   *  Atomicity: A transfer must either commit or entirely fail (failure      means no change to asset state).   *  Consistency: A transfer (commit or fail) always leaves the      networks in a consistent state (i.e. the asset is located in one      network only at any time).   *  Isolation: While the transfer is occurring, the asset state cannot      be modified in the origin network.   *  Durability: Once a transfer has been committed by both gateways,      it must remain so regardless of subsequent gateway crashes.   *  Liveliness and safety: The asset transfer protocol results in both      gateways reaching a non-blocking state (commits or aborts)      satisfying the above ACID properties.   *  Verifiable by authorized third parties: The proof that the asset      has been extinguished in the origin network, and the proof that      the asset has been generated in the destination network must be      verifiable by an authorized third party.Hardjono, et al.        Expires 10 December 2024                [Page 9]Internet-Draft              SAT Architecture                   June 2024   An implementation of the asset transfer protocol should satisfy these   properties, independent of whether the implementation employs   stateful messaging or stateless messaging between the two gateways.   Performing an asset transfer safely and securely is not simply a   matter of communicating desire or intent between two systems   represented by gateways, though such communication is a necessary   part of asset transfer.  The systems, or at least their gateway   proxies, must be interoperable in order to transfer assets among   themselves, but such interoperability imposes strictly more demands   on systems managing digital assets, especially systems that are built   on distributed ledgers, compared to conventional communication   interoperability.   Communication interoperability, which is concerned with syntax and   semantics of information geared towards producing a common   understanding (or knowledge reconciliation) among systems, is   insufficient to fulfill an asset transfer that requires systems to   carry out state updates in concert with each other.  But   communication, or messaging standards, play a necessary and   complementary role to asset transfer protocols.  An exemplar of this   is ISO 20022, which is a comprehensive global standard for financial   messaging that specifies message syntax for common actions occurring   in financial business processes, including payments, credit card   transactions, securities settlements, funds, and trade [ISO20022].   This standard provides the tools to model business processes from   basic logical building blocks and schemas to construct messages using   common formats like XML, JSON, and ASN.1.   As discussed later, such messaging standards are useful to   communicate information about the states of processes and digital   assets across systems, to make requests, and to convey intent.  They   therefore play a necessary and complementary role in asset transfer   protocols.  However they are by themselves insufficient to ensure the   ACID and verifiability properties described earlier.  Another way to   think about the relationship between messaging standards like ISO   20022 and asset transfer protocols is that the former is concerned   with the "what" of cross-system interoperability whereas the latter   is concerned with the "how".  Both kinds of protocols treat systems   as black boxes, but asset transfer protocols must place some   responsibility, and depend, on systems to drive a protocol instance   to successful conclusion.Hardjono, et al.        Expires 10 December 2024               [Page 10]Internet-Draft              SAT Architecture                   June 20245.4.  Event log-data, crash recovery and backup gateways   Implementations of a gateway should maintain event logs and   checkpoints for the purpose of gateway crash recovery.  The log-data   generated by a gateway should be considered as an interior resource   accessible to other authorized gateways within the same network.   The mechanism used to provide gateway crash-recovery is dependent on   the specific network.  For interoperability purposes the information   contained in the log and the format of the log-data should be   standardized.   The resumption of an interrupted transfer session (e.g. due to   gateway crash, network failure, etc.) should take into consideration   the aspects of secure channel establishment and the aspects of the   transfer protocol resumption.  In some cases, a new secure channel   (e.g.  TLS session) may need to be established between the two   gateways, before a resumption of the transfer can begin.   The log-data collected by a gateway acts also as a checkpoint   mechanism to assist the recovered (or backup) gateway in continuing   the transfer.  The point at which to re-start the transfer protocol   flow is dependent on the implementation of the gateway recovery   strategy.5.5.  Overview of the Stages in Asset Transfer   The interaction between two gateways in the secure asset transfer   protocol is summarized in Figure 1, where the origin network is NW1   and the destination network is NW2.  The gateways are denoted as G1   and G2 respectively.Hardjono, et al.        Expires 10 December 2024               [Page 11]Internet-Draft              SAT Architecture                   June 2024            Originator                                   Beneficiary                |                                             |         +-------------+                               +-------------+         |   Client    |                               |   Client    |         | Application |                               | Application |         |    (App1)   |                               |    (App2)   |         +-------------+                               +-------------+                |                                             |                |                                             |                |              |<--(Stage 0)-->|              |                V              |               |              V         +-------------+       |               |       -------------+         |    Network  |  +----+<-- Stage 1 -->+----+  |   Network   |         |     NW1     |  |Gate|               |Gate|  |     NW2     |         |             |--|way |               |way |--|             |         | +---------+ |  | G1 |<-- Stage 2 -->| G2 |  | +---------+ |         | |  State  | |  +----+               +----+  | |   State | |         | | Data DB1| |       |               |     | | Data DB2| |         | +---------+ |       |<-- Stage 3--->|       | +---------+ |         +-------------+                               +-------------+                                  Figure 1   The stages are summarized as follows.   *  Stage 0: Pre-transfer Verification and Context Establishment.  The      two applications utilized by the originator and beneficiary are      assumed to interact as part of the asset transfer.  In this stage,      the applications App1 and App2 may establish some shared transfer      context information (e.g.  Context-ID) at the application level      that will be made available to their respective gateways G1 and      G2.  The legal verification of the identities of the Originator      and Beneficiary may occur in this stages [FATF].  This stage is      outside the scope of the current architecture specification.   *  Stage 1: Transfer Initiation and Commencement.  In this stage      gateways G1 and G2 must exchange information (claims) regarding      the asset to be transferred, the identity information of the      Originator and Beneficiary and other information regarding      relevant actors (e.g. gateway owner/operator).  The main task in      this stage is for both gateways to finalize the parameters      previously negotiated in Stage 0 and to agree to commence the      transfer.   *  Stage 2: Lock Assertion and Receipt.  In this stage, gateway G1      must provide gateway G2 with a signed assertion that the asset in      NW1 has been immobilized and under the control on G1.  A signedHardjono, et al.        Expires 10 December 2024               [Page 12]Internet-Draft              SAT Architecture                   June 2024      assertion is needed because NW1 may be a private or closed      network, and therefore the state-database (ledger) in NW1 is not      readable by external entities including by G2.  This means that      gateway G1 must make an explicit signed assertion about the state      in NW1.  Note that the owner/operator of G1 takes on liability in      signing this assertion.   *  Stage 3: Commitment Preparation and Finalization.  In this stage      gateways G1 and G2 commit to the unidirectional asset transfer      using a 3PC (3-phase commit) subprotocol.   These stages will be further discussed below.6.  Pre-transfer Verification and Context Establishment (Stage-0)   Although Stage 0 is out of scope for the current architecture, it is   discussed here in order to provide background with the regards to the   various asset verification requirements prior to commencing the   transfer in Stage 1.   Several tasks need to be conducted as part of the pre-transfer:   *  Application level ContextID establishment: The application (App1)      used by the originator and the application (App2) used by the      beneficiary may need to establish a transfer context identifier      (contextID) to uniquely identity the transfer at the application      level.   *  Identification of the asset in the origin network: The specific      asset in the origin network NW1 must be located and identified,      and its legal ownership be verified by gateway G1.  A gateway      should not transfer assets whose ownership is unverified.  An      asset may be identified by way of a combination of the network-      identifier and a cryptographic hash of the ledger data      representing the asset.  Other syntax may also be used, such as      [ISO20022] or ITIN [ITIN].   *  Verification of the class or type of asset: The receiving gateway      G2 may need to verify the class or type of asset that is to be      transferred by gateway G1 in network NW1.  This is to ensure that      the asset type/class conforms to the governing policies in the      destination network NW2.  Additionally, gateway G2 must ensure      that network NW2 can technologically receive (mint) the asset of      that given type/class.  Asset schema definitons and asset profiles      may assist in this vertification process.Hardjono, et al.        Expires 10 December 2024               [Page 13]Internet-Draft              SAT Architecture                   June 2024   *  Validation of asset ownership status: The gateway G1 in the origin      network NW1 must ensure that an asset to be transferred to an      external network is legally owned by the originator who is      requesting the transfer.   *  Authorization to transfer: The gateway G1 must obtain      authorization from the owner of the asset (originator) to perform      the transfer to the beneficiary in network NW2.  Similarly, the      gateway G2 serving network NW2 must obtain authorization from the      beneficiary to receive the transfer and assign the asset to the      beneficiary in NW2.   *  Exchange of Travel Rule information and validation: In      jurisdictions where the Travel Rule policies regarding originator      and beneficiary information is enforced [FATF], the owners of      gateways G1 and G2 must comply to the Travel Rule.  Mechanisms      must be used to permit gateways G1 and G2 to make available      originator/beneficiary information to one another in such a away      that the Travel Rule information can be logged as part of the      asset transfer history.   *  Validation of the gateway ownership: There must be a means for      gateway G1 and G2 to verify their respective ownerships (i.e.      entities owning G1 and G2 respectively).  Examples of ownership      verification mechanism include X.509 certificates, directories of      gateways and owners, and others.   *  Mutual device attestations: In cases where device attestation      [RATS] is required, each gateway must yield attestation evidence      to the other regarding its configuration.  A gateway may take on      the role as a attestation verifier, or it may rely on an external      verifier to appraise the received evidence.   *  Negotiation of transfer protocol and network parameters: Gateway      G1 and G2 must agree on the parameters to be employed within the      asset transfer protocol.  Examples include endpoints definitions      for resources, duration of time-outs of messages, type of      commitment flows (e.g. 2PC or 3PC), signature algorithms, average      lock-time durations in their respective networks, and others.   The current specification seeks to reuse as much as possible the   existing standards related to digital assets.  We seek to rely on   existing messaging standards like ISO 20022 [ISO20022] or ITIN [ITIN]   for gateway ownership validation, owner status validation, asset   profile identification, and communication of travel rule and transfer   context information.  For identification of digital assets maintained   by distributed ledgers or blockchain systems, we can also rely on   standards like ITIN [ITIN].Hardjono, et al.        Expires 10 December 2024               [Page 14]Internet-Draft              SAT Architecture                   June 20247.  Transfer Initiation and Commencement (Stage-1)   In Stage 1 the sender gateway (G1) and the receiver gateway (G2) must   explicitly accept the parameters of the transfer which were   negotiated in the pre-transfer stage (Stage 0).   This explicit acceptance of the parameters takes the form of gateway   G1 sending a signed Transfer Proposal message containing a Transfer   Initiation Claims set (namely the parameters agreed upon in Stage 0),   and for the gateway G2 to respond with a signed Proposal Receipt   message which carries a hash of the proposal message.       App1  DB1          G1                     G2          DB2    App2        |     |            |                      |            |     |        |     |            |      (Stage 0)       |            |     |        |     |            |                      |            |     |        |<------------ (transfer context establishment) ------------>|        |     |            |                      |            |     |        |---request------->|                      |<------request----|        |     |            |                      |            |     |        |     |            |<-Param Negotiation-->|            |     |        |     |            |                      |            |     |      ..|.....|............|......................|............|.....|..        |     |            |       Stage 1        |            |     |        |     |            |                      |            |     |        |     |       (1.1)|---Transf. Proposal-->|            |     |        |     |            |                      |            |     |        |     |            |                      |            |     |        |     |       (1.2)|<--Proposal Receipt---|            |     |        |     |            |                      |            |     |        |     |            |                      |            |     |        |     |       (1.3)|---Transf. Commence-->|            |     |        |     |            |                      |            |     |        |     |            |                      |            |     |        |     |       (1.4)|<--- ACK Commence ----|            |     |        |     |            |                      |            |     |      ..|.....|............|......................|............|.....|..        |     |            |                      |            |     |                               Figure 2   There are several steps that may occur in Stage 1:Hardjono, et al.        Expires 10 December 2024               [Page 15]Internet-Draft              SAT Architecture                   June 2024   *  Secure channel establishment between G1 and G2: This includes the      mutual verification of the gateway device identities and the      exchange of the relevant parameters for secure channel      establishment.   *  Transfer Proposal message (1.1): Gateway G1 sends a signed      transfer proposal message that contains the Transfer Initiation      Claims to gateway G2.  The claims carry the parameters negotiated      in Stage 0 (pre-transfer negotiations).   *  Proposal Receipt (1.2): The gateway G2 indicates acceptance of the      parameters in the Transfer Initiation Claims by way of sending a      signed Proposal Receipt message to G1.  If gateway G2 decides not      to accept parameters in the Transfer Initiation Claims, then G2      can send an abort message to G1 ignore the message (time-out).   *  Transfer Commence message (1.3): Once gateway G1 receives the      signed Proposal Receipt from gateway G2, gateway G1 is ready to      signal the commencement of the asset transfer.  This is done by      gateway G1 sending a signed Transfer Commence message to G2.   *  Commence Acknowledgement message (1.4): Gateway G2 accepts the      formal commencement of the transfer by responding with a signed      Commence ACK message.   It is important to note the logical separation between the transfer   proposal/receipt messages from the commencement messages.  This   separation allows the gateways to decline to proceed during the   proposal finalization (1.1 and 1.2), prior to starting the 2PC   subprotocol which formally begins at the Commence messages (1.3 and   1.4).   This logical separation is useful because in some implementations the   decision to start the commencement (1.3 and 1.4) implies that the   gateways and network have sufficient resource to complete the   transfer.  Gateways that experience extreme loads may use this   separation to slightly delay the commencement until their loads   subsides.   Note that some implementations may choose to enable a multi-round   interactions for steps 1.1 and 1.2.8.  Asset Lock Assertion and Receipt (Stage 2)   In this stage, gateway G1 must issue a signed assertion that the   asset in origin network NW1 has been immobilized and under the   control of G1.Hardjono, et al.        Expires 10 December 2024               [Page 16]Internet-Draft              SAT Architecture                   June 2024   The steps of Stage 2 are summarized in Figure 4, and broadly consists   of the following:   *  G1 lock/escrow asset (2.1): Gateway G1 proceeds to establish a      lock or escrow the asset belonging to the originator.  This      prevents other local transactions in NW1 from changing the state      of the asset until such time the lock by G1 is finalized or      released.  A time-lock or escrow may also be employed.   *  Lock Assertion (2.2): Gateway G1 sends a digitally signed      assertion regarding the locked (escrowed or immobilized) state on      the asset in network NW1.  The signature by G1 is performed using      its entity public-key pair.  This signature signifies that G1      (i.e. its owner/operator) is legally standing behind its statement      regarding the locked/escrowed state on the asset.  The mechanism      to lock or immobilize the asset is outside the scope of secure      asset transfer protocol.   *  G2 Logs and Broadcasts lock-assertion information (2.3): Gateway      G2 logs a copy of the signed lock-assertion message received in      Step 2.4 to its local state data DB2.  G2 may also broadcast the      fact of the lock-assertion to all members of network NW2.  The      mechanism to log and to broadcast is also out of scope.   *  Lock-Assertion Receipt (2.4): If gateway G2 accepts the signed      assertion from G1, then G2 responds with a digitally signed      receipt message which includes a hash of the previous lock-      assertion message.  The signature by G2 is performed using its      entity public-key pair.  Otherwise, if G2 declines accepting the      assertion then G2 can simply ignore the transfer and let the      session time-out (i.e. transfer attempt has failed).Hardjono, et al.        Expires 10 December 2024               [Page 17]Internet-Draft              SAT Architecture                   June 2024         Orig DB1           G1                   G2            DB2  Benef         |     |            |      (Stage 1)     |              |     |         |     |            |                    |              |     |       ..|.....|............|....................|..............|.....|..         |     |            |       Stage 2      |              |     |         |     |            |                    |              |     |         |     |<---Lock----|(2.1)               |              |     |         |     |            |                    |              |     |         |     |       (2.2)|--Lock-Assertion--->|              |     |         |     |            |                    |              |     |         |     |            |               (2.3)|--Broadcast-->|     |         |     |            |                    |              |     |         |     |            |                    |              |     |         |     |            |<-----Receipt-------|(2.4)         |     |         |     |            |                    |              |     |       ..|.....|............|....................|..............|.....|..         |     |            |                    |              |     |                               Figure 3   The purpose of the signed lock-assertion is for dispute resolution   between G1 and G2 (i.e. the entities who own and operate G1 and G2   respectively) in the case that asset state inconsistencies in NW1 and   NW2 are discovered later.   The gateway G2 must return a digitally signed receipt to G1 regarding   the earlier signed lock-assertion in order to cover G1 (exculpatory   proof) in the case of later denial by G2.9.  Commitment Preparation and Finalization (Stage 3)   In Stage 3 the gateways G1 and G2 commit to the asset transfer by   making permanent the changes they made to the respective networks   (ledgers).  The previous signed receipt message (2.4) from gateway G2   to gateway G1 signals the start of the commitment subprotocol in   Stage 3.   Upon receiving the signed receipt message from G2 in the previous   stage, G1 begins the commitment (see Figure 5):   *  Commit-prepare (3.1): Gateway G1 indicates to G2 to prepare for      the commitment of the transfer.  This message should include      hashes of the previous messages (message 2.2 and 2.4).Hardjono, et al.        Expires 10 December 2024               [Page 18]Internet-Draft              SAT Architecture                   June 2024   *  Temporary asset mint (3.2): Gateway G2 creates (mints) an      equivalent asset in NW2 assigned to itself as the owner.  This      step can be reversed (i.e. asset destroyed) in the case of the      failure in the commitment steps because G2 is still the owner of      the asset in NW2.   *  Commit-ready (3.3): Gateway G2 sends a commit-ready message to G1      indicating that it is ready to carry-out the last steps of the      commitment subprotocol.  Note that that the entire asset transfer      session can be aborted before this step without affecting the      asset state in the respective networks.   *  Asset burn (3.4): Gateway G1 extinguishes (burns) the asset in      network NW1 which it has locked since Step 2.3.   *  Commit-final assertion (3.5): Gateway G1 indicates to G2 that G1      has performed the extinguishment of the asset in NW1.  This      message must be digitally signed by G1.   *  Asset-assignment (3.6): Gateway G2 assigns the minted asset (which      it has been self-holding since Step 3.2) to the Beneficiary.   *  ACK-final receipt (3.7): Gateway G2 sends a signed assertion that      it has assigned the asset to the intended Beneficiary.   *  Receipt broadcast (3.8) Gateway G1 logs a copy of the signed      receipt message to its local state data DB2.  G1 may also      broadcast the fact of the signed receipt to all members of network      NW1.  The mechanism to log and to broadcast is out of scope.   *  Transfer complete (3.9): Gateway G1 must explicitly close the      asset transfer session with gateway G2.  This allows both sides to      close down the secure channel established earlier in Stage 1.Hardjono, et al.        Expires 10 December 2024               [Page 19]Internet-Draft              SAT Architecture                   June 2024         Orig DB1           G1                   G2           DB2  Benef         |     |             |      (Stage 2)     |            |     |         |     |             |                    |            |     |       ..|.....|.............|....................|............|.....|..         |     |             |       Stage 3      |            |     |         |     |             |                    |            |     |         |     |        (3.1)|--Commit Prepare--->|            |     |         |     |             |                    |            |     |         |     |             |               (3.2)|----Mint--->|     |         |     |             |                    |            |     |         |     |             |<--Commit Ready ----|(3.3)       |     |         |     |             |                    |            |     |         |     |             |                    |            |     |         |     |<---Burn-----|(3.4)               |            |     |         |     |             |                    |            |     |         |     |        (3.5)|-Commit Final Asrt->|            |     |         |     |             |                    |            |     |         |     |             |                    |            |     |         |     |             |               (3.6)|---Assign-->|     |         |     |             |                    |            |     |         |     |             |<-----ACK Final-----|(3.7)       |     |         |     |             |                    |            |     |         |     |             |                    |            |     |         |     |<-Broadcast--|(3.8)               |            |     |         |     |             |                    |            |     |         |     |        (3.9)|-----Completed----->|            |     |         |     |             |                    |            |     |       ..|.....|.............|....................|............|.....|..         |     |             |                    |            |     |                               Figure 410.  The Commitment sub-protocol   Within Stage 3, the gateways must implement one (or more)   transactional commitment sub-protocols that permit the coordination   between two gateways, and the final commitment of the asset transfer.   In the case that there are multiple commitment subprotocols supported   by the gateways, the choice of the sub-protocol (type/version) and   the corresponding commitment evidence must be negotiated between the   gateways during Stage 0.   For example, in Stage 2 and Stage 3 discussed above the gateways G1   and G2 may implement the classic 2-Phase or 3-Phase Commit (2PC or   3PC) sub-protocol [Gray81] as a means to ensure efficient and non-   disputable commitments to the asset transfer.Hardjono, et al.        Expires 10 December 2024               [Page 20]Internet-Draft              SAT Architecture                   June 2024   Historically, transactional commitment protocols employ locking   mechanisms to prevent update conflicts on the data item in question.   When used within the context of digital asset transfers across   networks, the fact that an asset has been locked in NW1 must be   communicated via an assertion to G2 (as the 3PC participant) in an   indisputable manner.   Similarly, G2 must return a signed assertion to G1 that the asset has   been regenerated (minted) in NW2.   These signed assertions must be verifiable by an authorized third   party, in the case that disputes occur (post event) or where legal   audit is required on the asset transfer.   The precise form of these assertions must be standardized (for the   given transactional commitment protocol) to eliminate any ambiguity.11.  Security Considerations   As an asset network holds an increasing number of digital assets, it   may become attractive to attackers seeking to compromise the   cryptographic keys of the entities, services and its end-users.   Gateways are of particular interest to attackers because they enable   the transferal of digital assets to external networks, which may or   may not be regulated.  As such, hardening technologies and tamper-   resistant crypto-processors (e.g.  TPM, SGX) should be used for   implementations of gateways [HS19].12.  Policy Considerations   Digital asset transfers must be policy-driven in the sense that it   must observe and enforce the policies defined for the network.   Resources that make-up a network are owned and operated by entities   (e.g. legal persons or organizations), and these entities typically   operate within regulatory jurisdictions [FATF].  It is the   responsibility of these entities to translate regulatory policies   into functions on networks that comply to the relevant regulatory   policies.   At the application layer, asset transfers must take into   consideration the legal status of assets and incorporate relevant   asset-related policies into their business logic.  These policies   must permeate down to the gateways that implement the functions of   asset transaction processing.Hardjono, et al.        Expires 10 December 2024               [Page 21]Internet-Draft              SAT Architecture                   June 202413.  Threat Analysis Considerations   The SAT protocol faces challenges with regards to the confidentiality   of a transfer between gateways, and the potential issue related to a   denial-of-service (and resource waste) when either gateway is not   compliant with the protocol.   For confidentiality of a transfer, the secure asset transfer protocol   must utilize a TLS1.2 (TLS1.3) secure channel that must be   established between the sender gateway (G1) and the receiver gateway   (G2).  The two gateways must first establish this secure channel at   the start of Stage 1 before they can proceed to execute the asset   transfer protocol.  This includes both gateways verifying all the   relevant parameters required for their TLS1.2 session (e.g. correct   TLS endpoints, certificate validation, identity validation, etc.).   There are several challenges that may arise when gateways are not   compliant with the SAT protocol.  Some of these are described below.13.1.  Multiple intentional aborts by the sender gateway   A dishonest sender gateway G1 may purposely fail to continue the   protocol run at certain crucial points.  One such crucial point is in   Stage-3, where the gateway G1 is expected to transmit the Commit-   Final Assertion message (3.5).  If the gateway G1 intentionally fails   to transmit this message, gateway G2 may conclude that the message   has been lost and may proceed to reverse the temporary hold it has   previously created (temporary asset mint in message 3.2).  Although   this dishonest behavior by G1 does not cause asset damage to G2 or   NW2, it may exhaust computing resources at gateway G2.  If network   NW2 incurs transaction fees, such a reversal may be costly for   gateway G2.13.2.  Multiple intentional aborts by the receiver gateway   In a similar manner, a receiver gateway G2 may also purposely fail to   continue the protocol run at certain crucial points.  One such point   is the Commit-Ready message (3.3) that it should transmit to G1 after   receiving the commit prepare message (3.1) from G1.  In this case,   gateway G1 may conclude that the message is lost and simply abort the   protocol run.   Another possible denial-of-service attack could arise when G2   purposefully fails to send a Lock-Assertion-Receipt (2.4), thereby   forcing G1 to reverse its lock that was performed earlier (2.1).Hardjono, et al.        Expires 10 December 2024               [Page 22]Internet-Draft              SAT Architecture                   June 202413.3.  Failure to transmit ACK-Final Receipt   Another possible point of attack by a dishonest gateway G2 may occur   by the gateway intentionally failing to transmit the ACK-Final-   Receipt (3.7) in response to the Commit-Final Assertion message (3.5)   from gateway G1.  Here, the sender gateway G1 may conclude that the   message is lost and will assume that the transaction has reach   completion in network NW2.  The sender gateway G1 has retained the   previous Lock-Assertion Receipt (2.4) in Stage-2 that was signed by   G2, indicating that the gateway G2 has accepted the responsibility of   ensuring that the asset-assignment (3.6) by G2 will be correctly   executed.  Failure by G2 to complete this task becomes a financial   and legal liability for the owner of gateway G2.   In general, it is recommended that multiple redundant gateways be   utilized within a network to mitigate a single gateway's malicious   behavior.  Furthermore, there are gateway recovery and failover   mechanisms that have been defined in [BCH21].13.4.  Failure to extinguish asset   Another potential attack may come from a dishonest gateway G1 who   intentionally fails to extinguish the asset in network NW1 (in step   3.4).  This means G1 is henceforth in control of the asset.  This   type of denial-of-service is network specific because it implies that   G1 was able to perform a lock on the asset on behalf of the asset-   owner (i.e. originator) through one or more mechanisms supported by   network NW1 independent of (and prior to) the secure asset transfer   protocol.   This denial-of-service is out of scope for the current architecture   specification because it represents a weakness on the part of the   network NW1.13.5.  Identity impersonations   Another vector of attack may involve a gateway that impersonates an   asset holder in a given network.  For example, a gateway G1 may   pretend to be the owner of an asset (originator) in network NW1 and   proceed to transfer it to a beneficiary located in network NW2.   The verification of the identity of the originator and beneficiary   must be performed as part of the set-up stage (Stage 0) as described   in Section 6, which is currently out-of-scope for the secure asset   transfer protocol.Hardjono, et al.        Expires 10 December 2024               [Page 23]Internet-Draft              SAT Architecture                   June 2024   The identity verification includes that of the owner of gateways G1   and G2 respectively.  Standard protocols for federated identity   management already exist and have wide deployment.14.  Compatibility Considerations   As the asset transfer protocol must be agnostic to the anatomy of a   digital asset and to the type of ledger technology underlying a   system maintaining digital assets, it must be compatible with   different asset identification standards like ISO 20022 and ITIN, and   with standards for communicating information about business processes   (like ISO 20022).  Keeping the Stage-0 specification open and not   tied to a specific messaging or identification standard allows the   Secure Asset Transfer architecture to be flexible and inclusive, and   thereby meet compatibility goals.15.  References15.1.  Normative References   [FATF]     FATF, "International Standards on Combating Money              Laundering and the Financing of Terrorism and              Proliferation - FATF Revision of Recommendation 15              (Updated June 2021)", October 2018, <http://www.fatf-              gafi.org/publications/fatfrecommendations/documents/fatf-              recommendations.html>.   [ISO]      ISO, "Blockchain and distributed ledger technologies-              Vocabulary (ISO:22739:2020)", July 2020,              <https://www.iso.org>.   [ISO20022] ISO, "Universal Financial Industry Message Scheme (ISO              20022).", July 2023, <https://www.iso20022.org>.   [ITIN]     ITSA, "International Token Identification Number.", July              2023, <https://my.itsa.global/what-we-do>.   [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST              Blockchain Technology Overview (NISTR-8202)", October              2018, <https://doi.org/10.6028/NIST.IR.8202>.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.15.2.  Informative ReferencesHardjono, et al.        Expires 10 December 2024               [Page 24]Internet-Draft              SAT Architecture                   June 2024   [ABCH20]   Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and              T. Hardjono, "Proposal for a Comprehensive Crypto Asset              Taxonomy", May 2020, <https://arxiv.org/abs/2007.11877>.   [Abebe19]  Abebe, E., Behl, D., Govindarajan, C., Hu, Y.,              Karunamoorthy, D., Novotny, P., Pandit, V., Ramakrishna,              V., and C. Vecchiola, "Enabling Enterprise Blockchain              Interoperability with Trusted Data Transfer (Middleware              2019, Industry Track)", December 2019,              <https://arxiv.org/abs/1911.01064>.   [Abebe21]  Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit,              V., Ramakrishna, V., and J. Yu, "Verifiable Observation of              Permissioned Ledgers (ICBC2021)", May 2021,              <https://arxiv.org/abs/2012.07339>.   [BCH21]    Belchior, R., Correia, M., and T. Hardjono, "DLT Gateway              Crash Recovery Mechanism, IETF, draft-belchior-gateway-              recovery-01.", March 2021,              <https://datatracker.ietf.org/doc/draft-belchior-gateway-              recovery/>.   [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.              Correia, "A Survey on Blockchain Interoperability: Past,              Present, and Future Trends", May 2020,              <https://arxiv.org/abs/2005.14282v2>.   [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet              Protocols, ACM Computer Communication Review, Proc SIGCOMM              88, vol. 18, no. 4, pp. 106-114", August 1988.   [DevID]    IEEE, "802.1AR: Secure Device Identity", August 2018,              <https://doi.org/10.1109/IEEESTD.2018.8423794>.   [DLVIEW]   Ramakrishna, V., Pandit, V., Nishad, S., Narayanam, K.,              and D. Vinayagamurthy, "Views and View Addresses for              Blockchain/DLT Interoperability, IETF Draft", November              2021.   [Gray81]   Gray, J., "The Transaction Concept: Virtues and              Limitations, in VLDB Proceedings of the 7th International              Conference, Cannes, France, September 1981, pp. 144-154",              September 1981.   [Herl19]   Herlihy, M., "Blockchains From a Distributed Computing              Perspective, Communications of the ACM, vol. 62, no. 2,              pp. 78-85", February 2019,              <https://doi.org/10.1145/3209623>.Hardjono, et al.        Expires 10 December 2024               [Page 25]Internet-Draft              SAT Architecture                   June 2024   [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards and              Interoperability Architecture for Blockchain Autonomous              Systems, IEEE Transactions on Engineering Management",              June 2019, <https://doi:10.1109/TEM.2019.2920154>.   [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted              Computing Base for Blockchain Infrastructure Security,              Frontiers Journal, Special Issue on Blockchain Technology,              Vol. 2, No. 24", December 2019,              <https://doi.org/10.3389/fbloc.2019.00024>.   [RATS]     Birkholz, H., Thaler, D., Richardson, M., Smith, N., and              W. Pan, "Remote ATtestation procedureS (RATS)              Architecture", January 2023,              <https://datatracker.ietf.org/doc/rfc9334/>.   [SATcore]  Hargreaves, M., Hardjono, T., and R. Belchior, "IETF              Secure Asset Transfer Protocol (SATP)", 9 July 2023,              <https://datatracker.ietf.org/doc/draft-ietf-satp-              core/>.>.   [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments              in System Design, ACM Transactions on Computer Systems,              vol. 2, no. 4, pp. 277-288", November 1984.   [TPMdevID] TCG, "TPM 2.0 Keys for Device Identity and Attestation", 8              October 2021, <https://trustedcomputinggroup.org/resource/              tpm-2-0-keys-for-device-identity-and-attestation/>.Authors' Addresses   Thomas Hardjono   MIT   Email: hardjono@mit.edu   Martin Hargreaves   Quant Network   Email: martin.hargreaves@quant.network   Ned Smith   Intel   Email: ned.smith@intel.com   Venkatraman Ramakrishna   IBMHardjono, et al.        Expires 10 December 2024               [Page 26]Internet-Draft              SAT Architecture                   June 2024   Email: vramakr2@in.ibm.comHardjono, et al.        Expires 10 December 2024               [Page 27]