idnits 2.17.1 draft-sardon-blockchain-interop-asset-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 30, 2020) is 1185 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DTTC' is mentioned on line 151, but not defined == Unused Reference: 'RFC2119' is defined on line 341, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hardjono-blockchain-interop-arch-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Sardon 3 Internet-Draft Swisscom 4 Intended status: Informational T. Hardjono 5 Expires: July 3, 2021 MIT 6 B. Schuppli 7 FQX 8 December 30, 2020 10 Asset Profile Definitions for DLT Interoperability 11 draft-sardon-blockchain-interop-asset-profile-00 13 Abstract 15 In order for virtual assets to be traded or exchanged within online 16 transactions, the parties involved in the transaction must have share 17 a common definition of what constitute the virtual asset. Parties 18 transacting on a DLT system must have the unambiguous means to refer 19 to a common definition of an virtual asset, independent of the 20 implementation of the virtual asset in question. This specification 21 defines a JSON representation of a number of common information 22 fields within asset profiles. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 3, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. The Asset Profile . . . . . . . . . . . . . . . . . . . . . . 3 61 4. General Operational Requirements . . . . . . . . . . . . . . 4 62 5. Common Information Fields and Asset-Specific Extensions . . . 5 63 5.1. Mandatory fields (non-null) . . . . . . . . . . . . . . . 5 64 5.2. Mandatory fields . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Optional fields . . . . . . . . . . . . . . . . . . . . . 6 66 5.4. Asset-specific Extension fields . . . . . . . . . . . . . 7 67 6. Example: Promissory Note . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 In order for virtual assets to be traded or exchanged within online 76 transactions, the parties involved in the transaction must have share 77 a common definition of what constitute the virtual asset. This 78 requirement is notably acute when a virtual asset is a representation 79 of real-world assets (e.g. basket of commodities) because there are 80 limitless ways to combine such real-world assets into differing 81 virtual asset representations. Parties transacting on a DLT system 82 must have the unambiguous means to refer to a common definition of an 83 virtual asset, independent of the implementation of the virtual asset 84 in question. The availability of authoritative definitions of 85 virtual assets using a standardized computer-readable format permits 86 instances of the asset to be established in different DLT systems 87 simultaneously, and permits mobility or transferability of virtual 88 asset across different DLT systems. 90 In cross-DLT transfers assisted by gateways, the respective gateways 91 must have the ability to validate that the originator and beneficiary 92 are referring to the same asset profile. An asset profile may state 93 some mechanical restrictions (i.e. can be instantiated on specific 94 types of compatible DLT systems), jurisdictional restrictions and 95 other constraints. Gateways must validate these assertions founds 96 within the asset profile prior to conducting cross-DLT transfers of 97 the asset instance. 99 This specification defines a JSON representation of a number of 100 common information fields within asset profiles. 102 2. Terminology 104 There following are some terminology used in the current document: 106 o Virtual Asset: A virtual asset is a digital representation of 107 value that can be digitally traded, or transferred as defined by 108 the FATF [FATF]. 110 o Asset profile: The prospectus of a regulated asset that includes 111 information and resources describing the virtual asset. The asset 112 profile is independent from the specific instantiation of the 113 asset (on a DLT system or otherwise) and independent from its 114 instance-ownership information. 116 o Asset instance: A specific digital instantiation of a virtual 117 asset as defined by its asset profile. 119 o Asset profile issuer (publisher): The entity publishing and 120 signing an asset profile document (e.g. signed JSON). The entity 121 publishing a profile definition can be different from the entity 122 instantiating the virtual asset following the profile definition. 124 o Virtual asset issuer: The entity instantiating a virtual asset in 125 digital form (on a DLT system or otherwise). 127 Further terminology definitions can be found in [NIST]. 129 3. The Asset Profile 131 In order for interoperability to be achieved between two DLT systems, 132 the gateway-nodes that participate in both DLTs respectively must 133 have a common definition of the virtual asset being transacted. We 134 refer to this authoritative definition (metadata) of a virtual asset 135 as its asset profile. 137 An asset profile is essentially a prospectus document of a regulated 138 virtual asset that is issued by a legally recognized authority for 139 the asset under a governing law. The entity that defines the asset 140 profile in a given data format (e.g. JSON file) must digitally sign 141 the file. 143 The asset profile is independent from the specific instantiation of 144 the asset (on a DLT system or otherwise) and independent from its 145 instance-ownership information. 147 An asset profile is typically a publicly-readable document (e.g. 148 JSON file), and a copy of the signed profile file may be represented 149 on-chain, or it may be available off-chain in a digital format from a 150 well-known Internet location (e.g., URL of asset depository 151 organization [DTTC]). 153 The asset profile includes information and resources describing the 154 virtual asset. This could include, for example, the registered asset 155 name/code, the profile authority, denomination (currency or unit), 156 date of issue of the profile, intended systems of circulation (e.g. 157 specific ledgers or networks), governing law, the digital signature 158 of the profile file, and the URLs and mechanisms to validate the 159 information in the profile file. 161 When the Originator (Alice) in an origin DLT seeks to transfer 162 virtual assets to a Beneficiary (Bob) in destination DLT, both Alice 163 and Bob must have the means to refer to the same asset definition 164 (namely the asset profile file). Consequently, the gateway nodes G1 165 and G2 in the respective DLTs that are performing the transfer must 166 also have the means to refer to (point to, or hash of) the asset 167 profile file [Arch]. 169 4. General Operational Requirements 171 In order for an asset profile document (i.e. JSON) to be machine- 172 readable and processable, there are a number of technological 173 requirements regarding the digital representation of the profile 174 information and the mechanisms to validate assertions in a profile 175 document. 177 Typically, the technological means to validate asserted information 178 may include the use of machine-resolvable links (e.g. URIs/URLs) 179 that permit a machine to obtain other relevant information to 180 validate the assertion (e.g. public-key certificates). 182 Some operational requirements are as follows: 184 o Profile issuer validation: The identity of the issuer (signer) of 185 the profile document must be able to be validated. For 186 simplicity, we assume that the signer of the asset profile 187 document (i.e. JSON file) is the same entity as the issuer of the 188 virtual asset. 190 o Asset code validation: Any code assignment to a virtual asset 191 defined in an asset profile document must be able to be validated. 192 For example, if a government authority or an asset exchange 193 employs an identifier (e.g. alphanumeric) to distinguish the asset 194 within its own jurisdiction context of network operation context, 195 then the namespace authority and identifier assignment must be 196 confirmable. 198 o Assertion-authority identity validation: The identity of any 199 third-party entities stated in the profile to be authoritative 200 (over certain assertions in the profile) must be able to be 201 validated. For example, if an LEI entity identifier is used in an 202 asset profile document, then the identity of the issuer of the 203 identifier (i.e. GLEIF) must be confirmable [GLEIF]. 205 5. Common Information Fields and Asset-Specific Extensions 207 Several information fields within an asset profile are common across 208 all types of virtual assets (e.g. Issuer field), while other more 209 complex asset may have additional fields that are specific only to 210 that asset. 212 In order to be interoperable, an Asset Profile must contain at least 213 the following common fields that uniquely identifies the profile. 214 Note that the presence of a field (even when its value is "null" or 215 "non-applicable") is relevant from a document processing and semantic 216 interoperability perspective. 218 5.1. Mandatory fields (non-null) 220 The following are fields that must be present and with non-null 221 values: 223 o Issuer: The registered name or legal identifier of the entity 224 issuing this asset profile document. For example, a legal 225 identifier can be the global LEI number. 227 o Asset Code: The unique asset code under an authoritative namespace 228 assigned to the virtual asset. 230 o Asset Code Type: The code-type to which the asset code belongs 231 under an authoritative namespace. For example, this code-type 232 could be the "ISIN" following the numbering scheme by the 233 International Securities Identification Number [ISIN] and defined 234 by the ISO6166 standard. 236 o Issuance date: The issuance date of the Asset Profile JSON 237 document. 239 o Expiration date: The expiration of the Asset Profile JSON document 240 in terms of months or years. 242 o Verification Endpoint: The URL endpoint where anyone can check the 243 current validity status of the Asset Profile JSON file. 245 o Digital signature: The signature of the Issuer of the Asset 246 Profile. This field may include signature algorithm information 247 and references to the digital certificate of the Issuer. 249 5.2. Mandatory fields 251 The following are fields that must be present, but which may have 252 non-applicable (null) values: 254 o Prospectus Link: The link to any officially published prospectus, 255 or non-applicable. 257 o Key Information Link: The link to any Key Information Document 258 (KID), or non-applicable. 260 o Keywords: The list of keywords to make the Asset Profiles easily 261 searchable. Can be blank or non-applicable. 263 o Transfer Restriction: Information about transfer restrictions 264 (e.g. prohibited jurisdictions etc.), or non-applicable. 266 o Ledger Requirements: Information about the specific ledger 267 mechanical requirement, or non-applicable.. 269 5.3. Optional fields 271 Depending on the specific asset type, there may a need to capture 272 further information regarding the origins of an asset profile: 274 o Original Asset Location: is the information about the original 275 asset location ("home ledger" and address). This information may 276 be relevant for certain governance jurisdictions, which require 277 the identification of the ledger where the asset was first 278 instantiated. 280 o Previous Asset Location: The information about the previous asset 281 location (ledger and address) where an asset instance originated. 283 5.4. Asset-specific Extension fields 285 These are fields who presence in an asset profile document is 286 dependent on the specific type of virtual asset. 288 6. Example: Promissory Note 290 The following is an example of an asset profile pertaining to a 291 digital promissory note: 293 o Issuer: FQX AG 295 o Asset Code: CH0008742519 297 o Asset Code Type: ISIN 299 o Keywords: Electronic Promissory Note; eNote; Debt 301 o Prospectus Link: N/A 303 o Key Information Link: N/A 305 o Transfer Restriction: shall not be transferred to the U.S., 306 Canada, Japan, United Kingdom, South Africa. Shall not be 307 transferred to non-qualified investors anywhere. 309 o Ledger Requirements: Hyperledger Fabric. 311 o Original Asset Location: N/A 313 o Previous Asset Location: N/A 315 o Issuance date: 04.09.2020 317 o Verification Endpoint: https://fqx.ch/profile-validate 319 o Signature Value: (signature blob) 321 7. References 323 7.1. Normative References 325 [FATF] FATF, "International Standards on Combating Money 326 Laundering and the Financing of Terrorism and 327 Proliferation - FATF Revision of Recommendation 15", 328 October 2018, . 332 [ISIN] ISO, "Securities and related financial instruments - 333 International Securities Identification Numbering system 334 (ISIN) - ISO6166:2013", July 2013, 335 . 337 [NIST] Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST 338 Blockchain Technology Overview (NISTR-8202)", October 339 2018, . 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 7.2. Informative References 348 [Arch] Hardjono, T., Hargreaves, M., and N. Smith, "An 349 Interoperability Architecture for Blockchain Gateways. 350 draft-hardjono-blockchain-interop-arch-01", October 2020, 351 . 354 [GLEIF] GLEIF, "Introducing the Legal Entity Identifier (LEI)", 355 November 2017, . 358 Authors' Addresses 360 Aetienne Sardon 361 Swisscom 363 Email: aetienne.sardon@swisscom.com 365 Thomas Hardjono 366 MIT 368 Email: hardjono@mit.edu 370 Benedikt Schuppli 371 FQX 373 Email: benedikt@fqx.ch