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]
