Re: [Blockchain-interop] [EXTERNAL] Re: Scope of Work

Martin Hargreaves <martin.hargreaves@quant.network> Thu, 15 October 2020 09:09 UTC

Return-Path: <martin.hargreaves@quant.network>
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 CAF443A13BA for <blockchain-interop@ietfa.amsl.com>; Thu, 15 Oct 2020 02:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=quant.network
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 rcB-1ORFmanG for <blockchain-interop@ietfa.amsl.com>; Thu, 15 Oct 2020 02:09:45 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110076.outbound.protection.outlook.com [40.107.11.76]) (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 860763A13A0 for <blockchain-interop@ietf.org>; Thu, 15 Oct 2020 02:09:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iPc83s6yVMG/Gw/wZmIF3+rGicybGZoP7r0O9povjm3KhfCechcMIrzx5zyCFAs8tavFK9Uj6r58+hINocjBKfXw6ZbpW2+WXYIqjRN6Y+GK1LGxssXTUE/BXZ7gbQHG38o59gAq80PLmWbXs9fZAVLw/Esb4KvJgc/U0MWJ9Xlm/+n1DpiZpTI3bBonbp9xFnJw9meLMFCKnWb+5BtZfw5zKGEDYv2TphS/BPZ3hJtY3NsjmeK9S7oRspTsA9b3iF2rQ/gGEhhZq8elYR/En7jNo6UZv4M2QO181YAUMcd5J9nHda2B6m8D94bkvvNinJUz2018k3ENAtxyu2A14g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5OQOBuUtadS0urk14YvlIUsUv/Jd/a81WxYeIzigqaI=; b=Gw2NDj1wQBWQYiHPol72wYK9G+naTDIH/JzY8VHb58a7kEW9CMJ+OTDsxr6mXNQqRPBJy2YmvmBlCeyM80CxEMd6j7UUmGAg2tBU4PBCrkJQxWZVYXsseBIxJVLqYDATJMtPjRsKPYhI6+Oz7qDUd2bEfcWF63ZW7/VoJVY0r6LD+69PgAevcIKWPR/szOs5XCjw5yM5xk13qu62cTSgj+Bf79Be37Qyiw+2JJSkIXi6NIQ7xfmnsnPLeLQRyaRZV+NTKMQuybrAWh+596ZZ2ngBqVVzxnV7rGYfAtn2JGVsqtEAeTgMVy2kpLeeO5pZQwm+hszcHfwoE38qjghIZA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=quant.network; dmarc=pass action=none header.from=quant.network; dkim=pass header.d=quant.network; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quant.network; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5OQOBuUtadS0urk14YvlIUsUv/Jd/a81WxYeIzigqaI=; b=XaS0h9Pygp9ZJW0U0ZRGtWN9061S8iv5RKg9UrDMKKK6gQbSbNvldaD6Wyab0snsZ7ydGhWWoOLDNj/RP5acdweTO9Pvv+5oS4qVqMScpWcUIUxAkE9h4ikObNKqXkdFMx6ZvzBXbX54OFGp+qKf40QfvCXwSO5YIWJP5eXn0N0=
Received: from LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c0::15) by LO2P123MB2191.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:c9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.24; Thu, 15 Oct 2020 09:09:24 +0000
Received: from LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM ([fe80::b861:bf2:a7d7:2f8]) by LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM ([fe80::b861:bf2:a7d7:2f8%7]) with mapi id 15.20.3477.021; Thu, 15 Oct 2020 09:09:24 +0000
From: Martin Hargreaves <martin.hargreaves@quant.network>
To: Thomas Hardjono <hardjono@mit.edu>, =?iso-8859-1?Q?Rafael_Andr=E9_Pestana_Belchior?= <rafael.belchior@tecnico.ulisboa.pt>
CC: "Aetienne.Sardon@swisscom.com" <Aetienne.Sardon@swisscom.com>, "blockchain-interop@ietf.org" <blockchain-interop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Blockchain-interop] Scope of Work
Thread-Index: AQHWoZnYV4MJewd9VUah87q0dcH4HamV+EcAgAAHWICAAmD5EA==
Date: Thu, 15 Oct 2020 09:09:24 +0000
Message-ID: <LO2P123MB17593FDB20FAD4B66536661CFC020@LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM>
References: <GV0P278MB00204AE517921470AE1057C38B040@GV0P278MB0020.CHEP278.PROD.OUTLOOK.COM> <7eca6be02ea74abc808bdd74d1ab42db@oc11expo23.exchange.mit.edu>, <738016c34ecd78b672da2ab72e3d28cc@tecnico.ulisboa.pt> <bf1ebb1f480345e29b6de6d373c47d5e@oc11expo23.exchange.mit.edu>
In-Reply-To: <bf1ebb1f480345e29b6de6d373c47d5e@oc11expo23.exchange.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=quant.network;
x-originating-ip: [2a00:23c7:978c:3a00:15b5:6e08:332f:511]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b943305f-4235-4293-dbfa-08d870ea02bb
x-ms-traffictypediagnostic: LO2P123MB2191:
x-microsoft-antispam-prvs: <LO2P123MB219156E5A53C2959460C0B67FC020@LO2P123MB2191.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 03wyVcG+gpwWtKYDLpbpnpRg/FQfGGetoUIdksGyRIo8FC/Ka2BtMop27Q9TznGcOvQrC3fZ/cMXt9ALQZppKkLE2lig2h2NKu/pRSicV+gTtg+bCNznaCAE4CQ8pN3WJcr746GDpYugprlPEy6glT7ar8jS/9lxlPG5Ryo1UXnXc8YeqEsivDHVK7HDxrcwM9MxUBeQELXAgWN2Zd2eEhZK2Kgd+WFueuVMIClj6fsXjMtfK0ONrpUzQIu4TNze0rnGXzoIKLqYYd6wBI7j1mwVLeZbUmrDzx/Qh8KRvVtqqpGbSuIcRC1uNlBF+Z1JG4gIkzmrPn7w5WH/bNrqg9vYJaFwEY6TBgCrFobn8KPkG2LkAXTn/Blc0/XtXb86c/mascSqxIQyD5FWWSHrhbaDQQVSbluVJuIXvlkX45/0LBRYRqzKze2EknGOc+fn
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39830400003)(42606007)(366004)(136003)(346002)(376002)(45080400002)(4001150100001)(7696005)(186003)(53546011)(6506007)(316002)(44832011)(110136005)(54906003)(966005)(8676002)(33656002)(4326008)(2906002)(478600001)(8936002)(86362001)(9686003)(55016002)(83380400001)(66574015)(5660300002)(83080400001)(66476007)(64756008)(52536014)(66446008)(71200400001)(66556008)(66946007)(76116006)(46492008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 7uNNveYE1SSvBn+p1e0/v6phmOnOR5aM/Wh3QYvIN4YYBU3y7FKb5E6QH41cZQqkZKh8eDYDSjkUTAUc0iGtYvSffRg44PdOGrcMK3AFfsMo8E492VrPBpkHT7uw4/eeQ+k/GWXcuSfQb5WSGZdm5NhK9i6CJrd6ySON+Wjumpk+tJOim+TMkZxe7Gqasmf1f1bhszQAaDTmrkkwqXba4xtSxWmCUOLxuzDswBl/9PZHP/AFMNkU+5sFFSMS6A1G40FloKx58CCXaCFRY2Q7sLqQ8sUAd6ChH30TdqC2cpluO2g+FGoBADGiqRQn7q0C9/lKizvI/lAU0yVcJ5FVa4DiphKjd3QOBk68kmsiumne7ZaC/2omnaMWK7fdPW6vywJ24MDxaO0OGfuJztKpvoDwiXqVdHrui2ON+TSj9NDHpLxNCVP3VWSa3v00/f78q/NGR9uvOa42wrnT3hV8SdqJybv/VkavjkejAJ2FenIGVr8JIT2Zm0UrZUj1a9tbA5vLVBUhCT2P4xvFOVLRea0Qt+3v7v404lQkRGuJJn0WcN20gcZHJv2IuojOuEJzg3CO3HcAy8UnID5eeThvAK9bHTcqQBrFvgzo34aI4Fr3SmO0wbItIPRJ42SR0Edmr6RCRHjW1Ho62sSq4mFwVkC8ai+w7L2izhAcut6m4Q02XrLUqhHrDfQHGRp62Mqfh1BoPaXDdzL1OTsf4vQjyw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: quant.network
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB1759.GBRP123.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: b943305f-4235-4293-dbfa-08d870ea02bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 09:09:24.2799 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70500bf4-d417-4259-8a6e-b7a550c6d120
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iBgn1bqkQtrPiN3zF3cx1MiYNUVHHLimFMMWjI0YbmXD9el2C3/LJprk1gJ/3kdZdApEn3BN+kEx+X2kzFk6tw8W4Xviv4J3VfMriBOAUaY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2191
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/qn9atZc-_QPFIJmjkFEK0HtCelo>
Subject: Re: [Blockchain-interop] [EXTERNAL] Re: 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: Thu, 15 Oct 2020 09:09:55 -0000

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.