Internet Engineering Task Force A. Sardon Internet-Draft Swisscom Intended status: Informational T. Hardjono Expires: July 3, 2021 MIT B. Schuppli FQX December 30, 2020 Asset Profile Definitions for DLT Interoperability draft-sardon-blockchain-interop-asset-profile-00 Abstract In order for virtual assets to be traded or exchanged within online transactions, the parties involved in the transaction must have share a common definition of what constitute the virtual asset. Parties transacting on a DLT system must have the unambiguous means to refer to a common definition of an virtual asset, independent of the implementation of the virtual asset in question. This specification defines a JSON representation of a number of common information fields within asset profiles. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of Sardon, et al. Expires July 3, 2021 [Page 1] Internet-Draft Virtual Asset Profiles December 2020 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Asset Profile . . . . . . . . . . . . . . . . . . . . . . 3 4. General Operational Requirements . . . . . . . . . . . . . . 4 5. Common Information Fields and Asset-Specific Extensions . . . 5 5.1. Mandatory fields (non-null) . . . . . . . . . . . . . . . 5 5.2. Mandatory fields . . . . . . . . . . . . . . . . . . . . 6 5.3. Optional fields . . . . . . . . . . . . . . . . . . . . . 6 5.4. Asset-specific Extension fields . . . . . . . . . . . . . 7 6. Example: Promissory Note . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In order for virtual assets to be traded or exchanged within online transactions, the parties involved in the transaction must have share a common definition of what constitute the virtual asset. This requirement is notably acute when a virtual asset is a representation of real-world assets (e.g. basket of commodities) because there are limitless ways to combine such real-world assets into differing virtual asset representations. Parties transacting on a DLT system must have the unambiguous means to refer to a common definition of an virtual asset, independent of the implementation of the virtual asset in question. The availability of authoritative definitions of virtual assets using a standardized computer-readable format permits instances of the asset to be established in different DLT systems simultaneously, and permits mobility or transferability of virtual asset across different DLT systems. In cross-DLT transfers assisted by gateways, the respective gateways must have the ability to validate that the originator and beneficiary are referring to the same asset profile. An asset profile may state some mechanical restrictions (i.e. can be instantiated on specific types of compatible DLT systems), jurisdictional restrictions and other constraints. Gateways must validate these assertions founds Sardon, et al. Expires July 3, 2021 [Page 2] Internet-Draft Virtual Asset Profiles December 2020 within the asset profile prior to conducting cross-DLT transfers of the asset instance. This specification defines a JSON representation of a number of common information fields within asset profiles. 2. Terminology There following are some terminology used in the current document: o Virtual Asset: A virtual asset is a digital representation of value that can be digitally traded, or transferred as defined by the FATF [FATF]. o Asset profile: The prospectus of a regulated asset that includes information and resources describing the virtual asset. The asset profile is independent from the specific instantiation of the asset (on a DLT system or otherwise) and independent from its instance-ownership information. o Asset instance: A specific digital instantiation of a virtual asset as defined by its asset profile. o Asset profile issuer (publisher): The entity publishing and signing an asset profile document (e.g. signed JSON). The entity publishing a profile definition can be different from the entity instantiating the virtual asset following the profile definition. o Virtual asset issuer: The entity instantiating a virtual asset in digital form (on a DLT system or otherwise). Further terminology definitions can be found in [NIST]. 3. The Asset Profile In order for interoperability to be achieved between two DLT systems, the gateway-nodes that participate in both DLTs respectively must have a common definition of the virtual asset being transacted. We refer to this authoritative definition (metadata) of a virtual asset as its asset profile. An asset profile is essentially a prospectus document of a regulated virtual asset that is issued by a legally recognized authority for the asset under a governing law. The entity that defines the asset profile in a given data format (e.g. JSON file) must digitally sign the file. Sardon, et al. Expires July 3, 2021 [Page 3] Internet-Draft Virtual Asset Profiles December 2020 The asset profile is independent from the specific instantiation of the asset (on a DLT system or otherwise) and independent from its instance-ownership information. An asset profile is typically a publicly-readable document (e.g. JSON file), and a copy of the signed profile file may be represented on-chain, or it may be available off-chain in a digital format from a well-known Internet location (e.g., URL of asset depository organization [DTTC]). The asset profile includes information and resources describing the virtual asset. This could include, for example, the registered asset name/code, the profile authority, denomination (currency or unit), date of issue of the profile, intended systems of circulation (e.g. specific ledgers or networks), governing law, the digital signature of the profile file, and the URLs and mechanisms to validate the information in the profile file. When the Originator (Alice) in an origin DLT seeks to transfer virtual assets to a Beneficiary (Bob) in destination DLT, both Alice and Bob must have the means to refer to the same asset definition (namely the asset profile file). Consequently, the gateway nodes G1 and G2 in the respective DLTs that are performing the transfer must also have the means to refer to (point to, or hash of) the asset profile file [Arch]. 4. General Operational Requirements In order for an asset profile document (i.e. JSON) to be machine- readable and processable, there are a number of technological requirements regarding the digital representation of the profile information and the mechanisms to validate assertions in a profile document. Typically, the technological means to validate asserted information may include the use of machine-resolvable links (e.g. URIs/URLs) that permit a machine to obtain other relevant information to validate the assertion (e.g. public-key certificates). Some operational requirements are as follows: o Profile issuer validation: The identity of the issuer (signer) of the profile document must be able to be validated. For simplicity, we assume that the signer of the asset profile document (i.e. JSON file) is the same entity as the issuer of the virtual asset. Sardon, et al. Expires July 3, 2021 [Page 4] Internet-Draft Virtual Asset Profiles December 2020 o Asset code validation: Any code assignment to a virtual asset defined in an asset profile document must be able to be validated. For example, if a government authority or an asset exchange employs an identifier (e.g. alphanumeric) to distinguish the asset within its own jurisdiction context of network operation context, then the namespace authority and identifier assignment must be confirmable. o Assertion-authority identity validation: The identity of any third-party entities stated in the profile to be authoritative (over certain assertions in the profile) must be able to be validated. For example, if an LEI entity identifier is used in an asset profile document, then the identity of the issuer of the identifier (i.e. GLEIF) must be confirmable [GLEIF]. 5. Common Information Fields and Asset-Specific Extensions Several information fields within an asset profile are common across all types of virtual assets (e.g. Issuer field), while other more complex asset may have additional fields that are specific only to that asset. In order to be interoperable, an Asset Profile must contain at least the following common fields that uniquely identifies the profile. Note that the presence of a field (even when its value is "null" or "non-applicable") is relevant from a document processing and semantic interoperability perspective. 5.1. Mandatory fields (non-null) The following are fields that must be present and with non-null values: o Issuer: The registered name or legal identifier of the entity issuing this asset profile document. For example, a legal identifier can be the global LEI number. o Asset Code: The unique asset code under an authoritative namespace assigned to the virtual asset. o Asset Code Type: The code-type to which the asset code belongs under an authoritative namespace. For example, this code-type could be the "ISIN" following the numbering scheme by the International Securities Identification Number [ISIN] and defined by the ISO6166 standard. o Issuance date: The issuance date of the Asset Profile JSON document. Sardon, et al. Expires July 3, 2021 [Page 5] Internet-Draft Virtual Asset Profiles December 2020 o Expiration date: The expiration of the Asset Profile JSON document in terms of months or years. o Verification Endpoint: The URL endpoint where anyone can check the current validity status of the Asset Profile JSON file. o Digital signature: The signature of the Issuer of the Asset Profile. This field may include signature algorithm information and references to the digital certificate of the Issuer. 5.2. Mandatory fields The following are fields that must be present, but which may have non-applicable (null) values: o Prospectus Link: The link to any officially published prospectus, or non-applicable. o Key Information Link: The link to any Key Information Document (KID), or non-applicable. o Keywords: The list of keywords to make the Asset Profiles easily searchable. Can be blank or non-applicable. o Transfer Restriction: Information about transfer restrictions (e.g. prohibited jurisdictions etc.), or non-applicable. o Ledger Requirements: Information about the specific ledger mechanical requirement, or non-applicable.. 5.3. Optional fields Depending on the specific asset type, there may a need to capture further information regarding the origins of an asset profile: o Original Asset Location: is the information about the original asset location ("home ledger" and address). This information may be relevant for certain governance jurisdictions, which require the identification of the ledger where the asset was first instantiated. o Previous Asset Location: The information about the previous asset location (ledger and address) where an asset instance originated. Sardon, et al. Expires July 3, 2021 [Page 6] Internet-Draft Virtual Asset Profiles December 2020 5.4. Asset-specific Extension fields These are fields who presence in an asset profile document is dependent on the specific type of virtual asset. 6. Example: Promissory Note The following is an example of an asset profile pertaining to a digital promissory note: o Issuer: FQX AG o Asset Code: CH0008742519 o Asset Code Type: ISIN o Keywords: Electronic Promissory Note; eNote; Debt o Prospectus Link: N/A o Key Information Link: N/A o Transfer Restriction: shall not be transferred to the U.S., Canada, Japan, United Kingdom, South Africa. Shall not be transferred to non-qualified investors anywhere. o Ledger Requirements: Hyperledger Fabric. o Original Asset Location: N/A o Previous Asset Location: N/A o Issuance date: 04.09.2020 o Verification Endpoint: https://fqx.ch/profile-validate o Signature Value: (signature blob) 7. References 7.1. Normative References [FATF] FATF, "International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation - FATF Revision of Recommendation 15", October 2018, . Sardon, et al. Expires July 3, 2021 [Page 7] Internet-Draft Virtual Asset Profiles December 2020 [ISIN] ISO, "Securities and related financial instruments - International Securities Identification Numbering system (ISIN) - ISO6166:2013", July 2013, . [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST Blockchain Technology Overview (NISTR-8202)", October 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [Arch] Hardjono, T., Hargreaves, M., and N. Smith, "An Interoperability Architecture for Blockchain Gateways. draft-hardjono-blockchain-interop-arch-01", October 2020, . [GLEIF] GLEIF, "Introducing the Legal Entity Identifier (LEI)", November 2017, . Authors' Addresses Aetienne Sardon Swisscom Email: aetienne.sardon@swisscom.com Thomas Hardjono MIT Email: hardjono@mit.edu Benedikt Schuppli FQX Email: benedikt@fqx.ch Sardon, et al. Expires July 3, 2021 [Page 8]