Re: [Blockchain-interop] Data Discovery and DLT Gateways

Thomas Hardjono <hardjono@mit.edu> Fri, 29 January 2021 13:23 UTC

Return-Path: <hardjono@mit.edu>
X-Original-To: blockchain-interop@ietfa.amsl.com
Delivered-To: blockchain-interop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597BE3A0CC5 for <blockchain-interop@ietfa.amsl.com>; Fri, 29 Jan 2021 05:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCzc9L0M_tzq for <blockchain-interop@ietfa.amsl.com>; Fri, 29 Jan 2021 05:23:20 -0800 (PST)
Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52B63A0CC0 for <blockchain-interop@ietf.org>; Fri, 29 Jan 2021 05:23:20 -0800 (PST)
Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 10TDN3A9029321; Fri, 29 Jan 2021 08:23:17 -0500
Received: from w92expo23.exchange.mit.edu (18.7.74.77) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 29 Jan 2021 08:22:47 -0500
Received: from oc11expo23.exchange.mit.edu (18.9.4.88) by w92expo23.exchange.mit.edu (18.7.74.77) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jan 2021 08:23:15 -0500
Received: from oc11expo23.exchange.mit.edu ([18.9.4.88]) by oc11expo23.exchange.mit.edu ([18.9.4.88]) with mapi id 15.00.1365.000; Fri, 29 Jan 2021 08:23:15 -0500
From: Thomas Hardjono <hardjono@mit.edu>
To: "michael.mcbride@futurewei.com" <michael.mcbride@futurewei.com>, "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
Thread-Topic: Data Discovery and DLT Gateways
Thread-Index: Adb17fd0e7jMxRVeRma+mVOlQP1kUwAUFLec
Date: Fri, 29 Jan 2021 13:23:15 +0000
Message-ID: <99778597f20d437e85d2ca27021bc78f@oc11expo23.exchange.mit.edu>
References: <BYAPR13MB258236A4C0AEC520489494E5F4B99@BYAPR13MB2582.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB258236A4C0AEC520489494E5F4B99@BYAPR13MB2582.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [73.167.220.69]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/RqFZpYENcokmKjl4Tidww1sJDtQ>
Subject: Re: [Blockchain-interop] Data Discovery and DLT Gateways
X-BeenThere: blockchain-interop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Blockchain Gateway Interoperability Protocol <blockchain-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/blockchain-interop/>
List-Post: <mailto:blockchain-interop@ietf.org>
List-Help: <mailto:blockchain-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/blockchain-interop>, <mailto:blockchain-interop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2021 13:23:22 -0000

Hi Mike,

Yes this a good point.

>>> My understanding is the DLT Gateways will be given 
>>> a permissioned view of assets/transactions, 
>>> that they are requested to transfer, within their attached DLT domain. 
>>> And GW’s discovering assets/transactions, not explicitly provided, 
>>> within the DLT domain is out of scope.

Right now I think we are assuming that at least the GW is a node in the DLT (equivalent to other nodes), which means it has the capability to read/write to its own ledger. So for a permisisoned (private) DLT network, we assume it has the same privileges as other nodes in its own network.

An issue that is rarely discussed in the various DLT communities is:  (i) post-event audit and (ii) the the discovery of the data "parts" needed to validate the transfer after the asset movement.  The ledger in the DLT will not (unable to) hold all the relevant information pertaining to a previous asset transfer. So there need to be ways to search/discover these.

The data parts include:  

-- relevant DLT transaction public-keys of the involved entities (i.e. public-keys (addresses) used on both DLTs).

-- relevant entity public-keys & X.509 certs (Originator, owner of gateway G1, owner of gateway G2, Beneficiary). This is similar to the X509 certs and cert-profiles used in the SWIFT banking network.

-- relevant asset-related JSON documents (e.g. asset profiles).


>>> Some of us are working on data discovery (draft-mcbride-data-discovery-problem-statement, 
>>> mcbride-edge-data-discovery-overview, bernardos-sfc-discovery) within the COIN RG. 
>>> It may become necessary for the GW (or other network element.. if permitted) 
>>> to discover the data (asset, resource, service…) in order to transfer the required asset.


Things become more interesting if gateways are implemented trusted hardware or secure enclaves, and the Phase-1 exchange includes attestations of gateways to one another. This means that data discovery now includes device-related information, similar to the edge-computing device data discovery.


-- thomas --

________________________________________
From: Blockchain-interop [blockchain-interop-bounces@ietf.org] on behalf of Michael McBride [michael.mcbride@futurewei.com]
Sent: Thursday, January 28, 2021 10:50 PM
To: blockchain-interop@ietf.org
Subject: [Blockchain-interop] Data Discovery and DLT Gateways

We discussed this a bit on the call last week and I wanted to at least have it described on the list.

My understanding is the DLT Gateways will be given a permissioned view of assets/transactions, that they are requested to transfer, within their attached DLT domain. And GW’s discovering assets/transactions, not explicitly provided, within the DLT domain is out of scope.

Some of us are working on data discovery (draft-mcbride-data-discovery-problem-statement, mcbride-edge-data-discovery-overview, bernardos-sfc-discovery) within the COIN RG. It may become necessary for the GW (or other network element.. if permitted) to discover the data (asset, resource, service…) in order to transfer the required asset.

This may be something we can identify to work on after the initial milestones are achieved.

mike