Asset Profiles for Asset Exchange

Asset transfer protocols such as SATP 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 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) . 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 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 for vocabulary) is also included in the Asset Profile. In the example below, the Asset Profile the Asset Authority (Ministry of Culture) 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 , 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.gov.gr/asset_profile/dcap", "@context": { "rwa": { "@id": "https://www.culture.gov.gr/asset_profile/rwa", "@context": { "digital_carrier_id": { "@id": "https://www.culture.gov.gr/asset_profile/digital_carrier_id", "@type": "schema:string" }, "digital_carrier_type": { "@id": "https://www.culture.gov.gr/asset_profile/digital_carrier_type", "@type": "schema:string" }, "rwa_kind": { "@id": "https://www.culture.gov.gr/asset_profile/rwa_kind", "@container": "@language" }, "rwa_description": { "@id": "https://www.culture.gov.gr/asset_profile/rwa_description", "@container": "@language" }, "rwa_current_storage": { "@id": "https://www.culture.gov.gr/asset_profile/rwa_current_storage", "@container": "@language" }, "rwa_storage_location": { "@id": "https://www.culture.gov.gr/asset_profile/rwa_storage_location", "@container": "@language" } } }, "dar": { "@id": "https://www.culture.gov.gr/asset_profile/dar", "@context": { "dar_id": { "@id": "https://www.culture.gov.gr/asset_profile/dar_id", "@type": "schema:string" }, "dar_system_id": { "@id": "https://www.culture.gov.gr/asset_profile/dar_system_id", "@type": "schema:string" }, "dar_url": { "@id": "https://www.culture.gov.gr/asset_profile/dar_url", "@type": "schema:url" }, "dar_description": { "@id": "https://www.culture.gov.gr/asset_profile/dar_description", "@container": "@language" } } } } } }, "@id": "https://www.culture.gov.gr/asset_profile", "schema:title": "Asset Profile for Cultural Assets", "schema:organization": { "@id": "https://www.culture.gov.gr/", "schema:email": "info@culture.gov.gr", "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.et.gr/eli/law/yyyy/nnnn/enacted/data.json", "territory": "GR" } } } } 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 (Greek law).

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 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.gov.gr/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 ). 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 .