| Internet-Draft | Asset Schema Architecture | December 2024 |
| Avrilionis & Hardjono | Expires 19 June 2025 | [Page] |
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.¶
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/.¶
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 19 June 2025.¶
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.¶
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.¶
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".¶
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.¶
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¶
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.¶
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/"
}
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.¶
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"
},
"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": {
"ownerJurisdictionScope": {
"law": "https://www.officialjoutrnal.example.org/eli/law/yyyy/nnnn/enacted/data.json",
"territory": "Some country"
}
}
}
}
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.¶
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.¶
{
"@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"
},
"rwa_storage_location": {
"en": "Former Royal Estate, 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."
}
}
}
}
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].¶