Skip to main content

Asset Profiles for Asset Exchange
draft-avrilionis-satp-asset-profiles-02

Document Type Active Internet-Draft (individual)
Authors Denis Avrilionis , Thomas Hardjono
Last updated 2024-05-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-avrilionis-satp-asset-profiles-02
Network Working Group                                      D. Avrilionis
Internet-Draft                                            Compellio S.A.
Intended status: Informational                               T. Hardjono
Expires: 22 November 2024                                            MIT
                                                             21 May 2024

                   Asset Profiles for Asset Exchange
                draft-avrilionis-satp-asset-profiles-02

Abstract

   A definition of asset schema and profiles is needed to provide a
   semantic definition of tokenized assets.  The Asset schema is an
   abstract construct at the root hierarchy of more specific "asset
   profiles".  Asset profiles describe the structure (type) of assets
   that are specific to a given domain or industry.  An asset instance
   that is instantiated in a specific network and is exchanged via the
   SATP protocol has an instance-class relationship (in an ontological
   sense) with a given profile.  Asset profiles are essential to the
   SATP protocol as they define the semantics of asset instances to be
   transferred.  Gateways may negotiate asset transfers based on the
   nature and abilities of the assets as defined according to their
   profile.  The current document discusses the definition of the asset
   schema and profile.

Editorial Note

   Discussion of this draft takes place on the SATP mailing list
   (sat@ietf.org), which has its home page at
   https://datatracker.ietf.org/wg/satp/about/.

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 22 November 2024.

Avrilionis & Hardjono   Expires 22 November 2024                [Page 1]
Internet-Draft          Asset Schema Architecture               May 2024

Copyright Notice

   Copyright (c) 2024 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 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Asset Schema  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Organisation key  . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Facets  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Asset Schema Example  . . . . . . . . . . . . . . . . . .   4
   3.  Asset Profile . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Tokenized Asset Record Example  . . . . . . . . . . . . . . .   7
   5.  Implementation considerations . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Asset transfer protocols such as SATP [1] utilize gateways to
   transfer tokenized assets from one network to another.  In such
   transfers, the semantic definition of tokenisable assets is the basis
   for negotiating the transfer conditions among gateways.

   The semantic definition of the tokenizable real-world assets is
   referred to as the asset definition schema (or "asset schema" for
   short).  Certain industry verticals or narrow use cases may define a
   subset of the larger asset definition schema.  These derived schemas
   are called schema-profiles (or simply "profile").

   Asset schemas and profiles are defined using JSON-LD syntax.
   Tokenised Assets are JSON data structures that refer to Asset
   Profiles using the "@context" construct.

Avrilionis & Hardjono   Expires 22 November 2024                [Page 2]
Internet-Draft          Asset Schema Architecture               May 2024

2.  Asset Schema

   The Asset Schema is the top construct in the hierarchy of asset
   profiles.  It defines a set of namespaces relevant to the definition
   of asset profiles (e.g.  Schema.org, W3C SKOS, XML XSD, etc.).  It
   also defines the structure of generic constructs that are related to
   the overall architecture of Asset Profiles and Registries.  Two of
   such constructs have been identified so far, namely the "Organisation
   Key" and the "Facets".

2.1.  Organisation key

   An organisation key is the definition of the public key of an
   organisation and applies to all asset profiles.  Such key may be used
   to sign data in the exchange between an Asset Provider and a Registry
   (see [2] for the related vocabulary).  An organisation key is
   composed of a public key elements and a date of issuance of the
   public key.  This basic construct may be extended with additional
   elements, for example, the end of validity date of the key.

2.2.  Facets

   Facets are important elements of the overall architecture of Schemas
   and Profiles.  They refer to systemic qualities of an asset and play
   an important role in the negotiation phase among Gateways, prior to
   the execution of SATP.  Examples of facets are:

   *  Network transferability: information related to which networks can
      host a given asset.

   *  Owner transferability: information related to the ability to
      transfer ownership of an asset.

   *  Tradeability: information related to the way an asset can be
      exchanged with another.  For example, an asset provider can state
      that the asset cannot be traded for bitcoin.

   *  Taxability: information related to the way an asset can be taxed
      in specific jurisdictions

   *  Collateralisability: information related to the way an asset can
      be collateralised

   *  Confiscatability: information related to the ability of given
      entities to confiscate the asset in given jurisdictions

   *  Jurisdiction: information about the jurisdiction applicable to the
      assets related to the given profile

Avrilionis & Hardjono   Expires 22 November 2024                [Page 3]
Internet-Draft          Asset Schema Architecture               May 2024

   It should be noted that the Asset Schema introduces the notion of
   facet as an empty namespace.  Relevant facets would be defined at the
   level of the Asset Profile.

2.3.  Asset Schema Example

   Below we give an (non-normative) example definition of the Asset
   Schema using JSON-LD

{
   "@context": {
      "@version": 1.1,
      "foaf": "http://xmlns.com/foaf/0.1/",
      "schema": "http://schema.org/",
      "skos": "http://www.w3.org/2004/02/skos/core#",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
      "organization_key": {
         "@id": "https://satp.example.org/asset_schema_org_key",
         "@context": {
            "public_key": {
               "@id": "https://gateway.satp.ietf.org/asset_schema_pub_key",
               "@type": "schema:string"
            },
            "issued": {
               "@id": "https://gateway.satp.ietf.org/asset_schema_key_issued",
               "@type": "schema:string"
            }
         }
      },
      "facets": {
         "@id": "https://satp.example.org/asset_schema_facets"
      }
   },
   "@id": "https://satp.example.org/asset_schema/"
}

                   Figure 1: Asset Schema - JSON-LD

3.  Asset Profile

   Asset Profiles are definitions of the "types" of assets.  Asset
   Profiles may define a great variety of assets in different
   industries.  Asset Profiles are referenced by Tokenised Asset Records
   (TARs) [2] . As TARs are defined JSON, a TAR can reference an Asset
   Profile using the @context construct like any ordinary reference to a
   JSON-LD.

Avrilionis & Hardjono   Expires 22 November 2024                [Page 4]
Internet-Draft          Asset Schema Architecture               May 2024

   For illustration purposes, in this document, we use the example of an
   Asset Profile defining a "Digitized Cultural Asset Passport".  A
   Cultural Asset Passport can be seen as a certificate that is issued
   by a public authority in a given jurisdiction, uniquely defining the
   specific asset.  A Digitized Cultural Asset Passport stored in a
   Registry [2] allows Gateways to verify the validity of the asset in a
   given network and therefore to proceed to the transfer of the
   Digitized Cultural Asset Passport via the execution of the SATP
   protocol.  In order for such verifications to occur a public key of
   the Asset Authority (see [2] for vocabulary) is also included in the
   Asset Profile.  In the example below, the Asset Authority
   (culture.example.org) defines its public key so any kind of data
   signature with such a key (e.g. using a JSON Web Signature - RFC 7515
   mechanism) can be independently verified.

   As it can be seen in the example below and according to the overall
   Asset Schema and Profile Architecture defined in [2], the Digitized
   Cultural Asset Passport (DCAP) is a Tokenised Asset Record (TAR),
   composed of a set of attributes related to the Real-World Asset (RWA)
   as well as another set of attributes related to the Digitized Asset
   Record (DAR).

{
   "@context": {
      "@version": 1.1,
      "asset_schema": "https://gateway.satp.ietf.org/asset_schema/",
      "dcap": {
         "@id": "https://www.culture.example.org/asset_profile/dcap",
         "@context": {
            "rwa": {
               "@id": "https://www.culture.example.org/asset_profile/rwa",
               "@context": {
                  "digital_carrier_id": {
                     "@id": "https://www.culture.example.org/asset_profile/digital_carrier_id",
                     "@type": "schema:string"
                  },
                  "digital_carrier_type": {
                     "@id": "https://www.culture.example.org/asset_profile/digital_carrier_type",
                     "@type": "schema:string"
                  },
                  "rwa_kind": {
                     "@id": "https://www.culture.example.org/asset_profile/rwa_kind",
                     "@container": "@language"
                  },
                  "rwa_description": {
                     "@id": "https://www.culture.example.org/asset_profile/rwa_description",
                     "@container": "@language"
                  },

Avrilionis & Hardjono   Expires 22 November 2024                [Page 5]
Internet-Draft          Asset Schema Architecture               May 2024

                  "rwa_current_storage": {
                     "@id": "https://www.culture.example.org/asset_profile/rwa_current_storage",
                     "@container": "@language"
                  },
                  "rwa_storage_location": {
                     "@id": "https://www.culture.example.org/asset_profile/rwa_storage_location",
                     "@container": "@language"
                  }
               }
            },
            "dar": {
               "@id": "https://www.culture.example.org/asset_profile/dar",
               "@context": {
                  "dar_id": {
                     "@id": "https://www.culture.example.org/asset_profile/dar_id",
                     "@type": "schema:string"
                  },
                  "dar_system_id": {
                     "@id": "https://www.culture.example.org/asset_profile/dar_system_id",
                     "@type": "schema:string"
                  },
                  "dar_url": {
                     "@id": "https://www.culture.example.org/asset_profile/dar_url",
                     "@type": "schema:url"
                  },
                  "dar_description": {
                     "@id": "https://www.culture.example.org/asset_profile/dar_description",
                     "@container": "@language"
                  }
               }
            }
         }
      }
   },
   "@id": "https://www.culture.example.org/asset_profile",
   "schema:title": "Asset Profile for Cultural Assets",
   "schema:organization": {
      "@id": "https://www.culture.example.org/",
      "schema:email": "info@culture.example.org",
      "asset_schema:organization_key": {
         "asset_schema:public_key": "did:v1:test:nym:JApJf12r82Pe6PBJ3gJAAwo8F7uDnae6B4ab9EFQ7XXk#authn-key-1",
         "asset_schema:issued": "2018-03-15T00:00:00Z"
      }
   },
   "asset_schema:facets": {
      "owmner_transferability": "non-transferable",
      "network_transferability": "evm_compatible_network",
      "jurisdiction": {

Avrilionis & Hardjono   Expires 22 November 2024                [Page 6]
Internet-Draft          Asset Schema Architecture               May 2024

         "ownerJurisdictionScope": {
            "law": "https://www.officialjoutrnal.example.org/eli/law/yyyy/nnnn/enacted/data.json",
            "territory": "Some country"
         }
      }
   }
}

         Figure 2: Profile example: Digital Product Passport

   In the example above, the asset profile also defines some facets.
   Namely the facets 1) constrain assets to be non-transferable to
   another owner, 2) allow assets to be exchanged only among EVM-
   compatible networks and 3) define the legal jurisdiction.

4.  Tokenized Asset Record Example

   A Tokenised Asset Record defined according to a given asset profile
   has to reference the profile as an @context element.  Following the
   above Asset Profile example the JSON structure below is a non-
   normative example of a cultural asset passport TAR.

Avrilionis & Hardjono   Expires 22 November 2024                [Page 7]
Internet-Draft          Asset Schema Architecture               May 2024

{
   "@context": "urn:tar:eip155.137:0x517BBF0c9B71f64b5807f644E1F1bacD3Afb3ec2",
   "dcap": {
      "rwa": {
         "digital_carrier_id": "E492069BT491278256346325",
         "digital_carrier_type": "rfid_tag",
         "rwa_kind": {
            "en": "Various cases"
         },
         "rwa_description": {
            "en": "Blue velvet jewelry box with fabric lining on the inside. The metal edges in gold colour can be seen at the application point of the hinged cover."
         },
         "rwa_current_storage": {
            "en": "Former Royal Estate Tatoi > Old Vustassio"
         },
         "rwa_storage_location": {
            "en": "Former Royal Estate Tatoi > House Tatoi-1 (1000 sq.m.), Box XX"
         }
      },
      "dcar": {
         "dar_id": "911024",
         "dar_system_id": "5TDYIU",
         "dar_url": "https://www.culture.example.org/doi/5TDYIU/911024",
         "dar_description": {
            "en": " Blue velvet jewelry box with fabric lining inside."
         }
      }
   }
}

                        Figure 3: TAR Example

5.  Implementation considerations

   Validating a Tokenised Asset Record against a given Asset Profile
   shall follow the general JSON-LD validation process (see
   https://www.w3.org/TR/json-ld11-api/).  However, implementors can add
   extra validation steps in order to verify the consistency of
   information stored in a Registry.  In the example above, instead of
   adding a plain URL reference in the @content element like a regular
   json-ld, we show an example of a reference to the asset profile as
   URN.  Fetching the asset profile from a Registry based on that URN,
   an asset profile validator can perform the series of checks defined
   in the section "Working with Registries" as defined in [2].

6.  References

Avrilionis & Hardjono   Expires 22 November 2024                [Page 8]
Internet-Draft          Asset Schema Architecture               May 2024

   [1]        Hardjono, T., "SATP Architecture", Work in Progress,
              Internet-Draft, draft-ietf-satp-architecture, 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-satp-
              architecture>.

   [2]        Avrilionis, D. and T. Hardjono, "Asset Schema Architecture
              for Asset Exchange", Work in Progress, Internet-Draft,
              draft-avrilionis-satp-asset-schema-architecture, 2024,
              <https://datatracker.ietf.org/doc/html/draft-avrilionis-
              satp-asset-schema-architecture>.

Authors' Addresses

   Denis Avrilionis
   Compellio S.A.
   Email: denis@compell.io

   Thomas Hardjono
   MIT
   Email: hardjono@mit.edu

Avrilionis & Hardjono   Expires 22 November 2024                [Page 9]