Gateway Identification and Discovery

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) . 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 . 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 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 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]. Decentralized ledger network (DLN): A blockchain system or an implementation of a decentralized ledger technology (DLT) consisting nodes that shares a common set of resources. This term is used generically to refer to the collection of nodes as an autonomous system (AS). DLN identification number: This is the unique network identification for a DLN. This is akin to the AS-number issued by ARIN in North America for autonomous systems operated by Internet Service Providers (ISP). Device identity: This is the unique public-private key pair that is bound to the device (e.g. hardware) of the gateway. Examples include the IEEE 802.1AR Secure Device Identity [DevID] and the TPM EK/AIK key pair [TPM]. The device identity public key may be represented using an X.509 certificate. Gateway service endpoint: The URL or URI at the gateway device that provides gateway related services, such as asset transfer/migration services. See for details about secure asset transfer protocol. Service endpoint identity: This is the unique public-private key pair bound to the protocol service end-point of the gateway function. This key-pair is used in the establishment of a secure channel with a peer gateway (e.g., TLS). The endpoint identity public key should be represented using an X.509 certificate, which unambiguously states the purpose of the endpoint. Owner identity: This is the unique public-private key pair of the entity who legally owns and operates the gateway. For clarity this entity is referred to as a virtual asset service provider (VASP). The VASP identity public key should be represented using an X.509 certificate, possibly including extended fields such as those found in Extended Validation (EV) X.509 certificates [CAB]. Organization identity: This is a Legal Entity Identifier [LEI] or other identifier linking resource ownership to real world entity. Any schema for identifying DLT Gateway owners may be implemented , such as LEI Directory, closed group memberships, SWIFT BIC, etc. Decentralised identifiers (DiD): is a type of identifier that enables a verifiable, decentralized digital identity. DiD consists of an unique identifier string associated with a identifier documents, in which all required properties can be described in a key-value style.

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]).

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

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.

| 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: 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 and . DNS - Domain Naming Service : 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.,

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.

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

In addition to the basic security setting mentioned above, the following technologies can also be considered as either enhancement or alternatives of security settings: HTTPS/TLS: Whenever using HTTP [RFC2616] for the protocol execution, HTTPS/TLS [RFC2660] must be enabled by default against eavesdropping attack. DNSSEC: is a set of extensions to DNS that uses asymmetric cryptography to provide origin authentication and integrity checking for DNS data [RFC2535]. DNSSEC ensures not just the origin of the DNS record, but also its integrity, which thus enhances the security and trust of the blockchain gateway queries if adopting DNSSEC. Trusted hardware and attestations: Gateways may be implemented in computer systems possessing a secure processor (e.g., TPM) [ISO/IEC 11889] or secure enclave (e.g., SGX). For example, server machines can store security keys and conducts common security operations for hardware authentication and authorization. The use of device-unique public key pairs bound to these types of trusted hardware, coupled with their attestation capabilities, may significantly enhance the security and trust between the gateways to conduct blockchain asset transfer services collaboratively. Given the important roles that the DLNs? gateways will play, their IP address should be regarded as ASN (Autonomous System Number) and assigned by IANA's RIRs (Regional Internet Registries), such as ARIN (the American Registry for Internet Numbers) and dedicated to DLN gateway servers. This will greatly enhance the security and trust of the BGSP's services, due to the high bar to secure an ASN.