Update II: Sign in with Tezos (SIWT) - Advancements and Innovations
Hello again, Tezos community! We’re following up with another exciting update on the progress of the Sign in with Tezos (SIWT) project. If you are not up to date yet, you can find the introduction and first update of SIWT on Agora. Most recently, we’ve made significant advancements in developing and deploying a Proof of Concept (PoC) smart contract which facilitates tokenizing policies on the Tezos blockchain, completed the proposed extensions to the TZIPs, defined a process for minting ODRL policy tokens and released v0.0.4. Let’s delve into the details!
Development and Deployment of the PoC Smart Contract
We’re thrilled to announce the development and deployment of the PoC smart contract that facilitates tokenizing policies on the Tezos blockchain, representing them as unique digital assets. The contract complies with the Tezos FA2 standard, ensuring compatibility with the existing Tezos infrastructure. This means these tokenized policies can be easily integrated and interacted with existing applications and services within the Tezos ecosystem.
Extensions to the TZIPs
We’ve successfully completed the proposed extensions to the TZIPs (Tezos Interface Proposal), specifically TZIP-012 and TZIP-016. The first extension, TZIP-012, defines the usage and constraints on the interfaces of the FA2 smart contract. The second extension, TZIP-016, describes the metadata schema and standards for tokenized ODRL (Open Digital Rights Language)-compliant policies. These extensions enhance the functionality and interoperability of the tokenized policies on the Tezos blockchain, making it easier for developers to work with these policies and for users to interact with them.
Minting ODRL Policy Tokens
Our team has defined a stepwise process for minting ODRL policy tokens. This process ensures the authenticity and correctness of the tokenized policies, providing a robust mechanism for policy representation on the blockchain. Tokens provide an immutable record of the permissions, prohibitions, and obligations dictated by the tokenized ODRL policy. This record can be referenced by the application to enforce access controls.
-
Role of Tokens: Each token can be seen as a ‘license’ carrying the access policy (ODRL policy) for a particular resource, codified within it as a smart contract. The access policy specifies the permissions, obligations, and prohibitions associated with that digital asset.
-
Enforcing Access: The actual enforcement of access control takes place in the application layer, not at the token level. When a user tries to interact with a resource through the application, the application refers to the token’s policy (on-chain data) to ascertain the user’s permissions regarding that resource.
-
Decentralized Documentation: Each token serves as a decentralized, immutable proof of the policy. If a dispute arises, the token’s smart contract can provide irrefutable evidence of the conditions set forth at the time of the user’s interaction with the resource.
-
Claim State: The immutability and transparency of the blockchain provide a solid ground for users to state a claim if they feel their access rights, as detailed in the token, have been violated.
Splitting the Policy and Access Token
In a significant departure from our first approach (see Update 1 #Time Constraints, where we introduced our “own” domain-specific language like Valid Until as an attribute in the NFT metadata), we’ve decided to split the policy and the access token completely and instead use a widely used policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and services.
This means the policy is connected to the access NFT (Non-Fungible Token) by reference but not part of the NFT token metadata of the asset itself. This has certain advantages, such as revoking a policy without affecting the NFT. For example, if a policy needs to be updated or changed, the original NFT can remain intact while the policy is revised and reissued. In the future, the SIWT SDK could be expanded to parse and understand ODRL to check the validity or claim in arbitrarily complex policies written in a domain-specific language instead of limiting yourself to a few keywords in the attributes section.
Release of v0.0.4
The first changes reported by the community were fixed and have been released.
What’s changed:
* Replace axios with fetch
* Add option to add a timeout
* Refactor smart contracts to have correct FA2 entry points
Breaking change:
The queryAccessControl (from @siwt/acq) now takes an object in the form of:
{
query,
allowlist,
options,
}
Conclusion
We’re incredibly proud of our progress with SIWT and excited about its potential to enhance the Tezos ecosystem. We’re committed to continuously improving SIWT and making it the go-to solution for developers looking to enhance their applications. Stay tuned for more updates, and as always, we welcome your feedback and suggestions according to our contribution roles. SIWT aims to be a community-owned and operated project by its stakeholders.
Thank you for your continued support, and we look forward to seeing you in the Tezos ecosystem, especially when you are around at TezDev.
