Re: [Blockchain-interop] Scope of Work

Thomas Hardjono <hardjono@mit.edu> Tue, 13 October 2020 19:48 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 E42613A00C9 for <blockchain-interop@ietfa.amsl.com>; Tue, 13 Oct 2020 12:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 9sw1Qu8j6Xjr for <blockchain-interop@ietfa.amsl.com>; Tue, 13 Oct 2020 12:48:29 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 8BA303A005E for <blockchain-interop@ietf.org>; Tue, 13 Oct 2020 12:48:29 -0700 (PDT)
Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 09DJlN76015557; Tue, 13 Oct 2020 15:48:28 -0400
Received: from w92expo23.exchange.mit.edu (18.7.74.77) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 13 Oct 2020 15:47:50 -0400
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; Tue, 13 Oct 2020 15:47:57 -0400
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; Tue, 13 Oct 2020 15:47:57 -0400
From: Thomas Hardjono <hardjono@mit.edu>
To: "Aetienne.Sardon@swisscom.com" <Aetienne.Sardon@swisscom.com>, "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
Thread-Topic: Scope of Work
Thread-Index: AdahkITafN9dND8YQcKuDjiKcNVmcgAB3LJy
Date: Tue, 13 Oct 2020 19:47:57 +0000
Message-ID: <7eca6be02ea74abc808bdd74d1ab42db@oc11expo23.exchange.mit.edu>
References: <GV0P278MB00204AE517921470AE1057C38B040@GV0P278MB0020.CHEP278.PROD.OUTLOOK.COM>
In-Reply-To: <GV0P278MB00204AE517921470AE1057C38B040@GV0P278MB0020.CHEP278.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/Alg4TcJQhcdD1ObXhTySjK0-7Po>
Subject: Re: [Blockchain-interop] Scope of Work
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: Tue, 13 Oct 2020 19:48:31 -0000

Hi Aetienne,

>> Regarding the scope: I was wondering whether we 
>> should also include other interoperability issues apart 
>> from asset transfers, such as referencing data 
>> between blockchains (or from a blockchain to a legacy system)?

Yes, for sure -- the model describes in the architecture draft calls these references and data (on-chain and off-chain) generically as "blockchain resources".

For example, if a third party entity is used to "price"  a virtual asset (e.g. economic pricing or estimate done by a bank or FI) prior to the asset transfer, then the transfer-payload between G1 and G2 could (must) include a link (e.g. URL or hash) to the claim signed by the  third party.

This means that G1 must sign the payload using its entity public key pair (not the transaction public key pair).  Here G1 (i.e. the VASP owner of G1) is essentially asserting the truthfulness of the link to the resource.

Best


-- thomas --



________________________________________
From: Blockchain-interop [blockchain-interop-bounces@ietf.org] on behalf of Aetienne.Sardon@swisscom.com [Aetienne.Sardon@swisscom.com]
Sent: Tuesday, October 13, 2020 2:45 PM
To: blockchain-interop@ietf.org
Subject: [Blockchain-interop] Scope of Work

Hi all, great meeting you all in today's kickoff call!

Regarding the scope: I was wondering whether we should also include other interoperability issues apart from asset transfers, such as referencing data between blockchains (or from a blockchain to a legacy system)?

The reason why I'm asking is because a new DLT law is expected to enter into force in Switzerland next year, which will require that for all DLT-based financial instruments corresponding investor documentation (e.g. prospectus) shall be made available either directly on the given ledger or by referring to an outside data storage (which could be a legacy system as mentioned on slide 10 point 2). The latter case obviously creates an interoperability problem. So far the legislator has only outlined that there needs to be a unique pointer/identifier (e.g. a hash of the document), to ensure integrity of the accompanying external documentation. But apart from that there are currently no specific technical guidelines on how an interoperable on-/off-ledger pointer mechanism shall work. IMO our IETF working group could be a great platform to discuss and provide some guidance. What do you think?

Best regards
Aetienne