Internet Engineering Task Force M. Hargreaves Internet-Draft Quant Network Intended status: Informational T. Hardjono Expires: 29 October 2023 MIT R. Belchior Technico Lisboa 27 April 2023 Secure Asset Transfer Protocol (SATP) draft-ietf-satp-core-00 Abstract This memo This memo describes the Secure Asset Transfer (SAT) Protocol for digital assets. SAT is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit to ensure the properties of transfer atomicity, consistency, isolation and durability. 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 29 October 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Hargreaves, et al. Expires 29 October 2023 [Page 1] Internet-Draft SATP Core April 2023 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. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Secure Asset Transfer Protocol . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SAT Model . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Types of APIs . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Types of Flows . . . . . . . . . . . . . . . . . . . . . 6 4.5. Resources and Identifiers . . . . . . . . . . . . . . . . 7 5. SATP Message Format, identifiers and Descriptors . . . . . . 7 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. SATP Message Format . . . . . . . . . . . . . . . . . . . 7 5.3. Digital Asset Resource Descriptors . . . . . . . . . . . 8 5.3.1. Organization Identifier . . . . . . . . . . . . . . . 8 5.3.2. Gateway / Endpoint ID . . . . . . . . . . . . . . . . 9 5.3.3. Network or system Identifier . . . . . . . . . . . . 9 5.3.4. Resource . . . . . . . . . . . . . . . . . . . . . . 9 5.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Digital Asset Resource Client Descriptors . . . . . . . . 9 5.4.1. Organization Identifier . . . . . . . . . . . . . . . 10 5.4.2. Gateway / Endpoint ID . . . . . . . . . . . . . . . . 10 5.4.3. Organizational Unit . . . . . . . . . . . . . . . . . 10 5.4.4. Name . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4.5. Examples . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Gateway Level Access Control . . . . . . . . . . . . . . 11 5.6. Negotiation of Security Protocols and Parameters . . . . 11 5.6.1. TLS Established . . . . . . . . . . . . . . . . . . . 11 5.6.2. Client offers supported credential schemes . . . . . 11 5.6.3. Server selects supported credential scheme . . . . . 11 5.6.4. Client asserts or proves identity . . . . . . . . . . 12 5.6.5. Sequence numbers initialized . . . . . . . . . . . . 12 5.6.6. Messages can now be exchanged . . . . . . . . . . . . 12 5.7. Asset Profile Identification . . . . . . . . . . . . . . 12 5.8. Application Profile Negotiation . . . . . . . . . . . . . 12 5.9. Discovery of Digital Asset Resources . . . . . . . . . . 13 6. Identity and Asset Verification Flow (Stage 0) . . . . . . . 13 7. Transfer Initiation Flows (Stage 1) . . . . . . . . . . . . . 14 7.1. Initialization Request Message (Stage 1) . . . . . . . . 15 7.2. Initialization Request Message Response (Stage 1) . . . . 16 8. Lock-Assertion Flows (Stage 2) . . . . . . . . . . . . . . . 17 8.1. Transfer Commence Message . . . . . . . . . . . . . . . . 18 Hargreaves, et al. Expires 29 October 2023 [Page 2] Internet-Draft SATP Core April 2023 8.2. Commence Response Message (ACK-Commence) . . . . . . . . 20 8.3. Lock Assertion Message . . . . . . . . . . . . . . . . . 21 8.4. Lock Assertion Receipt Message (Assertion-Receipt) . . . 22 9. Commitment Establishment Flow (Stage 3) . . . . . . . . . . . 23 9.1. Commit Preparation Message (Commit-Prepare) . . . . . . . 23 9.2. Commit Preparation Acknowledgement (ACK-Prepare) . . . . 24 9.3. Commit Ready Message (Commit-Ready) . . . . . . . . . . . 25 9.4. Commit Final Message (Commit-Final) . . . . . . . . . . . 26 9.5. Commit-Final Acknowledgement Message (ACK-Final) . . . . 26 9.6. Transfer Complete Message . . . . . . . . . . . . . . . . 27 10. Security Consideration . . . . . . . . . . . . . . . . . . . 28 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction This memo proposes a secure asset transfer protocol (SATP) that is intended to be deployed between two gateway endpoints to transfer a digital asset from an origin network to a destination network. Both the origin and destination networks are assumed to be opaque in the sense that the interior constructs of a given network is not read/write accessible to unauthorized entities. The protocol utilizes the asset burn-and-mint paradigm whereby the asset to be transferred is permanently disabled or destroyed (burned) at the origin network and is re-generated (minted) at the destination network. This is achieved through the coordinated actions of the peer gateways handling the unidirectional transfer at the respective networks. A gateway is assumed to be trusted to perform the tasks involved in the asset transfer. The overall aim of the protocol is to ensure that the state of assets in the origin and destination networks remain consistent, and that asset movements into (out of) networks via gateways can be accounted for. There are several desirable technical properties of the protocol. The protocol must ensure that the properties of atomicity, consistency, isolation, and durability (ACID) are satisfied. Hargreaves, et al. Expires 29 October 2023 [Page 3] Internet-Draft SATP Core April 2023 The requirement of consistency implies that the asset transfer protocol always leaves both networks in a consistent state (that the asset is located in one system/network only at any time). Atomicity means that the protocol must guarantee that either the transfer commits (completes) or entirely fails, where failure is taken to mean there is no change to the state of the asset in the origin (sender) network. The property of isolation means that while a transfer is occurring to a digital asset from an origin network, no other state changes can occur to the asset. The property of durability means that once the transfer has been committed by both gateways, that this commitment must hold regardless of subsequent unavailability (e.g. crash) of the gateways implementing the SAT protocol. All messages exchanged between gateways are assumed to run over TLS1.2, and the endpoints at the respective gateways are associated with a certificate indicating the legal owner (or operator) of the gateway. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. 3. Terminology The following are some terminology used in the current document: Client application: This is the application employed by a user to interact with a gateway. Gateway: The computer system functionally capable of acting as a gateway in an asset transfer. Sender gateway: The gateway that initiates a unidirectional asset transfer. Recipient gateway: The gateway that is the recipient side of a unidirectional asset transfer. Hargreaves, et al. Expires 29 October 2023 [Page 4] Internet-Draft SATP Core April 2023 Claim: An assertion made by an Entity [JWT]. Claim Type: Syntax used for representing a Claim Value [JWT]. Gateway Claim: An assertion made by a Gateway regarding the status or condition of resources (e.g. assets, public keys, etc.) accessible to that gateway (e.g. within its network or system). 4. The Secure Asset Transfer Protocol 4.1. Overview The Secure Asset Transfer Protocol (SATP) is a gateway-to-gateway protocol used by a sender gateway with a recipient gateway to perform a unidirectional transfer of a digital asset. The protocol defines a number of API endpoints, resources and identifier definitions, and message flows corresponding to the asset transfer between the two gateways. +----------+ +----------+ | Client | | Off-net | | (App) | | Resource | +----------+ +----------+ | |API Type-3| | +----------+ | ^ V | +----------+ | |API Type-1| | +------+ +----------+----+ +----+----------+ +------+ | | | | | | | | | | | Net. | | Gateway |API | |API | Gateway | | Net. | | NW1 |---| G1 |Type|<------>|Type| G2 |---| NW2 | | | | | 2 | | 2 | | | | +------+ +----------+----+ +----+----------+ +------+ Figure 1 4.2. SAT Model The model for SATP is shown in Figure 1. Hargreaves, et al. Expires 29 October 2023 [Page 5] Internet-Draft SATP Core April 2023 The Client (application) interacts with its local gateway (G1) over an interface (API Type-1) in order to provide instructions to the gateway with regards to actions to assets and related resources located in the local system or network (NW1). Gateways interact with each other over a gateway interface (API Type- 2). A given gateway may be required to access resources that are not located in network NW1 or network NW2. Access to these types of resources are performed over an off-network interface (API Type-3). 4.3. Types of APIs The following are the types of APIs in SATP: * Gateway APIs for client (API Type-1): This the REST APIs that permit a Client (application) to interact with a local gateway, and issue instructions for actions pertaining to resources accessible to the gateway. * Gateway APIs for peer gateways (API Type-2): This is the REST APIs employed by two (2) peer gateways in performing unidirectional asset transfers. * APIs for validation of off-network resources (API Type-3): This is the REST APIs made available by a resource server (resource owner) at which a gateway can access resources. The use of these APIs is dependent on the mode of access and the type of flow in question. 4.4. Types of Flows The SAT protocol defines the following three (3) flows: * Transfer Initiation flow: This flow deals with commencing a transfer from one gateway to another. Several tasks are involved, including (but not limited to): (i) gateway identification and mutual authentication; (ii) exchange of asset type (definition) information; (iii) verification of the asset definition, and others. * Lock-Assertion flow: This flow deals with the conveyance of signed assertions from the sender gateway to the receiver gateway regarding the locked status of an asset at the origin network. * Commitment Establishment flow: This flow deals with the asset transfer and commitment establishment between two gateways. Hargreaves, et al. Expires 29 October 2023 [Page 6] Internet-Draft SATP Core April 2023 These flow will be discussed below. 4.5. Resources and Identifiers (a) Resource addressing for systems or networks, using the URL syntax. (b) Client identification based on the URN format. These are for identifying clients (developers and applications) who access these resources, and which in some use-cases require access authorization. (c) Protocol message family for negotiating authentication, authorisation, and parameters for confidential channel establishment. (d) Resource discovery mechanism for developers and applications to discover resources hosted at a gateway. The gateway response is subject to the level of access granted to that developer or application. 5. SATP Message Format, identifiers and Descriptors 5.1. Overview This section describes (i) the phases of SATP; (ii) the format of SATP messages; (iii) the format for resource descriptors; (iv) a method for gateways to implement access controls; (iv) protocol for negotiating security capabilities; (v) discovery and accessing resources and provisions for backward compatibility with existing systems. 5.2. SATP Message Format SATP messages are exchanged between applications (clients) and gateways (servers). They consist of protocol negotiation and functional messages. Messages are in JSON format, with protocol specific mandatory fields, support for several authentication and authorization schemes and support for a free format field for plaintext or encrypted payloads directed at the gateway. JSON format message, mandatory fields are shown below: * Version: SATP protocol Version (major, minor). * Message Type: This refers to the type of request or response to be conveyed in this message. Hargreaves, et al. Expires 29 October 2023 [Page 7] Internet-Draft SATP Core April 2023 * Session ID: unique identifier (UUIDv2) representing a session between two gateways handling a single unidirectional transfer. * Sequence Number: Monotonically increasing counter that uniquely represents a message from a session. * Resource URL: Location of Resource to be accessed. * Developer URN: Assertion of developer / application identity. * Action/Response: GET/POST and arguments (or Response Code) * Credential Profile: Specify type of auth (e.g. SAML, OAuth, X.509) * Credential Block: Credential token, certificate, string * Payload Profile: Asset profile and capabilities * Application Profile: Vendor or Application specific profile * Payload: Payload for POST, responses, and local networks. The payload is specific to the current SAT phase. * Payload Hash: hash of the current message payload. * Message signature: Gateway EDCSA signature over the message Other relevant attributes may exists that need to be captured for logging purposes. 5.3. Digital Asset Resource Descriptors Resources are identified by URL [RFC 1738] as described below: * The type is new: application/satres * The access protocol is SATP. Data included in the URL includes the folowing: 5.3.1. Organization Identifier This MAY be a Legal Entity Identifier (LEI) or other identifier linking resource ownership to a real world entity. Any scheme for identifying gateway owners may be implemented (e.g. LEI directory, closed user group membership, SWIFT BIC, etc.). Hargreaves, et al. Expires 29 October 2023 [Page 8] Internet-Draft SATP Core April 2023 The developer or application MAY validate the identity with the issuing authority. The identifier is not a trusted identity, but MAY be relied on where trust has been established between the two parties (e.g. in a closed user group). The mechanisms to determine organizations identifiers is out of scope for the current specification. 5.3.2. Gateway / Endpoint ID FQDN of the SATP compliant gateway. Required to establish IP connectivity. This MUST resolve to a valid IP address. 5.3.3. Network or system Identifier Specific to the gateway behind which the target network operates. This field is local to the gateway and is used to direct SATP interactions to the correct underlying network. This value maybe alphanumeric or a hexadecimal value. For example: "tradelens-network", "EU-supply-chain". 5.3.4. Resource Specifies a resource held on the underlying network. This field must be meaningful to the network in question but is otherwise an arbitrary string. The underlying object it points to may be a network address, data block, transaction ID, alias, etc. or a future object type not yet defined. 5.3.5. Examples satpres://quant/api.gateway1.com/swift 5.4. Digital Asset Resource Client Descriptors Resources are identified by URN as described below: * The type is new: application/satpclient The URN format does not imply availability of access protocol. Data included in the URN includes the following: Hargreaves, et al. Expires 29 October 2023 [Page 9] Internet-Draft SATP Core April 2023 5.4.1. Organization Identifier Legal Entity Identifier (LEI) or other identifier linking resource ownership to a real-world entity. Any scheme for identifying Gateway owners may be implemented (e.g. LEI directory, closed user group membership, BIC, etc.). The Gateway MAY validate the identity with the issuing authority. The identifier is not a trusted identity, but MAY be relied on where trust has been established between the two parties (e.g. in a closed user group). 5.4.2. Gateway / Endpoint ID Applications which interact with multiple networks can operate in a mode whereby the application connects to its local gateway, which then forwards application traffic to local networks and to remote networks via other SATP gateways. Where this is the case, this field identifies the "home" gateway for this application. This may be required to carry out gateway to gateway handshaking and protocol negotiation, or for the server to look up use case specific data relating to the client. 5.4.3. Organizational Unit The organization unit within the organization that the client (application or developer) belongs to. This assertion should be backed up with authentication via the negotiated protocol. The purpose of this field is to allow gateways to maintain access control mapping between applications and resources that are independent of the authentication and authorization schemes used, supporting future changes and supporting counterparties that operate different schemes. 5.4.4. Name A locally unique (within the OU) identifier, which can identify the application, project or individual developer responsible for this client connection. This is the most granular unit of access control, and gateways should ensure appropriate identifiers are used for the needs of the application or use case. 5.4.5. Examples satclient:quant/api.overledger.quant.com/research/luke.riley Hargreaves, et al. Expires 29 October 2023 [Page 10] Internet-Draft SATP Core April 2023 5.5. Gateway Level Access Control Gateways can enforce access rules based on standard naming conventions using novel or existing mechanisms such as AuthZ protocols using the resource identifiers above, for example: satpclient://hsbc/api.overledger.hsbc.com/lending/eric.devloper can READ/WRITE satpres://quant/api.gateway1.com/tradelens AND satpres://quant/api.gateway1.com/ripple These rules would allow a client so identified to access resources directly, for example: satpres://quant/api.gateway1.com/tradelens/xxxxxADDRESSxxxxx This method allows resource owners to easily grant access to individuals, groups and organizations. Individual gateway implementations may implement access controls, including subsetting and supersetting or applications or resources according to their own requirements. 5.6. Negotiation of Security Protocols and Parameters 5.6.1. TLS Established TLS 1.2 or higher MUST be implemented to protect gateway communications. TLS 1.3 or higher SHOULD be implemented where both gateways support TLS 1.3 or higher. 5.6.2. Client offers supported credential schemes Capability negotiation prior to data exchange, follows a scheme similar to the Session Description Protocol [RFC 5939]. Initially the client (application) sends a JSON block containing acceptable credential schemes, e.g. OAuth2.0, SAML in the "Credential Scheme" field of the SATP message. 5.6.3. Server selects supported credential scheme The server (recipient Gateway) selects one acceptable credential scheme from the offered schemes, returning the selection in the "Credential Scheme" field of the SATP message. Hargreaves, et al. Expires 29 October 2023 [Page 11] Internet-Draft SATP Core April 2023 If no acceptable credential scheme was offered, an HTPP 511 "Network Authentication Required" error is returned in the Action/Response field of the SATP message. 5.6.4. Client asserts or proves identity The details of the assertion / verification step are specific to the chosen credential scheme and are out of scope of this document. 5.6.5. Sequence numbers initialized Sequence numbers are used to allow the server to correctly order operations from the client, some of which may be asynchronous, synchronous, idempotent with duplicate requests handled in different ways according to the use case. The initial sequence number is proposed by the client (sender gateway) after the finalization of credential verification. The server (recipient gateway) MUST respond with the same sequence number to indicate acceptance. The client (sender gateway) increments the sequence number with each new request. Sequence numbers can be reused for retries in the event of a gateway timeout. 5.6.6. Messages can now be exchanged Handshaking is complete at this point, and the client can send SAT messages to perform actions on resources, which MAY reference the SAT Payload field. 5.7. Asset Profile Identification The client and server must mutually agree as to the asset type or profile that is the subject to the current transfer from the client and server. The client must provide the server with the asset- identification number, or the server may provide the client with the asset-identification numbers for the digital asset supported by the server. Formal specification of asset identification is out of scope of this document. Global numbering of digital asset types or profiles is expected to be performed by a legally recognized entity. 5.8. Application Profile Negotiation Where an application relies on specific extensions for operation, these can be represented in an Application Profile. Hargreaves, et al. Expires 29 October 2023 [Page 12] Internet-Draft SATP Core April 2023 For example, a payments application tracks payments through the use of a cloud based API and will only interact with gateways that log messages to that API, a resource profile can be established: Application Name: TRACKER X-Tracker_URL: https://api.tracker.com/updates X-Tracking-Policy: Always As gateways implement this functionality, they support the TRACKER application profile, and the application is able to expand its reach by periodically polling for the availability of the profile. This is an intentionally generalized extension mechanism for application or vendor specific functionality. 5.9. Discovery of Digital Asset Resources Applications located outside a network or system SHOULD be able to discover which resources they are authorized to access in a network or system. Resource discovery is handled by the gateway in front of the network. For instance using a GET request against the gateway URL with no resource identifier could return a list of URLs available to the requester. This list is subject to the access controls above. Gateways MAY allow applications to discover resources they do not have access to. This should be indicated in the free text field, and gateways SHOULD implement a process for applications to request access. Formal specification of supported resource discovery methods is out of scope of this document. 6. Identity and Asset Verification Flow (Stage 0) Prior to commencing the asset transfer from the sender gateway (client) to the recipient gateway (server), both gateways must perform a number of verifications steps. The types of information required by both the sender and recipient are use-case dependent and asset-type dependent. The verifications include, but not limited to, the following: Hargreaves, et al. Expires 29 October 2023 [Page 13] Internet-Draft SATP Core April 2023 * Gateway identity mutual verification: This is the identity of the gateway at the protocol and network layer. This may include validating the X509 certificates of the gateways. * Gateway owner verification: This is the verification of the identity (e.g. LEI) of the owners of the gateways. * Gateway device and state validation: This is the device attestation evidence [RATS] that a gateway must collect and convey to each other, where a verifier is assumed to be available to decode, parse and appraise the evidence. * Originator and beneficiary identity verification: This is the identity and public-key of the entity (originator) in the origin network seeking to transfer the asset to another entity (beneficiary) in the destination network. These are considered out of scope in the current specifications, and are assumed to have been successfully completed prior to the commencement of the transfer initiation flow. 7. Transfer Initiation Flows (Stage 1) This section describes the SATP initialization phase, where a sender gateway interacts with a recipient gateway, proposing a session. For this, several artifacts need to be validated: asset profile, asset ownership evidence, identities, and logging-related operations (log profile, access control profile). In this phase, gateways implement the Transfer Initiation Flows endpoint. In the following, the sender gateway takes instructions from an application, while the recipient gateway may act on behalf of its applications. The flow follows a request-response model. The sender gateway makes a request (POST) to the Transfer Initiation endpoint at the recipient gateway. Gateways MUST support the use of the HTTP GET and POST methods defined in RFC 2616 [RFC2616] for the endpoint. Clients (sender gateway) MAY use the HTTP GET or POST methods to send messages in this phase to the server (recipient gateway). If using the HTTP GET method, the request parameters may be serialized using URI Query String Serialization. Hargreaves, et al. Expires 29 October 2023 [Page 14] Internet-Draft SATP Core April 2023 The client and server may be required to sign certain messages in order to provide standalone proof (for non-repudiation) independent of the secure channel between the client and server. This proof may be required for audit verifications (e.g. post-event). (NOTE: Flows occur over TLS. Nonces are not shown). 7.1. Initialization Request Message (Stage 1) This message is sent from the sender gateway (client) to the recipient gateway (server) to its Transfer Initiation Endpoint. The purpose of this message is for the client to initiate an asset transfer. Depending on the proposal, multiple rounds of communication between the client and the server may happen. The parameters of this message consists of the following: * Version: SAT protocol Version (major, minor). * Message Type: The message type information indicating the current stage of the SATP flows. * Session ID: A unique identifier (UUIDv2) chosen by the sender gateway representing a session. * Developer URN: Assertion of developer / application identity. * Credential Profile: Specify type of auth (e.g. SAML, OAuth, X.509) * Payload Profile: Asset Profile provenance and capabilities * Application Profile: Vendor or Application specific profile * logging_profile REQUIRED: contains the profile regarding the logging procedure. Default is local store. * Access_control_profile REQUIRED: the profile regarding the confidentiality of the log entries being stored. Default is only the gateway that created the logs can access them. * Initialization Request Message signature REQUIRED: Gateway EDCSA signature over the message * Sender_gateway_pubkey REQUIRED: the public key of the gateway initiating a transfer Hargreaves, et al. Expires 29 October 2023 [Page 15] Internet-Draft SATP Core April 2023 * Sender_gateway_network_id REQUIRED: the ID of the source network * Recipient_gateway_pubkey REQUIRED: the public key of the gateway involved in a transfer * Recipient_gateway_network_id REQUIRED: the ID of the recipient network * Lock_type REQUIRED: faucet, timelock, hashlock, hashtimelock, multi-claim PC, destroy/burn (escrowed cross-claim). * Lock_expiration_time REQUIRED: when will the lock or escrow expire * Multiple claims allowed: true/false * Multiple cancels allowed: true/false * Permissions: list of identities (public-keys or X.509 certificates) that can perform operations on the escrow or lock on the asset in the origin network. * Originator: along with the sender gateway identification, allows identifying from where are the asset is escrowed/provided * Beneficiary: along with the recipient gateway identification, allows identifying to where are the escrowed asset is going * Subsequent calls: details possible escrow actions * History (optional): provides an history of the escrow, in case it has previously been initialized. The sender gateway makes the following HTTP request using TLS. Example: TBD. 7.2. Initialization Request Message Response (Stage 1) After receiving an Initialization Request Message, the recipient gateway needs to validate the profiles. This validation could be performed automatically (using a defined set of rules), or by requiring approval by an application. If one of the profiles is rejected, the recipient gateway constructs a Initialization Denied Message, stating what was rejected, and proposing an alternative (if applicable). Hargreaves, et al. Expires 29 October 2023 [Page 16] Internet-Draft SATP Core April 2023 Otherwise, if approved, the recipient gateway constructs an Initialization Request Message Response and sends it to the Transfer Initiation Endpoint at the sender gateway. The purpose of this message is for the server (recipient gateway) to indicate agreement to proceed with the proposed operations, under the proposed profiles. This message is sent from the recipient gateway to the sender gateway (client) in response to a Initialization Request from the sender gateway. The message must be signed by the server. The parameters of this message consists of the following: * Message Type: The message type information indicating the current stage of the SATP flows. * Session ID: A unique identifier (UUIDv2) chosen earlier by sender gateway in the Initialization Request Message. * Sequence Number: monotonically increasing counter that uniquely represents a message from a session. * Hash of the Initialization Request Message REQUIRED: the hash of the proposal. * Destination: if the recipient gateway calculates the destination address dynamically. * Timestamp REQUIRED: timestamp referring to when the Initialization Request Message was received. * Processed Timestamp REQUIRED: timestamp referring to when the Initialization Response Message was constructed. Example: TBD. 8. Lock-Assertion Flows (Stage 2) This section describes the conveyance of assertions (claims) regarding the status of the asset (or resource) from a sender gateway to a recipient gateway. In this phase, the gateways implement the Lock-Assertion Endpoint. Hargreaves, et al. Expires 29 October 2023 [Page 17] Internet-Draft SATP Core April 2023 In the following, the sender gateway takes the role of the client while the recipient gateway takes the role of the server. The flow follows a request-response model. The client makes a request (POST) to the Lock-Assertion Endpoint at the server. Gateways MUST support the use of the HTTP GET and POST methods defined in RFC 2616 [RFC2616] for the endpoint. Clients MAY use the HTTP GET or POST methods to send messages in this phase to the server. If using the HTTP GET method, the request parameters may be serialized using URI Query String Serialization. The client and server may be required to sign certain messages in order to provide standalone proof (for non-repudiation) independent of the secure channel between the client and server. This proof may be required for audit verifications post-event. (NOTE: Flows occur over TLS. Nonces are not shown). 8.1. Transfer Commence Message This message is sent from the client (sender gateway) to the Transfer Request Endpoint at the server (recipient gateway). It signals to the server that the client is ready to start the transfer of the digital asset. The message must contain claims related to the information from the previous flow (Phase 1). It must be signed by the client. The parameters of this message consists of the following: * message_type REQUIRED. MUST be the value urn:ietf:satp:msgtype:transfer-commence-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * originator_pubkey REQUIRED. This is the public key of the asset owner (originator) in the origin network or system. * beneficiary_pubkey REQUIRED. This is the public key of the beneficiary in the destination network. * sender_gateway_network_id REQUIRED. This is the identifier of the origin network or system behind the client. Hargreaves, et al. Expires 29 October 2023 [Page 18] Internet-Draft SATP Core April 2023 * recipient_gateway_network_id REQUIRED. This is the identifier of the destination network or system behind the server. * client_identity_pubkey REQUIRED. The public key of client who sent this message. * server_identity_pubkey REQUIRED. The public key of server for whom this message is intended. * hash_asset_profile REQUIRED. This is the hash of the asset profile previously agreed upon in Stage 1. * asset_unit OPTIONAL. If applicable this is the unit amount of the asset being transferred, previously agreed upon. * hash_prev_message REQUIRED. The hash of the last message. * client_transfer_number OPTIONAL. This is the transfer identification number chosen by the client. This number is meaningful only the client. * client_signature REQUIRED. The digital signature of the client. For example, the client makes the following HTTP request using TLS (with extra line breaks for display purposes only): Hargreaves, et al. Expires 29 October 2023 [Page 19] Internet-Draft SATP Core April 2023 POST /token HTTP/1.1 Host: server.example.com Authorization: Basic awHCaGRSa3F0MzpnWDFmQmF0M2ZG Content-Type: application/x-www-form-urlencoded { "message_type": "urn:ietf:satp:msgtype:transfer-commence-msg", "session_id":"9097hkstgkjvVbNH", "originator_pubkey":"zGy89097hkbfgkjvVbNH", "beneficiary_pubkey": "mBGHJjjuijh67yghb", "sender_net_system": "originNETsystem", "recipient_net_system":"recipientNETsystem", "client_identity_pubkey":"fgH654tgeryuryuy", "server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334", "hash_asset_profile":"nbvcwertyhgfdsertyhgf2h3v4bd3v21", "asset_unit": "ghytredcfvbhfr", "hash_prev_message":"DRvfrb654vgreDerverv654nhRbvder4", "client_transfer_number":"ji9876543ewdfgh", "client_signature":"fdw34567uyhgfer45" } Figure 2 8.2. Commence Response Message (ACK-Commence) The purpose of this message is for the server to indicate agreement to proceed with the asset transfer. This message is sent from the server (recipient gateway) to client (sender gateway) in response to a Transfer Commence Request from the client. The message must be signed by the server. The parameters of this message consists of the following: * message_type REQUIRED urn:ietf:satp:msgtype:ack-commence-msg * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client for whom this message is intended. * server_identity_pubkey REQUIRED. The server who sent this message. Hargreaves, et al. Expires 29 October 2023 [Page 20] Internet-Draft SATP Core April 2023 * hash_prev_message REQUIRED. The hash of the last message. * server_transfer_number OPTIONAL. This is the transfer identification number chosen by the server. This number is meaningful only to the server. * server_signature REQUIRED. The digital signature of the server. An example of a success response could be as follows: ``` HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "message_type":"urn:ietf:satp:msgtype:ack-commence-msg", "session_id":"9097hkbfgkjvVbNH", "client_identity_pubkey":"fgH654tgeryuryuy", "server_identity_pubkey":"dFgdfgdfgt43tetr535teyrfge4t54334", "hash_prev_message":"DRvfrb654vgreDerverv654nhRbvder4", "server_transfer_number":"ji9876543ewdfgh", "server_signature":"aaw34567uyhgfer66" } ``` Figure 3 8.3. Lock Assertion Message The purpose of this message is for the client (sender gateway) to convey a signed statement to the server declaring that the asset in question has been locked or escrowed by the sender in the origin network (e.g. to prevent double spending). The format of the evidence is dependent on the network or system of the client and is outside the scope of this specification. This message is sent from the client to the Lock Assertion Endpoint at the server. The server must validate the claims (payload) in this message prior to the next step. The message must be signed by the client (sender gateway). Hargreaves, et al. Expires 29 October 2023 [Page 21] Internet-Draft SATP Core April 2023 The parameters of this message consists of the following: * message_type REQUIRED urn:ietf:satp:msgtype:lock-assert-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client who sent this message. * server_identity_pubkey REQUIRED. The server for whom this message is intended. * lock_assertion_claims REQUIRED. The lock assertion claim or statement by the client. * lock_assertion_format OPTIONAL. The format of the assertion. * lock_assertion_expiration REQUIRED. The duration of time of the lock on the asset. * hash_prev_message REQUIRED. The hash of the previous message. * client_transfer_number OPTIONAL. This is the transfer identification number chosen by the client. This number is meaningful only to the client. * client_signature REQUIRED. The digital signature of the client. 8.4. Lock Assertion Receipt Message (Assertion-Receipt) The purpose of this message is for the server (recipient gateway) to indicate acceptance of the claims in the lock-assertion message delivered by the client (sender gateway) in the previous message. The message must be signed by the server. The parameters of this message consists of the following: * message_type REQUIRED urn:ietf:satp:msgtype:assertion-receipt-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client for whom this message is intended. Hargreaves, et al. Expires 29 October 2023 [Page 22] Internet-Draft SATP Core April 2023 * server_identity_pubkey REQUIRED. The server who sent this message. * hash_prev_message REQUIRED. The hash of previous message. * server_transfer_number OPTIONAL. This is the transfer identification number chosen by the server. This number is meaningful only to the server. * server_signature REQUIRED. The digital signature of the server. 9. Commitment Establishment Flow (Stage 3) This section describes the transfer commitment agreement between the sender gateway to a recipient gateway. This phase must be completed within the time specified in the lock_assertion_expiration value in the lock-assertion message. In this phase gateways implement the Transfer Commitment Endpoint. In the following, the sender gateway takes the role of the client while the recipient gateway takes the role of the server. The flow follows a request-response model. The client makes a request (POST) to the Transfer Commitment endpoint at the server. Gateways MUST support the use of the HTTP GET and POST methods defined in RFC 2616 [RFC2616] for the endpoint. Clients MAY use the HTTP GET or POST methods to send messages in this phase to the server. If using the HTTP GET method, the request parameters maybe serialized using URI Query String Serialization. The client and server may be required to sign certain messages in order to provide standalone proof (for non-repudiation) independent of the secure channel between the client and server. This proof maybe required for audit verifications post-event. (NOTE: Flows occur over TLS. Nonces are not shown). 9.1. Commit Preparation Message (Commit-Prepare) The purpose of this message is for the client to indicate its readiness to begin the commitment of the transfer. The message must be signed by the client. Hargreaves, et al. Expires 29 October 2023 [Page 23] Internet-Draft SATP Core April 2023 The parameters of this message consists of the following: * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:commit-prepare-msg * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client who sent this message. * server_identity_pubkey REQUIRED. The server for whom this message is intended. * hash_prev_message REQUIRED. The hash of previous message. * client_transfer_number OPTIONAL. This is the transfer identification number chosen by the client. This number is meaningful only the client. * client_signature REQUIRED. The digital signature of the client. 9.2. Commit Preparation Acknowledgement (ACK-Prepare) The purpose of this message is for the server to indicate to the client its readiness to proceed with the commitment finalization step. The message must be signed by the server. The parameters of this message consists of the following: * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:ack-prepare-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client for whom this message is intended. * server_identity_pubkey REQUIRED. The server who sent this message. * hash_prev_message REQUIRED. The hash of previous message. Hargreaves, et al. Expires 29 October 2023 [Page 24] Internet-Draft SATP Core April 2023 * server_transfer_number OPTIONAL. This is the transfer identification number chosen by the server. This number is meaningful only the server. * server_signature REQUIRED. The digital signature of the server. 9.3. Commit Ready Message (Commit-Ready) The purpose The purpose of this message is for the server to indicate to the client that: (i) the server has created (minted) an equivalent asset in the destination network assigned to the server (gateway), and (ii) that the server is ready to transfer ownership of the newly minted asset to the intended beneficiary. The message must be signed by the server. The parameters of this message consists of the following: * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:commit-ready-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client for whom this message is intended. * server_identity_pubkey REQUIRED. The server who sent this message. * mint_assertion_claims REQUIRED. The mint assertion claim or statement by the server. * mint_assertion_format OPTIONAL. The format of the assertion payload. * hash_prev_message REQUIRED. The hash of previous message. * server_transfer_number OPTIONAL. This is the transfer identification number chosen by the server. This number is meaningful only the server. * server_signature REQUIRED. The digital signature of the server. Hargreaves, et al. Expires 29 October 2023 [Page 25] Internet-Draft SATP Core April 2023 9.4. Commit Final Message (Commit-Final) The purpose of this message is for the client to indicate to the server that the client (sender gateway) has completed the extinguishment (burn) of the asset in the origin network. The message must contain standalone claims related to the extinguishment of the asset by the client. The claim must be signed by the client. The parameters of this message consists of the following: * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:commit-final-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client who sent this message. * server_identity_pubkey REQUIRED. The server for whom this message is intended. * burn_assertion_claims REQUIRED. The burn assertion claim or statement by the client. * burn_assertion_format OPTIONAL. The format of the assertion payload. * hash_prev_message REQUIRED. The hash of previous message. * client_transfer_number OPTIONAL. This is the transfer identification number chosen by the client. This number is meaningful only the client. * client_signature REQUIRED. The digital signature of the client. 9.5. Commit-Final Acknowledgement Message (ACK-Final) The purpose of this message is to indicate to the client that the server has completed the assignment of the newly minted asset to the intended beneficiary at the destination network. The parameters of this message consists of the following: Hargreaves, et al. Expires 29 October 2023 [Page 26] Internet-Draft SATP Core April 2023 * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:ack-commit-final-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. * client_identity_pubkey REQUIRED. The client for whom this message is intended.. * server_identity_pubkey REQUIRED. The server who sent this message. * assignment_assertion_claims REQUIRED. The assertion claim or statement by the server that the asset has been assigned by the server to the intended beneficiary. * assignment_assertion_format OPTIONAL. The format of the assertion payload. * hash_prev_message REQUIRED. The hash of previous message. * server_transfer_number OPTIONAL. This is the transfer identification number chosen by the server. This number is meaningful only the server. * server_signature REQUIRED. The digital signature of the server. 9.6. Transfer Complete Message The purpose of this message is for the client to indicate to the server that the asset transer session (identified by session_id) has been completed and that no further messages are to be expected from the client in regards to this transfer instance. The message closes the first message of Stage 2 (Transfer Commence Message). It must be signed by the client. The parameters of this message consists of the following: * message_type REQUIRED. It MUST be the value urn:ietf:satp:msgtype:commit-transfer-complete-msg. * session_id REQUIRED: 128-bit value identifying the current transfer-session between the client gateway and server gateway. This is the value from the Initialization Request Message. Hargreaves, et al. Expires 29 October 2023 [Page 27] Internet-Draft SATP Core April 2023 * client_identity_pubkey REQUIRED. The client who sent this message. * server_identity_pubkey REQUIRED. The server for whom this message is intended. * hash_prev_message REQUIRED. The hash of previous message. * hash_transfer_commence REQUIRED. The hash of the Transfer Commence message at the start of Stage 2. * client_transfer_number OPTIONAL. This is the transfer identification number chosen by the client. This number is meaningful only the client. * client_signature REQUIRED. The digital signature of the client. 10. Security Consideration Gateways are of particular interest to attackers because they are a kind of end-to-end pipeline that enable the transferral of digital assets to external networks or systems. Thus, attacking a gateway may be attractive to attackers instead of the network behind a gateway. As such, hardware hardening technologies and tamper-resistant crypto- processors (e.g. TPM, Secure Enclaves, SGX) should be considered for implementations of gateways. 11. IANA Consideration (TBD) 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . Hargreaves, et al. Expires 29 October 2023 [Page 28] Internet-Draft SATP Core April 2023 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . 12.2. Informative References [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", October 2018, . [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, September 2010, . Authors' Addresses Martin Hargreaves Quant Network Email: martin.hargreaves@quant.network Thomas Hardjono MIT Email: hardjono@mit.edu Rafael Belchior Technico Lisboa Email: rafael.belchior@tecnico.ulisboa.pt Hargreaves, et al. Expires 29 October 2023 [Page 29]