Subject: [Blockchain-interop] Summary Notes from IETF DLT Gateway Interop meeting (1 February 2022)

From: Thomas Hardjono <[email-masked]>
Date: Sat, 19 Feb 2022 14:45:47 +0000

Folks,

Here is the summary notes from our meeting on Tue 1 Feb 2022 -- apologies for the delay.

I'd like to extend a big thank you to Bishakh and Sandip for an excellent presentation. The link to their slides are below.

Please feel free to add/correct, as I may have misheard some of the features/aspects of their design.

-- thomas --

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

Date: Tuesday 1 February 2022

(a) Attendees:

Venkatraman Ramakrishna
Dhinakaran Vinayagamurthy
Krishna N
Vinayaka D Pandit
Rafael Belchior
Andre Augusto
Gang Wang
Denis Avrilionis
Martin Hargreaves
Claire Facer
Luke Riley
John Robotham
Bishakh Ghosh
Sandip Sandip Chakraborty
Qin Wang
Shiping Chen
Thomas Hardjono

(b) IETF Note Well slide

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

(c) Presentation on Blockchain Network Identity & Discovery (Bishakh/Sandip).

-- Slides are here:  https://bit.ly/3h0WBiy

-- Bishakh & Sandip gave a presentation regarding the need for identifying DLT networks in the context of a cross-chain transaction (e.g. data transfer) between two Network A and Network B.  For example one network could be a trade logistics ledger while the other network could be a trade finance ledger.

-- The overall goal is to find a decentralized way of sharing trust/certification information across two DLTs, relying on existing identity records and credentials possessed by network members. The proposal utilizes existing standards in the area, including decentralized identifiers, DID registries, Verifiable Credentials/Providers.

-- Currently entity identities are localized within closed networks, and thus it is difficult for an entity in DLT Network A to obtain validation about the identity (and digital signatures) of another entity in DLT Network B. The supporting information (manifestation) that bound the digital identity to the real-world (legal) entity is outside these networks.

-- Desirable goals/features: DLT agnostic; No dependency on a central identity registry; Networks must retain their autonomy; Minimal change to existing code and configurations.

-- The design logically separates an "Identity Plane" from the "Data Plane", and each network participant is assumed to have an SSI at the Identity Plane (i.e. has a VC that can be validated).

-- The proposal uses combined Trust Anchors based on an identity-validation point, referred to as Validators: Organization Identity validators (OIV) and Participant Membership Validators (PMV). The PMV attests that an entity is a member in a DLT network.

-- At the identity plane, there is assumed several Identity Interoperation Network (IIN), where within a given IIN there will be (for each participant) a copy of their Real-World DID, VC Auth Key, etc.  The IIN will also contain the OIV and PMV that allows them to provide validations for the identity of the entities in that IIN.

-- A given DLT network may have participants whose identity (at the identity layer) is anchored-up to *multiple* IINs. This leads to an many-to-many arrangement between identities at the Data Plane and the Identity Plane.

-- This results in a Distributed Identity Infrastructure for DLT networks.

-- Going back to our earlier case of a data-transfer between entities in DLT Network A and B, when entities in these respective DLT networks need proof of verification (of their respective entities), they can employ IINs as their "agents" with the task of mutually validating the entities in DLT Network A (Destination) and DLT Network B (Source).

-- This leads to the possible new construct called the "Network-DID" that is the basis to provide different ways of creating and discovering network groups (instead of depending on one -- or few -- trust anchors).

-- The creation of a Network-DID Document requires attestation by each network participant, with the aid of a DID Controller Group.  The DID Subject in the document is in fact the DLT Network itself (e.g. "did::iin::tradelens" for the commercial TradeLens DLT).

-- The IIN Ledger validates each participant's signature (upon the Document) by resolving their individual DIDs/VCs.

-- Any updates to a Network DID must follow the defined policies (updatePolicy), and requires the attestation of the members to satisfy the rules stated in the update policy.

-- Discovery of a DLT Network can be done via its Network-DID, where the Network-DID Document can be made globally available via various means (e.g. websites, advertising).

-- Given a Network-DID Document (which is publicly readable), anyone can resolve the entries within the Document leading to the DIDs of the individual participants of that network (and each of those participants can in turn be validated using their own respective VCs).  In effect, the IIN DID registry becomes a kind of name resolver for Network-DIDs.

(d) Future meetings (bi-weekly):

-- Tuesday February 15, 2022 -- presentation by Gang Wang (InterTrust).

-- Tuesday March 1, 2022

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

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 27 Feb 2022 17:44:39 +0000

Folks,

Here is the summary notes from our meeting on Tue 15 Feb 2022.

I'd like to extend a big thank you to Gang Wang for his presentation. 

The link to his slides are in the notes.

-- thomas --

Date: Tuesday 15 February 2022

(a) Attendees:

Peter Somogyvari
Tom McGary
Claire Facer
Bishakh Ghosh
Sandip Chakraborty
Gang Wang
Denis Avrilionis
Qin Wang
Krishnasuri N
John Robotham
Rafael Belchior
Venkatraman Ramakrishna

(b) IETF Note Well slide

(c) Presentation on Blockchain Interoperability (by Gang Wang, InterTrust)

-- Gang Wang's slides can be found here :  https://bit.ly/3JRrhiy

-- Gang Wang gave a presentation about the current challenges in interoperabiity across blockchains, and described a possible solution based on two primitives:  (i)  a (k, n)-threshold signature signatures and (ii) use of Trusted Hardware.  The threshold signature scheme (TSS) is used within an MPC (Multi-Party Computation). Note that this is different from multi-sig.

-- The proposal uses cross-AS (i.e. cross gateway) threshold signatures for integrity and atomicity.  The assumption here is that the devices (i.e. gateways) employ trusted hardware, thereby "rooting" the trust in the difficulty of extracting keying material from the hardware.

-- Message passing across blockchains is performed asynchronously (using paired or opposite operations): lock and unlock.  The relay transaction across the two AS-X and AS-Y carries proof from the trusted hardware.

-- The protocol is a 4-step protocol (following the basic 4-pahse atomic protocol): Setup, Commit, Verification, Abort.  It employs the 2-Phase Commit and hash-locking scheme.

-- The security analysis is based on the setup of the BFT protocol used to achieve consensus.  

-- Please contact Gang Wang for more detailed analysis on both Safety and Liveness, as well as the trusted services among ASs.

(d) Future Meetings

-- Tuesday 1 March, 2022.

-- Tuesday 15 March, 2022.

-- IETF113 week:  March 20-25, 2022

-- Tuesday March 29, 2022.