Subject: Re: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (22 June 2021)

From: Michael McBride <[email-masked]>
Date: Thu, 15 Jul 2021 19:22:47 +0000

Hi Thomas,

What's the latest BoF status? Perhaps shooting for BoF at IETF in November? 

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Monday, June 28, 2021 8:16 AM
To: [email-masked]
Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (22 June 2021)

Folks,

Here are the summary notes from yesterday's meeting.

Please feel free to add or make corrections

-- thomas --

----------------------------------------------
Summary Notes from IETF Blockchain Gateway Interoperability group meeting

Date: Tuesday 22 June 2021.

(a) Attendees:

Denis Avrilionis
Shiping Chen
Luke Riley
Rafael Belchior
Miguel Correia
John Robotham
Java Xu
Juan Ignacio Ibanez
Mizan Chowdury
Tom McGarry
Thomas Hardjono

(b) IETF Note Well slide

-- This group meeting operates under IETF IP Rules as described in RFC5378 and RFC8179.

(c) Updates on drafts/docs:

-- Gateway identification & discovery (Shiping/Thomas)

     o  Thank you to Rafael and other folks for inputs.

     o  Nothing more to report today on draft-00, but Shiping & Thomas plan will be working on the next revision (including the diagrams).

-- Crash recovery (Rafael):

     o  No updates to report today, but continuing work on the draft.

-- Log storage using IPFS (Thomas):

     o  Thomas mentioned a meeting with some folks from Protocol Labs (PL), who develop IPFS and Filecoin. The potential is to use IPFS-based storage for logs in crash recovery, possibly via a Standardized APIs. Thomas will extend an invitation to PL for a presentation to this group (e.g. aiming for August).

     o  Denis mentioned that there are various other decentralized storage systems, such as Cassandra (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F1773912.1773922&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934284075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gBnxlYuQn%2BXEs6jvPbfb%2BuieWOdm%2FnMEZxB0lzh6RHo%3D&amp;reserved=0). So having a standardized APIs will help. Denis also mentioned a core concern with on-chain decentralized storage, namely the privacy issues around data (i.e. GDPR in the EU).

-- Escrow models (Luke):

     o  Luke will start writing-up a short draft on the various models for asset escrow/locking. This is the material Luke presented to this group a couple of meetings ago.

(d) Device Attestations Model for Gateways:

-- Since gateways may be handling digital assets carrying significant economic value, it is likely that future infrastructures implementing gateways will require that gateways perform mutual device attestations as part of Phase-1 (as a preliminary to establishing the secure TLS channel between them).

-- In Phase-1, a gateway (e.g. G2 in the destination DLN) must verify different aspects of the digital asset transfer-- each of which could be more easily viewed as different "layers" (sub-phases) of Phase-1. For example, gateway G2 will have to validate the device identity and owner (VASP V1) of gateway G1, and vice versa.  It will have to validate that DLN2 is permitted (legally) and mechanically capable to ingest the asset-type.  It has to validate that the asset has legal standing in the jurisdiction of operation of DLN2 (i.e. not some fake stable-coin or digital assets), etc. etc.

-- Part of validating "device identity" is performing mutual device attestations, where the gateways issues a signed report of its "current state" -- examples of which include the device composition and software stack used by the gateway. A gateway G2 may decline a request from G1 if the gateway G2 is configured with a policy that demands that G1 be operating using a certain approved configuration (i.e. approved set of device configurations).  If a getaway is built using trusted hardware (e.g. TPM, SGX, TrustZone) then part of attestations is proving the presence of the identity-key(s) of the trusted hardware.

-- Thomas explained the Attestation Framework that is being developed in the TCG and the IETF.  Here are some links:

     o  IETF RATS:  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rats-architecture%2F&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934284075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=KURKUkOZqg1q%2Bz33fBDozmmUrZwcar9oGI4aiPRl8aA%3D&amp;reserved=0

     o  The TCG has been working on attestations since early 2000s. A new TCG Attestations will be published soon, but an early spec can be found here:

         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedcomputinggroup.org%2Fwp-content%2Fuploads%2FIWG_Architecture_v1_0_r1.pdf&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934284075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Hnhfh%2FhE5P%2BEDweaMHQfstwfjov9Ww3zpNbkx60D7mU%3D&amp;reserved=0

-- In the context of gateways, each gateway must take-on the role of an Attester. For the Attestation Evidence verification, there may multiple deployment models. In one model, a gateway may take-on the dual role of Attester and of Verifier (i.e. it has an on-board verifier). Another model is for a gateway to offload the verification of the Attestation Evidence to a third-party Verifier Service that serves the DLN (i.e. for G2 in DLN2, there will be Verifier Service VS2 that serves all gateways belonging to DLN2). In this second model, the gateway become truly a Relying Party to the Verifier Service.

-- The policies set within a gateway is referred to as Appraisal Policies for Evidence, and it is defined by the Verifier Owner.  The policies may determined by the owner of the gateway, or it may be determined by the membership of the DLN (e.g. consortium of node owners).

-- A reasonably readable paper that explains the Attestation Framework from TCG and IETF can be found here (nb. it has the same diagram used in the slides):

         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink.springer.com%2Farticle%2F10.1007%2Fs11280-021-00869-4&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934294070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=thgvGxBl6DwX0DXD726gxo0h%2BE10C0sYRnexd49WAVw%3D&amp;reserved=0

(e) Trustworthiness Claims for Gateways:

-- In order to provide semantically interoperable "meanings" to the attestation evidence from different types of trusted hardware, there is another draft in the IETF from Eric Voit (Cisco) defining a number of comparable "Trustworthiness Claims":

   https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voit-rats-attestation-results%2F&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934294070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cmnSCzizKWZfHbDNRyQn9pLQpcIyHjLM1yOFGlddokE%3D&amp;reserved=0

-- For gateways, the use of a standardized set of Trustworthiness Claims allows gateways to quickly appraise the attestation evidences coming from other gateways that employ different trusted hardware.

-- We will revisit this broad topic (i.e. gateway device attestations and trustworthiness claims) again in the future, as this is of core importance to gateways and many applications (e.g. Financial Industry).  Today was just a very quick introduction.

(f) Other items:

-- The group will take a break in July (i.e.  no meetings for July). Thomas will send calendar cancellations for July.

-- Action item to invite Protocol Labs to present to the group regarding IPFS.  

-- Generally, it would be interesting and useful to the group to periodically invite technical presentations pertinent to the area of DLT gateways (nb. the one from Luke on escrow was excellent).

(g) Next meeting:

-- Tuesday August 3rd.

----------------------------------------------------------

-- 
Blockchain-interop mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fblockchain-interop&amp;data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C939e9e3c06d445de734e08d93a47b557%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637604901934294070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5aChC8YnMd1IdunAGojzU3XQy7NJa2N1KQ9HAdS6IsA%3D&amp;reserved=0

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 15 Jul 2021 19:45:09 +0000

Hi Mike,

I think the group needs to do more work on the ODAP protocol and crash-recovery protocol (for ODAP) before we should contemplate a BOF or WG.

We'll have to do the hard work in any case, either now before a BOF or after a BOF.

Best

--thomas

________________________________________
From: Michael McBride [[email-masked]]
Sent: Thursday, July 15, 2021 3:22 PM
To: Thomas Hardjono; [email-masked]
Subject: RE: Summary Notes from IETF Blockchain Gateway Interop meeting (22 June 2021)

Hi Thomas,

Thanks,
mike

-----Original Message-----
From: Blockchain-interop <[email-masked]> On Behalf Of Thomas Hardjono
Sent: Monday, June 28, 2021 8:16 AM
To: [email-masked]
Subject: [Blockchain-interop] Summary Notes from IETF Blockchain Gateway Interop meeting (22 June 2021)

Folks,

-- thomas --

(a) Attendees:

Denis Avrilionis
Shiping Chen
Luke Riley
Rafael Belchior
Miguel Correia
John Robotham
Java Xu
Juan Ignacio Ibanez
Mizan Chowdury
Tom McGarry
Thomas Hardjono

(b) IETF Note Well slide

-- Escrow models (Luke):

(f) Other items:

(g) Next meeting:

-- Tuesday August 3rd.