Re: [Blockchain-interop] Scope of Work

Miguel Correia <miguel.p.correia@tecnico.ulisboa.pt> Mon, 19 October 2020 14:18 UTC

Return-Path: <miguel.p.correia@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 0CCA33A00D9 for <blockchain-interop@ietfa.amsl.com>; Mon, 19 Oct 2020 07:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 LE_Fj8qsNC9Z for <blockchain-interop@ietfa.amsl.com>; Mon, 19 Oct 2020 07:18:16 -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 4B00E3A0639 for <blockchain-interop@ietf.org>; Mon, 19 Oct 2020 07:18:15 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTP id 3DDB66007C1D for <blockchain-interop@ietf.org>; Mon, 19 Oct 2020 15:18:13 +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 U2G232yzfs2u for <blockchain-interop@ietf.org>; Mon, 19 Oct 2020 15:18:10 +0100 (WEST)
Received: from mail1.tecnico.ulisboa.pt (mail1.ist.utl.pt [193.136.128.10]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTPS id EABEC6003C04 for <blockchain-interop@ietf.org>; Mon, 19 Oct 2020 15:18:09 +0100 (WEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tecnico.ulisboa.pt; s=mail; t=1603117090; bh=XUsx7nizd9E8KjMIplrTQVMhZcNIIYjcgwW2u7xCnVg=; h=From:Subject:Date:References:To:In-Reply-To; b=LwkTIlyQ9dyP6d3AATEi/0oe4H7gKQPGQwxIM8c5wbY27sFZ7Z6Uac0sYnzyen9nP PxyvZEPwH7loVX1CgSKwEmirPthkcG1vsJC3l1fpW1HGfz9ORSNyPutMcgmNxjTi2G 6/SWsri9qPTK7uYNtRHLuqjcRcB0tLDiNr2lHMoY=
Received: from [IPv6:2001:818:d859:2000:8529:1495:242f:870b] (unknown [IPv6:2001:818:d859:2000:8529:1495:242f:870b]) (Authenticated sender: ist130598) by mail1.tecnico.ulisboa.pt (Postfix) with ESMTPSA id C61E8360071 for <blockchain-interop@ietf.org>; Mon, 19 Oct 2020 15:18:09 +0100 (WEST)
From: Miguel Correia <miguel.p.correia@tecnico.ulisboa.pt>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 19 Oct 2020 15:18:09 +0100
References: <GV0P278MB00204AE517921470AE1057C38B040@GV0P278MB0020.CHEP278.PROD.OUTLOOK.COM> <7eca6be02ea74abc808bdd74d1ab42db@oc11expo23.exchange.mit.edu> <738016c34ecd78b672da2ab72e3d28cc@tecnico.ulisboa.pt> <bf1ebb1f480345e29b6de6d373c47d5e@oc11expo23.exchange.mit.edu> <LO2P123MB17593FDB20FAD4B66536661CFC020@LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM> <e0dd7d1bdbf04e77b988d828526b00ee@oc11expo23.exchange.mit.edu> <LO2P123MB175969F04A7F69B2B6061FB9FC1E0@LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM> <118191732a8f453da4ce5281af5c116c@oc11expo23.exchange.mit.edu>
To: "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
In-Reply-To: <118191732a8f453da4ce5281af5c116c@oc11expo23.exchange.mit.edu>
Message-Id: <CECEF2D9-F216-4B5C-BC22-E25C67563282@tecnico.ulisboa.pt>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/IcYozjg_2vU0Tpej6GUsjmSoJcE>
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: Mon, 19 Oct 2020 14:18:19 -0000

Hi,

All this looks great!

I was analysing the protocol and two questions come to mind:

- what are the properties we aim to guarantee for asset transfer? I guess we need something like (very draftish):
	- Non-triviality: no asset transfer occurs if its owner does not require that transfer.
	- Consensus: no asset transfer occurs without agreement from G1 and G2.
	- Termination: asset transfer is concluded when the asset no longer exists in B1 and is represented in B2.

- what are the failure assumptions? Is it possible for G1 and G2 to fail during the process? If they fail, do we assume they later recover?

I need this kind of details to check the correctness of the asset transfer protocol. 

Best,
Miguel


> On 19 Oct 2020, at 14:53, Thomas Hardjono <hardjono@mit.edu> wrote:
> 
> 
> Hi Martin,
> 
>>>> I like that, I think that checking for compatible profiles on 
>>>> the application and gateway sides is a key validation. 
> 
> Yes, good idea -- Gateways G1 and G2 need to verify that they are both referring to the same asset-profile (independent of the actual instances of the asset being transferred, and independent who is the current owner of those instances).
> 
> The asset-profile could be a signed JSON file that lists factual assertions about the virtual asset and links to verify these assertions.  Something like:
> 
> -- Profile name/identifier
> 
> -- Asset code/number (e.g. “USDT, “WIR”, etc.).
> 
> -- Asset issuing authority (e.g. “EU ECB”, “DTCB NYC”, etc.) and jurisdiction.
> 
> -- URL to validate the above.
> 
> -- Signature of profile author (nb. author could be issuing authority).
> 
> -- etc.
> 
> 
> 
>>>> Do we also need a naming scheme or identifier format 
>>>> for asset profiles / resource profiles?
> 
> Yes, I think we do need this.  Any suggestions?
> 
> 
> 
>>>> Looking at the section on negotiation of security 
>>>> protocols and parameters, should we also encode this 
>>>> as a set of authorisation profiles? 
>>>> This would allow easy referenceability for common 
>>>> configurations, and allow follow-on work to 
>>>> create new security profiles (e.g. a PQ profile).
> 
> 
> Good idea. Having pre-baked authorization profiles would help speed-up transfers. 
> 
> 
> 
> -- thomas --
> 
> 
> 
> ________________________________________
> From: Martin Hargreaves [martin.hargreaves@quant.network]
> Sent: Monday, October 19, 2020 5:18 AM
> To: Thomas Hardjono
> Cc: blockchain-interop@ietf.org
> Subject: RE: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
> 
> I like that, I think that checking for compatible profiles on the application and gateway sides is a key validation. Do we also need a naming scheme or identifier format for asset profiles / resource profiles?
> 
> Looking at the section on negotiation of security protocols and parameters, should we also encode this as a set of authorisation profiles? This would allow easy referenceability for common configurations, and allow follow-on work to create new security profiles (e.g. a PQ profile).
> 
> Best,
> 
> Martin
> 
> -----Original Message-----
> From: Thomas Hardjono <hardjono@mit.edu>
> Sent: Sunday, October 18, 2020 2:56 PM
> To: Martin Hargreaves <martin.hargreaves@quant.network>
> Cc: blockchain-interop@ietf.org
> Subject: [EXTERNAL] RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
> 
> CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.
> 
> 
> Hows this for a definition of an asset-profile:
> 
> Asset profile: The set of information and resources describing a virtual asset, including the asset name/code, issuing authority, denomination, jurisdiction, and the URLs and mechanisms to validate the information. The asset profile is independent from the specific instantiation of the asset (on a blockchain and otherwise) and independent from the asset ownership information.
> 
> 
> The basic idea is that the gateway transfer protocol should work for any number of asset-profiles.
> 
> -- An asset-profile should have all the relevant links/URLs to permit anyone to validate it. Kind of a "metadata" (e.g. in JSON) fully describing a virtual asset.
> 
> -- For non-private assets, anyone should be able to validate the statements or assertions stated in the asset-profile.
> 
> -- An asset-profile should not incorporate any ownership information (i.e. ownership of instances of the asset).
> 
> 
> 
> 
> 
> -- thomas --
> 
> ________________________________________
> From: Martin Hargreaves [martin.hargreaves@quant.network]
> Sent: Thursday, October 15, 2020 5:09 AM
> To: Thomas Hardjono; Rafael André Pestana Belchior
> Cc: Aetienne.Sardon@swisscom.com; blockchain-interop@ietf.org
> Subject: RE: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
> 
> Hi both,
> 
> I'm keen on this approach, it lets us have a well-bounded scope for the coordination of communication, and a clear framework for creation of profiles. I suspect some profiles will require significant domain expertise, particularly if the profile integrates existing domain specific data standards (e.g. ISO20022, FIX or a host of others). I think allowing industry groups to become compliant by creating profiles should provide a level of flexibility that can accelerate adoption of the underlying protocol.
> 
> All the best,
> 
> Martin
> 
> -----Original Message-----
> From: Blockchain-interop <blockchain-interop-bounces@ietf.org> On Behalf Of Thomas Hardjono
> Sent: Tuesday, October 13, 2020 9:43 PM
> To: Rafael André Pestana Belchior <rafael.belchior@tecnico.ulisboa.pt>
> Cc: Aetienne.Sardon@swisscom.com; blockchain-interop@ietf.org
> Subject: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
> 
> [EXTERNAL EMAIL] DO NOT CLICK links or attachments unless you recognise the sender and know the content is safe.
> 
> Thanks Rafael.
> 
> As I mentioned, maybe there will need to be a kind of "payload profile" that defines the meaning of the component/part of the payload according to the type of asset and policies/conditions.
> 
> This profile (specification) would include links to the resources (off-chain, or on-chain on ledger L1) that must be delivered from G1 to G2 in order to permit G2 to evaluate and accept the payload.
> 
> So for example, if the virtual asset was stablecoin X backed by some securities, then the "payload profile for X" specification may mandate inclusion of a URL to the signed securities (i.e. digitized securities). The profile may even include the Jurisdictions where the profile is honored.
> 
> Just a thought.
> 
> 
> -- thomas --
> 
> 
> 
> 
> ________________________________________
> From: Rafael André Pestana Belchior [rafael.belchior@tecnico.ulisboa.pt]
> Sent: Tuesday, October 13, 2020 4:16 PM
> To: Thomas Hardjono
> Cc: Aetienne.Sardon@swisscom.com; blockchain-interop@ietf.org
> Subject: Re: [Blockchain-interop] Scope of Work
> 
> 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/
> 
> --
> Blockchain-interop mailing list
> Blockchain-interop@ietf.org
> https://www.ietf.org/mailman/listinfo/blockchain-interop
> This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.
> This message is intended solely for the addressee and may contain privileged and confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment. Quant Network does not guarantee that this email has not been intercepted and amended or that it is virus free.
> 
> -- 
> Blockchain-interop mailing list
> Blockchain-interop@ietf.org
> https://www.ietf.org/mailman/listinfo/blockchain-interop