Internet DRAFT - draft-sardon-blockchain-interop-asset-profile

draft-sardon-blockchain-interop-asset-profile







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, <http://www.fatf-
              gafi.org/publications/fatfrecommendations/documents/fatf-
              recommendations.html>.



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,
              <https://www.iso.org/standard/44811.html>.

   [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
              Blockchain Technology Overview (NISTR-8202)", October
              2018, <https://doi.org/10.6028/NIST.IR.8202>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.ietf.org/archive/id/draft-hardjono-
              blockchain-interop-arch-01.txt>.

   [GLEIF]    GLEIF, "Introducing the Legal Entity Identifier (LEI)",
              November 2017, <https://www.gleif.org/en/about-lei/
              introducing-the-legal-entity-identifier-lei.html>.

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]