[Blockchain-interop] Discussion on Asset Profiles

Thomas Hardjono <hardjono@mit.edu> Mon, 07 December 2020 14:20 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 40A9A3A13E9 for <blockchain-interop@ietfa.amsl.com>; Mon, 7 Dec 2020 06:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZhUuShe9O0wi for <blockchain-interop@ietfa.amsl.com>; Mon, 7 Dec 2020 06:20:52 -0800 (PST)
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 023C33A13E4 for <Blockchain-interop@ietf.org>; Mon, 7 Dec 2020 06:20:48 -0800 (PST)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id 0B7EKfZY006908; Mon, 7 Dec 2020 09:20:47 -0500
Received: from w92expo23.exchange.mit.edu (18.7.74.77) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 7 Dec 2020 09:20:02 -0500
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; Mon, 7 Dec 2020 09:20:26 -0500
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; Mon, 7 Dec 2020 09:20:26 -0500
From: Thomas Hardjono <hardjono@mit.edu>
To: "Blockchain-interop@ietf.org" <Blockchain-interop@ietf.org>
CC: "Aetienne.Sardon@swisscom.com" <Aetienne.Sardon@swisscom.com>
Thread-Topic: Discussion on Asset Profiles
Thread-Index: AQHWzKKECsdnYmQO0Um1n40hmEqGGw==
Date: Mon, 07 Dec 2020 14:20:26 +0000
Message-ID: <336ffead5aed4912a40a086504728636@oc11expo23.exchange.mit.edu>
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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/blockchain-interop/-uvzms5wl58ASQGVJTGfBZeMz-4>
Subject: [Blockchain-interop] Discussion on Asset Profiles
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, 07 Dec 2020 14:20:53 -0000

Folks,

At the SecDispatch presentation at IETF109 there was a bullet point about the need for gateways to be able to point to an authoritative profile JSON file that defines clearly the asset in question.

This JSON file is a kind of prospectus document that states the aspects/attributes of the virtual asset. It's not the asset itself, but a description of it.

I think a standardized asset profile will be needed, given that different jurisdictions around the world may have its own regulatory perspectives on what/which virtual assets are recognized in a given jurisdiction. This become important if one of the gateways (e.g. origin-gateway G1) is operating in a different jurisdiction than the destination-gateway G2.

The assets-types will have some common fields (e.g. Issuer, Code, Date, signature), but other assets types may have sub-fields that are specific to that asset-type.


Below is a compiled list of the fields of information for the asset-profile that we have so far:

•	Issuer: is the LEI or name of the entity/company that is issuing the Asset Profile JSON file or N/A.

•	Asset Code: is any officially recognized asset code (e.g. CH0008742519).

•	Asset Code Type: is the code type to which the Asset Code belongs (e.g. ISIN or "other" if none exists).

•	Keywords: is a list of keywords to make the Asset Profiles easily searchable.

•	Prospectus Link: is the link to any officially approved prospectus or N/A.

•	Key Information Link: is the link to any Key Information Document (KID) or N/A.

•	Transfer Restriction: is any information about transfer restrictions (e.g. banned jurisdictions etc.), such that the sender and recipient gateways can assess the validity of the transfer or N/A.

•	Ledger Requirements: is any information about the specific ledger requirements, such that the sender and recipient gateway can assess the appropriateness of the "receiving ledger" or N/A.

•	Original Asset Location: is the information about the original asset location L0 ("home ledger" and address), such that the receiving gateway can notify L0 that the asset has been transferred to a potentially new DLT.

•	Previous Asset Location: is the information about the previous asset location (ledger and address) from where the sender gateway DLT has received the asset, such that the recipient gateway can check that the received quantity doesn't exceed the disposable amount on the sender gateway DLT. This is N/A if the sender gateway DLT is the Original Asset Location.

•	Issuance: is the issuance date of the Asset Profile JSON file.

•	Expiration: is the expiration of the Asset Profile JSON file in terms of months or years (comparable to the TLS X.509 certificate).

•	Verification Endpoint: is the URL endpoint where anyone can check the current validity status of the Asset Profile JSON file.

•	Signature Value: is the signature of the Issuer of the Asset Profile.


		
Thoughts?



-- thomas --