Internet-Draft SATP Gateway August 2022
Chen, et al. Expires 16 February 2023 [Page]
Internet Engineering Task Force
Intended Status:
S. Chen
CSIRO Data61
T. Hardjono
Q. Wang
CSIRO Data61

Gateway Identification and Discovery


[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.

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

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.

Table of Contents

1. Introduction

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.

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. Further terminology can be found in [Arch].

4. Gateway Identification

4.1. Requirements

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:

  • Application layer: At the application layer a gateway identification scheme is needed that permits a legal organization who participates in a given DLN to declare (advertise) one or more gateways into that DLN. This permits organizations to establish peering agreements (contracts) based on the asset type, DLN and jurisdictions, identifying (specifying) the gateways that will be used to connect to the DLN.
  • Network layer: In order for asset transfer services to scale-up, some degree of automation is needed for a gateway to discover peer gateways in remote DLN. This discovery must be efficient in order to minimize the time required for a digital asset from an originator in an origin DLN to be transferred cross-chain to the beneficiary in the destination DLN (see [SATP]).

4.2. DiD for Gateway Identification

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  |
             +---------------+                  +-----------+

Figure 1

The gateway identification must include (but not limited) the following verifiable identification information for authentication and secure channel establishment for secure asset transfer:

  • Authentication: The gateway must be owned/operated by a legal business entity registered with the local authority. The registration should be verifiable via 3rd-party services and/or trustworthy decentralized business directories, using standard identification schema, such as [LEI].
  • Authorization: The gateway owner must be issued with a license/certificate as authorized approval to provide virtual assets transfer services as a gateway from the corresponding blockchain foundation/authority, and register the services with well-known business directories (e.g., VASP).
  • Service: DiD document must include a complete service endpoint URI, or the necessary information used to construct such a URI, like SATP URI. In addition, the service endpoint identity public key should be represented using an X.509 certificate for establishing a secure channel between the two gateway peers (e.g., TLS). Optionally, some service-specific settings may be included here, such as a storage URI for SATP logging.
  • Device: Optionally, a gateway may be implemented in computer systems with a secure processor (TPM) [ISO/IEC 11889] or secure enclave (e.g., SGX) for assurance of device-level security. The Did document may include such information for remote attestation of the device security setting.

      "@context": [

      "id": "did:GatewayExample:123xyz
      "authentication": [{
         "id": "5493-00-84UKLVMY22DS-16",
         "type": "LEI",

      "Authorization": [{
         "id": "abc-123",
         "type": "VASP",

       "Service": [{
         "end-point": "satres://..........",
         "type": "SATP"

Figure 2

5. Gateway Registration and Discovery

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.

5.1. Architecture

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      +-----+    +------+

Figure 3

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.

5.2. Gateway DiD Repository Implementation

A public DiD repository can be implemented using one of the following system architectures:

  • Centralized client/server architecture: It is a mature system architecture and can be easily implemented. The disadvantage of this architecture is that all users have to trust the centralized server, which violates the design principle of DiD.
  • Decentralized Ledger: A nature implementation is to use blockchain/DLN directly. There have already such implementations under development, such as [SOVRIN] and [BTCR].
  • DNS - Domain Naming Service [RFC2181]: can be leveraged and/or extended to support DiD registration and discovery. These gateways can even form a DNS-like distributed DiD repository system to enable gateway registration and discovery by themselves.

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.

    • Input: A DiD string with its associated document
    • Output: A DiD record created in the repository if successful

    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.

    • Input: A DiD string
    • Output: its corresponding DiD document if successful

    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:

    • Input: A DiD string with a new DiD document or a set of attributes to update
    • Output: The existing DiD record is updated or a reversion is created

    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.

  • Delete (Revoke): a DiD repository must also allow a gateway owner to delete/revoke its existing DiD. While implementations may be different for different architectures, the DiD repository must ensure the DiD will never be used once being deleted although the record cannot be deleted persistently.

There are a few on-going projects in developing such decentralised DiD repository systems, e.g., [TVDR]

6. Gateway Verification

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----------------------+          |
Figure 4
  1. DLN1: request to transfer an asset to an address with DLN2
  2. DW1: request for DLN2's DiD Doc from the DiD Repository
  3. DiD Repository: resolve and return DLN2's DiD Doc
  4. DW1: after passing DLN2's DiD verification, request for a mutual verification by sending itself DiD string
  5. DW2: request for DLN2's DiD Doc from the DiD Repository
  6. DiD Repository: resolve and return DLN1's DiD Doc
  7. DW2: Send ACK if passing DLN1's DiD verification
  8. DW1: start a SATP tranfer
  9. DW2: If everything is OK, write/mint the transferred asset to DLN2
  10. DW2: send ACK to notify DW1

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.

7. Security Consideration

In addition to the basic security setting mentioned above, the following technologies can also be considered as either enhancement or alternatives of security settings:

8. References

8.1. Normative References

Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0", , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Elz, R. and R. Bush, "Clarifications to the DNS Specification", , <>.
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, , <>.
Eastlake, D., "Domain Name System Security Extensions", , <>.
Fielding, R., Mogul, J., MMasinter, L., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", , <>.
Rescorla, E. and A. Schiffman, "Clarifications to the DNS Specification", , <>.
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", , <>.
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <>.
Clement, L., Hately, A., Riegen, C., and T. Rogers, "UDDI Version 3.0.2, published by OASIS", , <>.

8.2. Informative References

Hardjono, T., Hargreaves, M., and N. Smith, "An Interoperability Architecture for Blockchain Gateways. draft-hardjono-blockchain-interop-arch-02", , <>.
Duffy, K.H., Grant, R., and C. Allen, "BTCR DIDs and DDOs", , <>.
FATF, "International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation - The FATF Recommendations", , <>.
Hardjono, T. and N. Smith, "Decentralized Trusted Computing Base for Blockchain Infrastructure Security, Frontiers Journal, Sepcial Issue on Blockchain Technology, Vol. 2, No. 24", , <>.
Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", , <>.
Hargreaves, Q., Hardjono, T., and R. Belchior, "Secure Asset Transfer Protocol", , <>.
Lodder, M. and D. Hardman, "Clarifications to the DNS Specification", , <>.
[TVDR], "Tezos Verifiable Data Registry", , <>.

Authors' Addresses

Shiping Chen
CSIRO Data61
Thomas Hardjono
Qin Wang
CSIRO Data61