Re: [Blockchain-interop] Scope of Work

Rafael André Pestana Belchior <rafael.belchior@tecnico.ulisboa.pt> Tue, 13 October 2020 20:16 UTC

Return-Path: <rafael.belchior@tecnico.ulisboa.pt>
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 67EF83A1243 for <blockchain-interop@ietfa.amsl.com>; Tue, 13 Oct 2020 13:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tecnico.ulisboa.pt
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 VtRWe_iRQo_D for <blockchain-interop@ietfa.amsl.com>; Tue, 13 Oct 2020 13:16:53 -0700 (PDT)
Received: from smtp1.tecnico.ulisboa.pt (smtp1.tecnico.ulisboa.pt [IPv6:2001:690:2100:1::15]) (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 9BF433A122C for <blockchain-interop@ietf.org>; Tue, 13 Oct 2020 13:16:37 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTP id CD1C56030C0E; Tue, 13 Oct 2020 21:16:35 +0100 (WEST)
X-Virus-Scanned: by amavisd-new-2.11.0 (20160426) (Debian) at tecnico.ulisboa.pt
Received: from smtp1.tecnico.ulisboa.pt ([127.0.0.1]) by localhost (smtp1.tecnico.ulisboa.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id rjXzKjlHh9zq; Tue, 13 Oct 2020 21:16:32 +0100 (WEST)
Received: from mail1.tecnico.ulisboa.pt (mail1.ist.utl.pt [IPv6:2001:690:2100:1::b3dd:b9ac]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTPS id 9DB916030C02; Tue, 13 Oct 2020 21:16:32 +0100 (WEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tecnico.ulisboa.pt; s=mail; t=1602620192; bh=LQsUJ5Jyf0jlL12hnSYIImcRPRgbypq/B8ewcBp0iew=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Mv6HOh33rninQy2E0c9bL6c/6DObFdCIBwxYyDRL5m+G/wnIGzC7/QRsVcO6FKC8k wvG3csf+kc7Sgl3MF8YfSl45KlVMljLS6yHOWnfGrkrelwyQmvDLEEvByeckP0pJUX 2PGTCqATXOCiXiSLpFgGxTSEjqwK97uxoy/4DabU=
Received: from webmail.tecnico.ulisboa.pt (webmail4.tecnico.ulisboa.pt [IPv6:2001:690:2100:1::8a3:363d]) (Authenticated sender: ist180970) by mail1.tecnico.ulisboa.pt (Postfix) with ESMTPSA id 2AF6C36007D; Tue, 13 Oct 2020 21:16:32 +0100 (WEST)
Received: from [81.193.66.22] via vs1.ist.utl.pt ([2001:690:2100:1::33]) by webmail.tecnico.ulisboa.pt with HTTP (HTTP/1.1 POST); Tue, 13 Oct 2020 21:16:32 +0100
MIME-Version: 1.0
Date: Tue, 13 Oct 2020 21:16:32 +0100
From: =?UTF-8?Q?Rafael_Andr=C3=A9_Pestana_Belchior?= <rafael.belchior@tecnico.ulisboa.pt>
To: Thomas Hardjono <hardjono@mit.edu>
Cc: Aetienne.Sardon@swisscom.com, blockchain-interop@ietf.org
In-Reply-To: <7eca6be02ea74abc808bdd74d1ab42db@oc11expo23.exchange.mit.edu>
References: <GV0P278MB00204AE517921470AE1057C38B040@GV0P278MB0020.CHEP278.PROD.OUTLOOK.COM> <7eca6be02ea74abc808bdd74d1ab42db@oc11expo23.exchange.mit.edu>
Message-ID: <738016c34ecd78b672da2ab72e3d28cc@tecnico.ulisboa.pt>
X-Sender: rafael.belchior@tecnico.ulisboa.pt
User-Agent: Roundcube Webmail/1.3.15
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/Gu3RfZl97EboDK2DPWcgZNXr8_Y>
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 20:17:03 -0000

Hello All,
Great to e-meet you.

The fact that G1 signs the payload using its key-pair is a good start to 
ensure accountability. We need to discuss if the protocol should assure 
accountability in case of dispute, or if it suffices to coordinate 
communication.

Cheers,
--rafael

A 2020-10-13 20:47, Thomas Hardjono escreveu:
> 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

-- 
Rafael Belchior
Ph.D. student in Computer Science and Engineering, Blockchain - Técnico
Lisboa
https://rafaelapb.github.io/
https://www.linkedin.com/in/rafaelpbelchior/