| Internet-Draft | SATP Gateway | August 2022 |
| Chen, et al. | Expires 16 February 2023 | [Page] |
[SATP] is a secure asset transfer protocol that operates between two gateways. This memo describes requirements, standards and architectural options that can be considered to identify, discover and verify gateways before transferring secure digital assets via SATP.¶
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 16 February 2023.¶
Copyright (c) 2022 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 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.¶
Currently there is a growth in the number of blockchain and distributed ledger technology (DLT) systems being deployed worldwide for different areas of applications (e.g., finance, supply chains, IoT devices, etc.). One notable application is in the area of digital assets (or virtual assets) [FATF].¶
As independent autonomous systems, each decentralized ledger network (DLN) employs its own interior protocols (e.g. consensus protocols) that manages the resources (e.g., shared ledger) relevant to the assets and entities in that network. Key to the success of the blockchain and DLT paradigm is the interoperability between DLNs, permitting digital assets to be moved across DLNs in an efficient and secure manner.¶
For the purposes of asset transfers across DLNs, one or more nodes within a DLN can take-on the role of a gateway that peers with other gateways belonging to other DLNs [ARCH]. As a node participating in a blockchain, a gateway has access to the resources (e.g., ledger) located in the interior of that blockchain. Facing outbound, the gateway has the ability to peer with matching gateways to facilitate asset transfers¶
A core requirement for the gateway-to-gateway protocol [SATP] employed by peered gateways is the correct identification of the systems that act as gateways, the efficient look-up/discovery of the required gateway on demand, and the correct validation of the ownership of the discovered gateway.¶
This memo is to identify the key security requirements for a trustworthy gateway. Based on the requirements, decentralised identification description [DiD] standard is selected to describe a gateway as its identifier. Then, architectural options are presented to showcase how to use the decentralised gateway identifier for gateway discovery and verification.¶
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.¶
The following are some terminology used in the current document. Further terminology can be found in [Arch].¶
In the context of a digital asset transfer, a gateway identification, discovery and verification solution consists of mechanisms that permit a local gateway to obtain assurance that a given remote device is a gateway with a verifiable identity and ownership. That is, it needs to obtain assurance that (a) the device is a genesis and trusted computer system with proper security settings; (b) is operating as a gateway for a designated blockchain or decentralized ledger network (DLN) and (c) is owned by an entity operating under the relevant jurisdiction in the context of the digital asset in question. In the other word, the gateway identification should provide enough information to enable the above assurance verification at both application and network layers:¶
Since the gateways are used to transfer digital assets across DLNs, they must have an unique identifier, which is discoverable globally or within a specific consortium, e.g. [SWIFT]. In addition, They also must provide enough verifiable business and security settings at both application and network level for them to verify and trust each other to ensure the security and legal compliance of the asset transfer.¶
According to the above requirement analysis, there is a need for a data container used to host a collection of identification and security settings at both application and network (device) layers. DiD is a natural technology to meet the requirement. Applying DiD for gateway identification and verification is shown in Figure 1.¶
+--------------+
| DiD Doc |------------------>did:Gateway:123xyz
+--------------+ |
^ |
| |
| |
| V
+---------------+ +-----------+
| Gateway Owner |----------------->| Gateway |
+---------------+ +-----------+
The gateway identification must include (but not limited) the following verifiable identification information for authentication and secure channel establishment for secure asset transfer:¶
did:Gateway:123xyz
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/ed25519-2020/v1"
]
"id": "did:GatewayExample:123xyz
"authentication": [{
"id": "5493-00-84UKLVMY22DS-16",
"type": "LEI",
......
}]
"Authorization": [{
"id": "abc-123",
"type": "VASP",
......
}]
"Service": [{
"end-point": "satres://..........",
"type": "SATP"
......
}]
}
In this section, an overall architecture is proposed to support the gateway registration and discovery. Three implementation options are discussed. The basic CURD operations that a DiD repository must implement are provided.¶
A given asset service provider may possess multiple nodes within one or more DLNs. No matter what consensus model is applied in a DLN, it is desirable that the DLN has one or more gateways capable of participating in an asset transfer between two DLNs. As such, there must be some mechanism that permits these gateway owners to declare their DiD as a gateway into a given DLN.¶
To make a gateway widely discoverable, the gateway owner should follow the common Publish/Lookup design pattern [UDDI] by registering the gateway's DiD with a public DiD repository for other gateways or applications to look up. The process is shown in Figure 3.¶
+----------------+
2. Lookup +------>| DiD Repository |<------+ 1. Register
| +----------------+ |
| |
| |
+------+ +-----+ 3. Mutual Verify +-----+ +------+
| DLN1 |--->| GW1 |<------------------------>| GW2 |--->| DLN2 |
+------+ +-----+ 4. SATP Transfer +-----+ +------+
First of all, GW2 registers its DiD with the DiD Repository as shown Step 1 in Figure 3. When another gateway (GW1) wants to transfer digital assets from DLN1 to DLN2, GW1 can discover GW2 by querying its DiD from the DiD repository as shown Step 2 in Figure 3. With the resolved DiD of GW2, GW1 can request a mutual verification with GW2 by sending its DiD string as shown Step 3 in Figure 3. Once GW1 and GW2 establish a trusted channel after passing all verification, they can start a SATP asset transfer as shown Step 4 in Figure 3.¶
This discovery and verification processes must be automated as far as possible, and discovery should not require human intervention. If a directory of gateways is available, then it should be utilized by both GW1 and GW2.¶
A public DiD repository can be implemented using one of the following system architectures:¶
No matter which above architecture to be adopted, the DiD repository service must support the basic CRUD operations via standard API or SDK as follows:¶
Create (Register): The DiD repository system must specify how a client creates a DID record in the repository.¶
To do so, the DiD repository system must conduct all cryptographic and non-cryptographic operations to ensure the correctness and ownership of the DiD to register. In addition, DiD repository may design and add specific metadata attached to a DiD record to help a particular class of clients easily to query a particular gateway, such as "Gateways for Bitcoin" or "ateways for Bitcoin for clients in Asia-Pacific".¶
Read (Resolver): Given a DiD string, the DiD repository must be able to resolve the DiD string by returning a valid DiD document if the DiD string is valid.¶
Due to the verity of the ways to obtain a DiD string, how to look up a DiD string is beyond of this memo.¶
Update (Reversion): From time to time, a gateway owner may want to update its gateway, e.g. add a new service. As a result, the DiD repository system should allow the gateway owner to update its existing DiD, subject to passing the required security verification:¶
Note that due to the immutability of blockchain/DLT, a reversion of the DiD to be updated may be created, instead of updating, for a decentralized implementation.¶
There are a few on-going projects in developing such decentralised DiD repository systems, e.g., [TVDR]¶
Once a gateway (DW1) obtains another gateway (DW2)'s DiD, it can initialize a session with its gateway peer for mutual verification. The high-level process/protocol is presented in Figure 4.¶
+------+ +-----+ +----------------+ +-----+ +------+
| DLN1 | | GW1 | | DiD Repository | | GW2 | | DLN2 |
+---+--+ +--+--+ +--------+-------+ +--+--+ +---+--+
|-----1--->| | | |
| +---------2----->| | |
| |<--------3------+ | |
| | | | |
| |----------------4-------------->| |
| | |<-------5------+ |
| | +--------6----->| |
| | | | |
| |<-------7-----------------------| |
| |-------------------------8----->| |
| | ...... | |
| | +----9---->|
| |<-------10----------------------+ |
Note that the above protocol has been simplified. The actual verification process may involve one or more the trusted 3rd-part to help verify some of the business qualifications and security capabilities defined in the DiD docs. And there are more than one interactions between DW1 and DW2 according to the transfer type and SATP protocol.¶
In addition to the basic security setting mentioned above, the following technologies can also be considered as either enhancement or alternatives of security settings:¶