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

From: Michael McBride <[email-masked]>
Date: Fri, 29 Jan 2021 03:50:16 +0000

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

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jan 2021 13:23:15 +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 [[email-masked]] on behalf of Michael McBride [[email-masked]]
Sent: Thursday, January 28, 2021 10:50 PM
To: [email-masked]
Subject: [Blockchain-interop] Data Discovery and DLT Gateways

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.

mike