New TZIP draft: Policy Tokenization

TZIP
1

About the TZIP

The Tezos community has always been at the forefront of blockchain innovation, and the latest Tezos Improvement Proposal (TZIP) on Policy Tokenization is no exception. This proposal, which has been developed during the newest release of SIWT, defines the tokenization of policies - a process to represent policies as unique digital assets on the blockchain, written in the Open Digital Rights Language (ODRL). ODRL is a language used to express policies for information management and digital rights governance. The proposal extends a Tezos FA2-compliant smart contract for functionality and interoperability on the Tezos blockchain to express usage rights and obligations of resources in a trustless environment.

This proposal is built as an extension to existing Tezos Improvement Proposals (TZIPs):

  1. TZIP-012: Establishing usage constraints and interfaces for the FA2 smart contract. This alignment ensures that the proposed tokenized policy mechanism integrates with the existing infrastructure.
  2. TZIP-016: Describing the metadata schema and standards for tokenized ODRL-compliant policies, thereby standardizing the representation and interpretation of policy metadata.

Moreover, this document specifies a methodical procedure for minting ODRL policy tokens. This process guarantees the authenticity and correctness of the tokenized policies through a robust verification mechanism. By integrating cryptographic techniques and blockchain’s inherent transparency, the proposal ensures that every policy token minted is verifiable and traceable.

Potential use cases of this proposal encompass various domains where granular access control and rights management are critical. Examples include digital content distribution, information access control in organizations, and rights management in open data ecosystems. It is expected that the implementation of this proposal will significantly contribute to the robustness, transparency, and flexibility of policy management on the Tezos blockchain.

We’re inviting all blockchain developers and enthusiasts in the Tezos ecosystem to submit suggestions, opinions, and proposals for improvement. Let’s work together to make Tezos even better! In addition, we thank all teams who helped us develop this, from ideation to technical implementation. Let’s get the conversation started!

7 Likes
2

Thanks @StakeNow for the post. I will be sharing this post in different meetings/groups to invite feedback. Are there any specific group/products/teams you would like the feedback from, please let me know and I will try to facilitate that.

2 Likes
3

Hi @asutosh ,
thank you for taking this on!

I think the target audience are groups/entities who want to define more detailed licenses/policies, business cases in which the proper documentation of these rights is important. Software licenses e.g. - taking an example where such an approach is not needed:
“Scan a code at TezDev, get a NFT and present it to get a T-Shirt”

There is a section with use cases and a section making an argumentation for the tokenization of the policies. I am not sure with what groups you have contact and maybe it is best if you read through the document as well to see where you see a good fit in your network.

We could definitely need support in the process of bringing the refined version into the “official tzip repository”

Best regards
Carlo

2 Likes
4

If I resume :

  • most of use case are about licensing definition in a structured way , but onchain
  • checkers are on a web2 backend to execute actions over some offchain resources

Am I right ?

2 Likes
5

That is about right :slight_smile:

I had a conversation with Eugene in which he said that describing the digital right in michelson would be nice to execute the logic directly on-chain. I would say that this would only be useful for a subset of the possible ODRL descriptions and would require a ODRL->Michelson interpreter.

In general I would say that the current proposal to “off-chain” the validation of the schema and also the application action checker while having the trace of rights clearly on chain is a very well balanced compromise. I think it is hard (up to impossible?) to force application backends to do anything anyway and it it clearly a contract that needs clear definition.

1 Like