Announcing Tezos Profiles - Own and Control Your Creator Identity
Spruce is excited to announce the upcoming launch of Tezos Profiles (TZP) in early May.
TZP is a web application that helps users regain control of their digital identity for use across platforms. It allows users to create portable verified profiles by demonstrating control over their public social media and by self-attesting information. These verified profiles are then linked to Tezos accounts, allowing any platform to resolve and establish trusted information to mitigate identity fraud.
Loss of Trust, Loss of Connection
With the accelerated growth of NFT adoption, creator impersonation and copyminting have unfortunately become widespread, with many buyers unsure if an NFT is being sold by its true creator. Not only have buyers lost millions of dollars purchasing fraudulent assets, but it has led to growing trust problems between users and NFT platforms. With no existing way to authenticate artists at scale, platforms are continually feeling pressure to authenticate artists on an individual basis, all while the fraud continues.
A Better Approach
Instead of a creator’s identity being recreated and fragmented across various platforms, why not allow the creator to attest to their own identity and credentials?
TZP solves this problem with a web application where a user can anchor their Tezos address to their public online identity based on social media profiles and self-attested information. Platforms can then globally resolve this user-managed information to establish a creator’s profile. Since each platform draws from the same source (the creator), their identity remains whole and consistent to audiences.
How it Works
TZP will initially support two distinct workflows that result in W3C Verifiable Credentials with more to come: basic profile information provided by the end user, and a Twitter profile verification.
The basic profile information workflow prompts users to input an alias, a description, a website, and an avatar URL, and sign off on that information using their Tezos wallet of choice. This enables services to pull basic information about a user without requiring any account creation or data duplication.
The Twitter verification workflow requires the user to tweet an identity proof message such as “I am @sprucesystems, verifying my Tezos address is tz1…” with a valid signature. The application runs a service that will confirm the validity of the tweet and upon success issue a verifiable credential signed by did:web:tzprofiles.com (also known as a “claim”).
The steps to creating a basic profile will be the following:
- A user connects their Tezos wallet.
- The user completes the Twitter verification and self-attested information workflows to receive claims in browser localStorage.
- The user then signs a storage operation with their Tezos wallet to upload their claims to Kepler, Kepler returns a public URL per claim.
- After that, the user deploys a smart contract they control containing the URLs and content hashes of the claims.
- (Optional) The user can update the smart contract contents and sign additional storage operations to update or delete their claims. Additionally, users can further control the active contents of the contract using their Tezos account, and even set the URL in the smart contract to files on their own web host.
The Difference: Kepler, Key Controlled Off-Chain Storage
Where are the W3C Verifiable Credentials stored? We initially considered plain IPFS, but wanted to maximize user control.
Therefore, tzProfiles credentials will be stored in a storage service at kepler.tzprofiles.com. The service can produce a public URL that anyone can fetch per file, and allows users to create, update, and delete data using their Tezos wallet to sign requests. While bare IPFS instances may allow replication to unknown parties, Kepler adds permissioning around IPFS to restrict replication so users can delete their data and reasonably retract their information if they wish. In the future, users will have the ability to run their own Kepler instance to mirror just their content sets (known as orbits) to their own servers if they wish.
We have open-sourced the MVP of Kepler powering tzProfiles as Apache 2.0 on our GitHub, with an official release and announcement forthcoming. From the product roadmap, Kepler will support pluggable storage backends (e.g., S3, RocksDB, Couchbase) and authentication modules (DID-based, ssh keys, OpenLogin, other crypto wallets).
Developers can use the tzProfiles SDK (to be shipped on launch) to allow their users to fetch and independently check verifications for any Tezos address. These verifications can be displayed within user pages and further styled for a seamless experience. People will be able to manage verifications outside of tzprofiles.com, such as by setting and confirming their public exposure directly in their wallets or checking additional verifications per address in block explorers.
Future Plans and Use Cases
We plan to extend support in TZP to include credentials from additional public social profiles such as Instagram to give creators the ability to continue to associate their core public information. Not only does this user-centric identity model rebuild trust between creators and their followers, but it also means that identity verification doesn’t become platform-dependent. This allows creators to directly manage their own identity, and as a result, directly manage their audience and relationships.
The problem of establishing trust between parties is not unique to artists. In the payments and financial services industries, this is often required. The same technology powering creators’ TZP can also enable Tezos addresses to satisfy enterprise use cases. We intend to support verifications for corporate and enterprise stakeholders, such as proof of DNS record control, external audit reports, and corporate filings containing identity proofs.
In the future, we imagine a system featuring multiple independent parties verifying credentials — not just tzprofiles.com, and eventually decentralizing the set of supported verifications to avoid singular control.