Since the dawn of the internet, humans have strived to enhance the web experience and make it an engaging, enjoyable experience. First, we had static websites where every person in the world saw the same thing on the internet.

Then, to improve it, we moved on to creating profiles that personalized a website for each user by adding their details and preferences. Alongside profiles came cookies that tracked the activities of users across the internet. Based on the user activity, each person’s personas became further enriched and the web experience became further personalized with functionalities like content recommendations, personalized social feeds, tailored messaging, relevant advertisements, etc.

Today, a modern user not only expects a personalized experience, but 71 percent get frustrated when this doesn’t happen. The personalization features can make or break any website.

The better your website’s personalization, the more the user retention rates.

The Advent of Web3

For the past decade, we have been reimagining the internet, making it decentralized and free from control, censorship, or manipulation. The web3 community has been developing decentralized apps (dApps) and has been trying to get adoption.

However, they haven’t been quite successful there. The experience on web3 platforms isn’t exactly fun and the user churn rates across all dApps are a dismal 93%.

When a person lands on a web3 dApp for the first time, the decades-long context of the person that he or she created in the web2 world is all gone and they have to start from scratch on the web3 platform. On average, a new website only has 10 seconds to capture a new user’s attention before they churn. Figuring out how to connect a wallet alone takes more time than that and even after the connection, there is no user context attached to the wallet so every person on the dApp has exactly the same experience.

When it comes to experience, web3 is synonymous to web1 as there is no personalization.

This leads to the cold start problem for dApps where not only is it difficult for the users to acquire new customers but also to retain existing ones. So, how big a problem is it really that there is no personalized user experience on dApps? Let’s take a look at the stats.

1. 71% of consumers express some level of frustration when their experience is impersonal
2. 80% of consumers indicated they would be more likely to purchase from a brand that provides a personalized experience.
3. 80% of consumers were more likely to do business with a company that offered personalized experiences.
4. 31% of consumers wished their shopping experience was more personalized than it currently was.
5. 91% of consumers are more likely to shop with brands that provide relevant offers and recommendations.
6. 44% of consumers who were satisfied with personalized service become repeat customers

From the stats, it’s quite clear that people expect personalization in their online experiences. But, personalization cannot happen without having some contextual data of users, which brings the question of privacy.

So, can personalization and privacy co-exist?

The big question is, would users want to share their data for personalization? Let’s take a look at the stats once again

1. 52% of consumers would share personal data in exchange for product recommendations
2. 64% of consumers are happy with retailers to save personal preferences if more personalization is offered
3. 90% were comfortable with companies collecting data if it led to a personalized experience.

Hmmm, that’s quite a conundrum, isn’t it? We live in contradictory times. The modern consumer demands increased privacy, tightened data controls, and the right to be forgotten. That’s easily deliverable until you contrast those demands with their expectations for tailor-made content, bespoke product recommendations, and uber-personalization. Add to it the fact that people are also okay with sharing some of their data if they believe they get a better experience for it.

So, what’s the best possible way to do so in web3 keeping in mind that a web3 wallet has no contextual data attached to it? And is it possible to do it while respecting people’s privacy?

Well, there are a few approaches to balance privacy and personalization.

NFTs as a zero-party data strategy

For the past 3 years, NFTs have been experimented with in many different ways. One of them is for loyalty programs by brands using zero-party data strategies.

Zero-party data strategy is when users consensually share their data with a party in exchange for some value through forms, questionnaires, polls, etc.

So, brands have been asking users to give their data with their consent directly to the brands (zero-party data strategy) and get NFTs in return which will allow them to get discounts, promos, and other benefits.

This strategy makes sense but is extremely limited. Going to each website and filling out form after form for freebies is not only frustrating but cannot scale. Moreover, how much data can you fill out? Humans produce 146 GB of digital footprint each day which just cannot be transferred to a single form. Adding wound to the salt, NFTs are publicly reflected in your wallet, which isn’t exactly adhering to the concept of privacy.

So, are there any better options or web3 is doomed to be impersonalized and boring forever? What else is out there?

The Better Zero-Party Data Strategy with Self-Sovereign Identity

What if instead of filling out forms again and again and getting very little personalization and benefits in return, we could have all our data in a data backpack, that we take with us on any website as we travel across cyberspace and plug it in on that website to be used for personalization. We decide when, how, and where that data is used.

“Personalization and privacy can only co-exist in the future with a zero-party data strategy.” — Scott McNealy, founder at Sun Microsystems

With technological standards like Self-Sovereign Identity, not only is this possible, but is also being done in projects.

This is what plurality network is doing by allowing dApps to get contextualized user information that helps them to personalize user experience on their website, without needing to store the data.

We could never bring the next billion users to web3 without giving them at least the same level of user experience as on the internet today.

Know of any other projects working in this domain? Hit me up!

Hey there, thanks for reading this far. If you liked this article, don’t forget to follow and leave a clap.

Follow me here, on LinkedIn, on X, and on Farcaster to get the latest blockchain technical content in simple, bite-sized reads.

Last weekend was a thrilling and energy packed atmosphere at ETH Zurich, where the plurality team hacked away the first prototype of Plurality.

The plurality team presented the concept of a privacy-preserving identity layer for DEFI and the blockchain world that any dApp developer can easily integrate into its workflows.

The modular application design and the use of Semaphore to create the Zero-Knowledge Identity Layer intrigued many fellow web3-enthusiasts and led to many interesting discussions.

From proof-of-personhood to sybil resistance to full-fledged KYC, plurality has the modularity to fulfil all such use cases.

The showcased demo showed the example of a mortgage lending dApp that requires its users to identity themselves but also doesn’t want to put any personal information on-chain.

The demo can be seen here:

https://www.youtube.com/watch?v=7fA5Kyl2NcA

To test out the demo code, you can clone from this git repository:

GitHub - Web3-Plurality/zk-onchain-identity-verification

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

Ever since the modern world has adopted a monetary value exchange system, identification of involved parties has been the cornerstone of every transaction. Today, every monetary transaction is identified and tracked. Various regulatory bodies like FATF provide guidelines to track the money trails such as “Travel Route”. Unidentified transactions are not considered legal, and every new value exchange technology, like Blockchain, is judged and examined under the same lens:

Do we know who is sending payment to whom?

In 2009, a peer-to-peer transactional system called Bitcoin was introduced. The concept was simple: One world, one global ledger that has transparency in transactions without the need of any centralized party. Fast forward to 2022, we are living in a world where all the internet is slowly shifting to programmable blockchains which are managed and enabled decentrally by the community. We call it web3.

While the key concept of this decentralization and web3 is revolutionary, it lacks one key piece of puzzle i.e., Identity. Blockchains provide pseudonymity — which means that it’s impossible to know the actual people behind any transaction. This has created two major challenges for the blockchain community:

1. Legal Challenges: The government regulations ask for identification of the sender and receiver in value-exchange transactions — which is not possible natively in blockchain.
2. Adoption Challenges: It posed a hurdle in adoption of web3 in traditional use cases like lending, mortgage, social media, insurance etc. For example, how can you create a truly decentralized mortgage platform or under-collaterized lending platform without knowing who you are lending to or what is their risk profile?

The legal challenges have partially been catered by the creation of centralized cryptocurrency exchanges or marketplaces. These exchanges or marketplaces are run by centralized organizations that identify users and do the KYC (Know Your Customer), let them buy cryptocurrency and crypto assets for fiat and then hold their assets.

Examples are Binance, Coinbase, Kraken etc. However, the paradox is that for buying the assets of the decentralized world, these platforms use the same centralized means for identification that blockchain originally set out to disrupt. We basically ended up at the point where we started from.

For decentralized world, same centralized means are used that blockchain originally set out to disrupt

Moreover, the crypto regulatory landscape is constantly changing and more and more applications like DeFi, DAOs, NFT Marketplaces — which previously did not have to comply to regulations are now coming into the regulatory umbrella after regulations like MiCA.

Now coming to the adoption challenges, currently, no native identification solution exists. Therefore, the blockchain is restricted as only a financial tool even though it has the potential to provide an improved, decentralized version of many solutions we see today e.g., social media, lending, insurances etc. Until there is a native identification solution, the blockchains will be stuck to only being a “bank account”.

This is what plurality has set out to solve. Plurality wants to solve the identification problem in public blockchains and give innovative dApps a chance to survive in the complex crypto-regulatory landscape. Moreover, by 2030, the decentralized identity market is expected to grow to $100 billion from the current $1 billion. So, the need for decentralized identification is going to exponentially grow in the coming decade.

To provide the ground for the next generation of innovative applications in the blockchain space, we need an identification mechanism that is:

1. Decentralized: no single party holds or controls it

2. Off-chain: Personal Identifiable Information is not stored permanently on the blockchain (necessary for GDPR compliance)

3. Privacy-preserving: Protects the privacy of the individual by disclosing only the minimal required identity to the required party.

4. Plural: Different subsets of identity disclosed to different parties i.e., plural identity relationship

5. Peer to peer: Identification takes place only between the concerned parties in a peer to peer fashion

The decentralized society is not complete without an identification mechanism that’s decentralized, protects and respects human beings and their inviolable right to privacy. This final piece of puzzle is enabled by Plurality.

How Plurality does this?

Plurality proposes to use the concepts and techniques from Self Sovereign Identity ecosystem to bridge the SSI and the blockchain world. (Read through our three-part series to understand SSI better).

Plurality wallet has created a novel approach to pair your credentials to your blockchain address in a provable way — without compromising on privacy.

To understand how plurality does this, let’s assume an example where Alice wants to prove to Bob that she lives in London. She can do this easily by revealing to Bob her residence card. Or, if she wants to be more privacy preserving, she can use the technique of selective disclosure where only selected parts of her identity card will be revealed.

However, if she also wants to prove that she is the owner of a certain blockchain address, all she needs to prove is that she also knows the secret of the wallet i.e., the private key.

Alice creates a Verifiable Credential proof of her residence city and then signs it with the private key of the blockchain wallet.

Once Bob receives the proof from Alice, he will unpack it with the public key of Alice and then verify the proof. If the unpacking of proof is successful, this means that Alice indeed was the creator of the proof since she was the only one who knows the private key of her blockchain wallet. This way, Bob would know whether Alice lives in London and what her blockchain address is.

Decentralized Mediation Protocol (DMP)

Peer to peer communication between proving and verifying parties cannot happen without decentralized mediators in between. Mediators are servers that forward the messages between provers and verifiers without knowing about the information in the message.

Plurality aims to create a Decentralized Mediation Protocol (DMP) which will enable a network of mediators to facilitate communication between the parties without compromising on privacy. This pool of mediators will be completely decentralized which means that anyone can setup a server and start offering mediation services. These mediators will be compensated as per their service accordingly.

Storage on Blockchain

After every successful verification, a zero-knowledge proof of verification will be stored on the blockchain which will reveal no personally identifiable information of the user, just that the user meets the criteria for the proof.

How dApps can use Plurality for identifying their users?

The DApps need to take the following steps:

1. Dapps first figure out what kind of information do they need from users? E.g., address from identity card to prove residence in Europe, passport number from passport etc.

2. Follow the simple steps to setup your dapp’s verifier service and configure it with proof requirements

3. The DApp is now able to identify its users by cryptographically verifying the presented credentials.

Conclusion

Decentralization is a major step in the vision of an independent, plural society. Blockchains are bringing us one step closer to that vision. However, a key piece of this puzzle i.e. identification of people still remains highly centralized and restrictive. This not only goes against the principles of web3, but also poses serious privacy concerns for the parties involved. Moreover, it limits the innovative use cases that can be created in this ecosystem.

New and upcoming regulations in the crypto-space are asking more and more dapps to identify their users. Plurality wants to give innovative dapps a chance to survive in the crypto regulatory landscape without compromising on the web3 ethos of decentralization and privacy-by-design.

Plurality proposes a better way to handle identification using Self Sovereign Identity (SSI), which lets users be in control of their data. The users should be able to decide when, how much and to whom their personal information needs to be revealed. Plurality attempts to create an identification system that protects the inviolable dignity of humankind by ensuring privacy and decentralization. By design, it supports all programmable blockchains and can support multiple types of identification credentials. Plurality brings the complexity of human relationships on the blockchain, giving rise to a new era of decentralized society.

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

Plurality: Decentralized Identity for the Decentralized World was originally published in Blockchain Biz on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many people today prefer using their crypto wallets on their mobile phones. Not only are mobile apps easy to use and handy, but also come with the added benefit of being able to be linked with other mobile apps using a technique known as deep linking or app-to-app linking.

App-to-app linking allows one mobile app to interact with another mobile app. In the case of blockchain wallets, using deep linking, any mobile app can interact with the blockchain wallet and ask it to perform certain actions.

Using this technique, we can connect the actions we do on any mobile app with our blockchain wallet.

The requesting app asks the blockchain wallet to sign certain actions, and if the blockchain wallet agrees to do so, the mobile app has a “written-consent” to perform this action.

This concept is powerful and can allow many interesting use cases to be developed. For example, using an identity app to send your identity information to a third-party along with the signed consent from your blockchain wallet. This would prove that the person who is performing the action has access to both the blockchain wallet and the identity wallet, thus providing a cryptographic proof that these belong to the same person.

Mobile Linking with WalletConnect

WalletConnect has been an established name in the web3 industry that connects different dapps and wallets. They have recently come out with the version 2 of their SDK with better features.

In this tutorial, we will be creating an Android app using Kotlin and connecting it to a Trust Wallet mobile app using WalletConnect v2.

Note: Many wallets and dapps are still making the transition to wallet connect v2. As of 14th March, 2023, Metamask hasn’t completed the integration, therefore, we will be using Trust Wallet in this tutorial.

To follow this tutorial, you should have:

1. An android phone with developer options enabled

2. The android phone should have Trust Wallet installed and a test wallet should be setup on it

3. Android studio installed on your computer

4. Internet connection

5. Curiosity to learn something new 😊

So, let’s get started:

Step 1: Create Android Project

Create a new project in Android Studio. Select “Phone and Tablet” category and activity type as “Basic Activity”

Fill in the name of the project and other details and finish creating the project.

Step 2: Add dependencies in gradle files

In root/build.gradle.ts

allprojects {
 repositories {
    mavenCentral()
    maven { url "https://jitpack.io" }
 }
}

Note: You might have to move this code to settings.gradle as sometimes settings.gradle is preferred over build.gradle when the app runs.

In app/build.gradle.kts

implementation("com.walletconnect:android-core:1.11.1")
implementation("com.walletconnect:sign:2.9.1")
implementation("com.walletconnect:web3wallet:1.4.1")

The current tutorial has been tested with the above versions. For most recent versions, you can visit here.

Step 3: Create a CoreClient and SignClient object in the custom application class

Now, to lay the foundations of the walletconnect, we need to setup our CoreClient object. This object must be created in the Application Class. Since in android the application class is an implicit class, therefore, you would not see it in your kotlin class files.

We need to create a new Kotlin class and inherit the application class to override it.

Right click on your Java folder, click new -> Kotlin Class/File

Name the class whatever you want e.g. MyCustomApplication

This will create a barebones class for you like this:

Class MyCustomApplication {
}

Now, we need to inherit the class from Application Class and add our required methods

class MyCustomApplication : Application() {
    // Called when the application is starting, before any other application objects have been created.
    // Overriding this method is totally optional!
    override fun onCreate() {
        super.onCreate()
        // Required initialization logic here!
    }
    // Called by the system when the device configuration changes while your component is running.
    // Overriding this method is totally optional!
    override fun onConfigurationChanged ( newConfig : Configuration) {
        super.onConfigurationChanged(newConfig)
    }
    // This is called when the overall system is running low on memory,
    // and would like actively running processes to tighten their belts.
    // Overriding this method is totally optional!
    override fun onLowMemory() {
        super.onLowMemory()
    }

Once you have the methods in place, we can now create the WalletConnect’s CoreClient in the onCreate method.

override fun onCreate() {
    super.onCreate()
    // Required initialization logic here!
    val projectId = "" //Get Project ID at https://cloud.walletconnect.com/
    val relayUrl = "relay.walletconnect.com"
    val serverUrl = "wss://$relayUrl?projectId=$projectId"
    val connectionType = ConnectionType.AUTOMATIC // or ConnectionType.MANUAL
    val appMetaData = Core.Model.AppMetaData(
        name = "Test App",
        description = "Kotlin App",
        url = "Test App url",
        icons = listOf("https://gblobscdn.gitbook.com/spaces%2F-LJJeCjcLrr53DcT1Ml7%2Favatar.png?alt=media"),
        redirect = getString(R.string.deep_link_url)  // Custom Redirect URI
    )
    CoreClient.initialize(
        relayServerUrl = serverUrl,
        connectionType = connectionType,
        application = this,
        metaData = appMetaData
    ) { error -> Log.e("CoreClient_Initialization_Error", error.throwable.stackTraceToString()) }
    val init = Sign.Params.Init(core = CoreClient)
    SignClient.initialize(init) { error ->
        Log.e("SignClient_Initialization_Error", error.throwable.stackTraceToString())
}

Project ID needs to be created individually for each application from https://cloud.walletconnect.com/

The relay URL and server URL are fixed values and need to be used as-is. The connection type can be automatic or manual, but we will be using automatic connection type.

In the appMetadata, the redirect is an important parameter. It tells the android app where to return when a response is received from the wallet application. The deep link url needs to be unique for your app and must follow a certain standard. For this tutorial, the deep link url is “kotlin-plurality-dapp-wc:/request”

Its important to register this deeplink in the navigation graph as well, which we will do in the next step.

Once we have all the parameters setup, we can then initialize the CoreClient using and SignClient using CoreClient.initialize and SignClient.initialize methods as shown in the code above.

Step 4: Registering the deep link in the navigation graph

You must register a deep link in the navigation graph (navigation/nav_graph.xml) with the same link that you used as redirect parameter in the CoreClient object. Inside the <navigation> tag, add the following.

<deepLink
    app:action="android.intent.action.VIEW"
    app:uri="@string/deep_link_url" />

The deep_link_url string is “kotlin-plurality-dapp-wc:/request”. You can use it directly or add it in strings.xml file. Either way, it should be the same as the redirect parameter with which the CoreClient object was initialized.

Step 5: Create buttons for actions

Now we need to create two buttons for the two actions we will demonstrate in this tutorial. If you created a basic project, you will have a file layout/fragment_first.xml. Lets use this file to display the two buttons.

<Button
    android:id="@+id/button_pair"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/pair"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toBottomOf="@id/textview_first" />

<Button
    android:id="@+id/button_sign"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/request_sign"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toBottomOf="@id/button_pair" />

Adjust as per your project but we need two buttons which we will use to perform the pairing and signing operations. The buttons should roughly look like this:

Now we need to register clicks for these buttons so go to java/FirstFragment.kt file and inside the onViewCreated function, register the clicks for these buttons

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    binding.buttonPair.setOnClickListener {
        //logic goes here
    }
    binding.buttonSign.setOnClickListener {
        //logic goes here
    }
}

Step 6: Establishing the connection between android app and wallet

Now let’s dive into details on how to connect our app and the wallet. To do this, we will add the code in the buttonPair’s onclicklistener.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    var apprSession: Sign.Model.ApprovedSession? = null
    var deeplinkPairingUri: String? = null
    binding.buttonPair.setOnClickListener {
        // for proposer to create inactive pairing
        val pairing = CoreClient.Pairing.create()
        deeplinkPairingUri = pairing!!.uri
        val dappDelegate = object : SignClient.DappDelegate {
            override fun onSessionApproved(approvedSession: Sign.Model.ApprovedSession) {
                apprSession = approvedSession
                // Triggered when dapp receives the session approval from wallet
                Log.d("Session_Approved", "Session was approved by the wallet")
                Log.d("Session_Topic", "Approved session's topic is: "+ approvedSession.topic)
            }
            override fun onSessionRejected(rejectedSession: Sign.Model.RejectedSession) {
                // Triggered when Dapp receives the session rejection from wallet
                Log.d("Session_Rejected", "The wallet rejected the session")
            }
            override fun onSessionUpdate(updatedSession: Sign.Model.UpdatedSession) {
                // Triggered when Dapp receives the session update from wallet
                Log.d("Session_Updated", updatedSession.toString())
            }
            override fun onSessionExtend(session: Sign.Model.Session) {
                // Triggered when Dapp receives the session extend from wallet
                Log.d("Session_Extended", session.toString())
            }
            override fun onSessionEvent(sessionEvent: Sign.Model.SessionEvent) {
                // Triggered when the peer emits events that match the list of events agreed upon session settlement
                Log.d("Received_Session_Event", sessionEvent.toString())
            }
            override fun onSessionDelete(deletedSession: Sign.Model.DeletedSession) {
                // Triggered when Dapp receives the session delete from wallet
                Log.d("Session_Deleted", deletedSession.toString())
            }
            override fun onSessionRequestResponse(response: Sign.Model.SessionRequestResponse) {
                // Triggered when Dapp receives the session request response from wallet
                Log.d("Received_Session_Request_Response", response.toString())
            }
            override fun onConnectionStateChange(state: Sign.Model.ConnectionState) {
                //Triggered whenever the connection state is changed
                Log.d("Connection_State_Changed", state.toString())
            }
            override fun onError(error: Sign.Model.Error) {
                // Triggered whenever there is an issue inside the SDK
                Log.e("Error_In_SignClient_SDK", error.toString())
            }
        }
        SignClient.setDappDelegate(dappDelegate)
        val chains = listOf("eip155:1", "eip155:137")
        val methods = listOf("eth_sendTransaction", "eth_signTransaction", "eth_sign", "personal_sign", "eth_signTypedData","get_balance")
        val events = listOf("accountsChanged", "chainChanged", "connect", "disconnect")
        val namespaces = mapOf("eip155" to Sign.Model.Namespace.Proposal(chains, methods, events))
        // for proposer to create a session
        val connectParams = Sign.Params.Connect(namespaces,null,null, pairing!!)
        SignClient.connect(connectParams,
            onSuccess = { -> /*Session proposal was being sent successfully over pairing topic*/
                Log.d("SignClient_Connect_Proposal_Send_Success", "The sign client connection proposal was successfully sent to the wallet")},
            onError = { error -> /*callback for error while sending session proposal*/
                Log.e("CONNECTION_ERROR", error.throwable.stackTraceToString()) })
        startActivity(Intent(Intent.ACTION_VIEW, deeplinkPairingUri!!.toUri()))
    }
}

The most important function is the CoreClient.Pairing.create() which initiates the connection between the two apps. The SignClient.DappDelegate is then created in order to receive responses from the wallet app. Whenever our app requests something and the wallet app responds, the response event will be caught by one of the functions in this class.

Once the SignClient has registered the DappDelegate class using SignClient.setDappDelegate(dappDelegate)

Then we need to create a session request. Session request means that our app will ask to create a session with the wallet using certain parameters i.e. which chains, which methods, which events should the wallet allow. The wallet will see what permissions are being asked and will approve or reject the session accordingly.

We have only used required namespaces not optional namespaces in this tutorial but you are free to play around with the namespaces and permissions that are required by using different parameter values.

Finally, the signclient will create a connect session request using SignClient.connect function.

However, for the app to move from its own screen to the wallet’s screen, we need to start the deeplink intent activity using

startActivity(Intent(Intent.ACTION_VIEW, deeplinkPairingUri!!.toUri()))

Without this step, your app will not be able to open the wallet app.

Now, you can deploy the application to your android phone and click the pairing button. It will open the list of all wallets on your phone that are able to handle this request. In this tutorial we have used trust wallet because not all wallets have completely migrated to walletconnect v2.

You can also view your session connections from the settings in trust wallet

Step 7: Requesting the wallet to sign a message

Now, we will demonstrate how our app can ask for a wallet for a signature using its private key. The prerequisite is that the two apps should already have a previous connection.

We will use eth_personalsign method to sign a simple human readable message. For more complex requests, wallet connect also supports EIP_712 signatures but those are out of the scope of this tutorial.

For the signing request, we will use buttonSign’s onclicklistener.

binding.buttonSign.setOnClickListener {
  val sessionTopic = apprSession!!.topic
    val method = "personal_sign"
    val account = apprSession!!.accounts[0]
    val params = SignUtils.getPersonalSignBody(account)
    val chainId = "eip155:1"
    val expiry = (System.currentTimeMillis() / 1000) + TimeUnit.SECONDS.convert(7, TimeUnit.DAYS)
    val requestParams = Sign.Params.Request(sessionTopic,method,params,chainId, expiry);
    val activeConnection = checkNotNull(SignClient.getActiveSessionByTopic(sessionTopic))
    Log.d("Connection is active", activeConnection.toString())
    SignClient.request(requestParams,
        onSuccess = { req: Sign.Model.SentRequest ->
            /* callback for success while sending request over session */
            Log.d("Sign_Client_Request_Send_Success", req.toString())
        },
        onError = { error: Sign.Model.Error ->
            /* callback for error while sending request over session */
            Log.e("Sign_Client_Request_Send_Error", error.throwable.stackTraceToString()) })
    startActivity(Intent(Intent.ACTION_VIEW, deeplinkPairingUri!!.toUri()))
}

First we need to create a signing request. To do so, we need a method (“personal_sign”), a chainId and in the params, we need properly formatted message. To do the proper formatting, create a separate class SignUtils and add a method in it getPersonalSignBody as shown in the next step. Once all the parameters are in place we can use SignClient.request function to create the signing request and then trigger the deeplink intent activity using the

startActivity(Intent(Intent.ACTION_VIEW, deeplinkPairingUri!!.toUri()))

The SignUtil class looks like the following:

class SignUtils {
// Companion objects is how you define static methods in kotlin
    // To learn more visit here: https://kotlinlang.org/docs/object-declarations.html#companion-objects
    companion object {
        fun getPersonalSignBody(account: String): String {
            val msg = "My email is john@doe.com - ${System.currentTimeMillis()}".encodeToByteArray()
                .joinToString(separator = "", prefix = "0x") { eachByte -> "%02x".format(eachByte) }
            return "[\"$msg\", \"$account\"]"
        }
}

And that’s it!

Now if you run the app and click on the Request Sign from Wallet button, you will be redirected to the wallet like before which will show you the signing request

Note: Sometimes the signing request does not show the first time, so in this case try once more to see it. This is a known issue that will be resolved once the migrations to v2 will be complete.

The android project for this tutorial can be found here

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

New to trading? Try crypto trading bots or copy trading on best crypto exchanges

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

• Free Crypto Signals | Crypto Trading Bots
• An ultimate guide to Leveraged Token
• 16 Best Folding Electric Bikes
• 28 Best Electric Bikes Review
• Top 3 Binance Futures Trading Bots

Connecting your Mobile Apps with your Web3 Identity was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zero-Knowledge Proofs (ZKPs) have been considered a promising solution for privacy-preserving identification due to their ability to prove specific attributes without revealing the user’s identity. The concept of ZKPs has gained popularity as a way to address privacy concerns in identity verification.

ZKPs allow for the creation of cryptographic proofs that demonstrate the possession of certain information, such as age or qualifications, without revealing the information itself. They are generally perceived as a desirable solution for privacy-sensitive public applications, such as online identity verification, where users are often required to share personal information in order to prove their identity. Some public blockchains like Polygon are also looking into zero-knowledge proofs as a way to identify users on-chain (Link).

Here’s a hypothetical scenario where a user can prove something about him/herself with zero knowledge to a dApp:

1. A user, let’s call him John, wants to verify himself on a blockchain smart contract in a zero-knowledge way.

2. The smart contract requires that John prove that he is over the age of 21.

3. John uses a zero-knowledge proof to generate a cryptographic proof that he is over the age of 21, without revealing his actual age or any other personal information.

4. The smart contract verifies the proof, and because it was generated in a zero-knowledge way, it has no information about John’s identity other than the fact that he is over the age of 21.

5. The smart contract allows John to access its features or perform actions that are restricted to users over the age of 21, such as making investments or participating in age-restricted online activities.

6. Throughout the process, John’s personal information remains private and secure, as the zero-knowledge proof only reveals the information necessary to verify his age.

Reputation is an important aspect of identity verification but ZKPs un-link the proof from the reputation — thus creating a blind-spot

Before we dig deeper into the on-chain identification using ZKPs, let us discuss the concept of identity verification in Self Sovereign Identity (SSI). Reputation is a crucial aspect of identity verification and trust-building processes. A person’s reputation is tied to their real-life identity or previous actions. It shows the trust others have in their ability to fulfill their obligations and behave in a certain manner. It is a logical assumption that the users want to protect their identity and make sure it is not used by someone else for some malicious purpose due to the staked reputation.

However, ZKPs provide privacy benefits by allowing the user to prove their identity without revealing any personally identifiable information (PII). The logical reduction of claims made by ZKPs reduces the strength of the claims and makes them un-linkable with the user’s identity, negating nonrepudiation and enabling credential sharing via proxy. This privacy protection can create a blind spot in verification, as the verifier cannot trace the proof back to the user. This blind spot undermines the identity verification process’s trust without risking the prover’s reputation.

If the identity owner is compromised or is ‘evil’ and decides to sell the zero-knowledge proofs the end-to-end trust cannot be established.

In a concrete scenario where the user sells their credential to a malicious actor, the verifier will not be able to trace the malicious actor back to the user. As a result, trust in the user’s reputation can not be established due to the increased risk of fraudulent activities. For example, a malicious user could impersonate John and collude together with John to present a zero-knowledge proof to a verifier smart contract using John’s credentials, claiming that they are over the age of 21. These potential risks associated with using a co-relation resistant DID in combination with ZKPs can better be explained by reconsidering our example scenario:

1. John holds a credential that proves he is over the age of 21.

2. Bob wants to access age-restricted content on a blockchain-based platform.

3. John creates a DID and creates a ZKP that proves he is over the age of 21 using his valid credentials (VCs).

4. John does not want to give the access to his original VC to Bob but still wants to contribute to the fake verification of Bob. So he decides to sell his ZKP and DID to Bob.

5. Since John’s ZKP is un-linkable with his identity, he is able to sell his ZKP without risking his own reputation or original credential.

6. Bob uses John’s DID to present the ZKP to the smart contract, claiming that he is over the age of 21.

7. The smart contract relies on the reputation of the DID and accepts the ZKP, granting Bob access to the age-restricted content.

8. Bob uses access to restricted content for malicious purposes, potentially causing harm to the platform or its users.

John sells ZKPs via a proxy service to Bob and other third parties (Image Credits: https://ieeexplore.ieee.org/document/9031545)

In this scenario, the use of co-relation-resistant DIDs exacerbates the risk of exploitation through the blind spot created by ZKPs. In order to minimize this risk, it is important to consider implementing additional measures, such as reputation systems or manual verification processes, to ensure the credibility of the user presenting the proof.

In conclusion, reputation is crucial in identification systems, we can trust the identity owners in a permissionless system only due to their staked reputation. Identity verification using ZKPs poses a blind spot problem that can undermine the reliability and security of the system if not addressed explicitly. These scenarios highlight the trade-off between privacy and trust in ZKP-based identification systems and the need to balance these factors to ensure their secure and effective use in blockchain verifiers.

The trust paradigm and the blindspot presented in this article is originally stated in the paper “Zero-Knowledge Proofs Do Not Solve the Privacy-Trust Problem of Attribute-Based Credentials: What if Alice Is Evil?” (Link)

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

Risks of using Zero Knowledge Proofs for Identity Verification on Blockchains was originally published in Blockchain Biz on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous parts of this series, we talked about the concepts of Self-Sovereign Identity, how it differs from traditional KYC methods, and the benefits of using SSI concepts in blockchain for identification.

In this part, we would talk about the plethora of use cases that would open in the blockchain space if SSI based KYC processes come to the public blockchain world.

Currently, there is a huge gap in how we use centralized web2 in our daily lives with the decentralized web3.

In web2, you can:

1. Use search engines to search information.
2. Use online banking to interact with your bank account
3. Use learning portals to acquire new skills
4. Use social media to stay connected with the world
5. Use job portals to get jobs anywhere in the world
6. Use food delivery apps to get food at your doorstep
7. Use online fashion retail stores to order your dresses

And so on…

On the other hand, in web3, you can:

1. Buy crypto assets in a speculative market
2. Swap & lend crypto assets

That’s just about it! In the current scenario, the maximum web3 can offer is replace your financial interactions in the web2 world.

Web3 is no more than a bank account, for now.

If you think about a true decentralized society, web3 has a lot of catching up to do. One of the critical reasons that web3 cannot currently offer the web2 functionalities in a decentralized manner is because there is no decentralized way to identify people in web3.

You can do a centralized KYC on exchanges but natively there is pseudonymity in the blockchain. You cannot tell which address is which person simply by looking at the blockchain.

Pseudonymity is one of the most important and ground-breaking features of blockchain. However, it is a double-edged sword. While it offers a border-less anonymous way to transfer assets, it is also the reason why so much of the activity on blockchain is under stringent compliance regulations.

With the current legal systems in place, pseudonymity is hindering web3 to reach its potential of a decentralized society.

But does that mean we should let go of the ideals of decentralization just to be compliant? Of course not.

One way how web3 can replicate and even exceed the offerings of web2 while remaining compliant is to provide a native way to provide user-centric, privacy-preserving, decentralized KYC solutions.

Such a solution should not in any way replicate the same problems of centralization that web2 KYC solutions have. It should be decentralized, and the user should decide when, to whom and how much information should be revealed.

Therefore, an SSI based web3 native KYC solution can push web3 into the next generation where it can replace web2 completely and provide a better alternative for a decentralized society.

While a solution like this could open the possibility of a plethora of new innovative applications, it could also improve existing applications.

Existing solutions that can be improved using Self Sovereign KYC

1. Decentralized exchanges could use decentralized KYC instead of centralized KYC, saving both cost and the ideals of decentralization
2. Verification on social media could be made privacy-preserving platforms e.g., Twitter’s blue tick
3. Airdrops could become fairer by connecting them to real life identity of person so that the same person cannot get airdrop more than once
4. Decentralized Autonomous Organizations (DAOs) could be made more decentralized by ensuring the uniqueness of the real-life identity of addresses involved in a DAO
5. Web3 grants could be distributed more fairly by connecting them to the real-life identity of the grant accepters
6. Decentralized tele-health could be created where patients could disclose medical records to the medical personnel using selective disclosure
7. Decentralized elections where people could vote by showing that they possess a valid identity card

etc.

New solutions that can be created using Self Sovereign KYC

1. Inheritance solutions where the crypto assets of a person can be legally moved to the next of kin after death, upholding the local state laws
2. Decentralized social media connected to the on-chain wallets of the user and identity information revealed only as much as wanted by the user
3. Decentralized job marketplaces where people could reveal credentials to the prospective employers and get jobs
4. Decentralized mortgages where people could use real life assets as collateral to get loans, the same way they do today using banks
5. Decentralized marketplaces where people could buy and sell items peer to peer, demanding the other person to verify themselves before a trade if and how they require
6. Decentralized dating apps where it’s up to the people when and how they want to identity the person they are contacting

And the list goes on…

To cut the long story short, a native identification solution for web3 adhering to the principles of self-sovereign identity would not only improve the current identification solutions in web3 but would also pave the way for a new generation of innovative solutions in web3.

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

In our last article, we talked about how the current centralized KYC systems can be improved using Self-Sovereign Identity (SSI). We explained that by using SSI, not only can the cost of KYC be reduced, but also the control can be provided back to the users. Users can decide when, to whom and how much of their information is being shared with external parties. Lastly, we made a case that over all the KYC process needs to become decentralized due to data breach possibilities in the centralized system.

SSI can improve KYC process by introducing decentralization, reducing cost by reuse and by returning control back to identity owner.

But what exactly is this new fancy term Self-Sovereign Identity, and what’s so special about it? Let’s get the ball rolling…

The mumbo jumbo of Self Sovereign Identity

Self-sovereign identity refers to a system of identity management in which individuals or organizations have full control over their own digital identity and personal data. This means that individuals are able to choose what personal information they share, with whom they share it, and for what purpose.

In SSI, individuals decide what, to whom, and how much to share!

SSI is attractive because it improves privacy and reduces the risk of data breaches or misuse. With traditional identity systems, personal information is often stored in centralized databases that are vulnerable to hacking or data leaks. In contrast, self-sovereign identity systems use decentralized technologies such as blockchain to store and manage identity data, which can increase security and privacy.

I know what you are thinking right now: that it’s poh-tay-to / poh-taa-to. When we are presenting our identity information to a third party, the information is being shared anyways so what exactly is the difference here?

The answer is in two terms: Selective Disclosure and Decentralized Identifiers.

Selective Disclosure

Selective disclosure refers to the ability of an individual to control which pieces of their personal identity information they share with others. In SSI systems, individuals decide which aspects of their identity they want to reveal to others, while still being able to participate in online interactions and transactions that require some level of identity verification. Selective disclosure is an important feature of SSI systems because it allows individuals to balance the need for privacy with the need to verify their identity in certain situations.

Selective disclosure balances the need for privacy with the need for verification

As an example, think of yourself trying to prove that you were born in a certain state using your identity card. In a traditional KYC system, you will need to present your entire identity card since there is simply no way to split or cut information out of the identity card.

However, this provision is baked into the protocols of SSI and you can choose to disclose as little identity information as required.

Decentralized Identifiers (DIDs)

A DID is a unique identifier used specifically to identify an individual or organization in an SSI system. It is stored on a decentralized platform, such as a blockchain, and can be used to authenticate identity, verify attributes, and establish trust relationships. DIDs are cryptographically signed and can be used to prove the authenticity and ownership of various types of digital assets, such as documents, transactions, or certificates.

Correlation Resistance

Correlation resistance is an important property of decentralized identifiers (DIDs) that helps to protect privacy. It refers to the ability of a DID to resist being correlated with the identity of the owner. This is achieved by using a decentralized platform, such as a blockchain, to store and manage the DID. Because the decentralized platform is distributed and decentralized, it is more difficult for third parties to track and correlate the DID with the identity of the owner.

In other words, I can have 10 DIDs that I use for 10 different online interactions, and nobody will know that these 10 different interactions are done by the same person, unless I specifically want to prove it.

In the context of Know Your Customer (KYC) processes, correlation resistance can be useful because it allows individuals or organizations to share their identity information in a secure and private way. For example, if a customer provides their DID to a financial institution as part of a KYC process, the institution can verify the identity of the customer without learning anything else about the customer’s personal information. This can help protect the customer’s privacy and reduce the risk of identity theft or fraud.

Relationship between DID and Blockchain Address

As opposed to a DID, a blockchain address is a unique identifier that is used to identify a specific blockchain account or wallet. It is usually a long, alphanumeric string that is associated with a particular blockchain network, such as Bitcoin or Ethereum. Blockchain addresses are used to send and receive cryptocurrency or other digital assets, and they can also be used to store and manage these assets.

There is often a relationship between a DID and a blockchain address, in that a DID may be associated with a particular blockchain address. For example, an individual may use their DID to prove their identity and ownership of a particular blockchain address. In this case, the DID would act as a sort of “identity layer” on top of the blockchain address, enabling the individual to prove their identity and ownership of the blockchain assets associated with the address.

Overall, DIDs and blockchain addresses are both useful tools for identity management and asset management in the digital world. They each serve different purposes and are used in different contexts, but they can also be used together to enhance the security, privacy, and verifiability of various digital transactions and processes.

To bring our entire (social, personal and professional) identities on chain, we have to use a combination of blockchain addresses and DIDs to make this possible.

If we use only blockchain address to create an identity system on chain, we will end up creating solutions that have same problems that the current systems have, just in a different form.

In the next part, we will talk about all the use cases that can be possible if we create an on-chain privacy preserving identity system. Stay tuned.

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)

KYC checks are a vital component of financial regulation that help to prevent money laundering and terrorist financing. These checks are required for financial service providers, banks, and blockchain-based businesses to verify the identity of their customers and assess any potential risks they may pose. Traditional KYC methods, such as manual and online identity verification, video, and biometrics, can have limitations, such as a high risk of errors and duplicated efforts.

Centralization is a bad idea — especially when it comes to identity

Currently, the security of verification comes from a centralized organization that verifies and stores the identity information of a person. This centralized party then relays this information to the business that requested the KYC checks and lets them know which users are verified and which are not. A classic example of this is using centralized KYC providers or in the web world, using oAuth protocol to onboard users.

These approaches have served us well and long. However, they come with certain drawbacks:

1. The centralized party holding all the identity information can become a honeypot for attackers

2. More than necessary identity information is relayed to businesses who only need to know whether to grant or deny access to a certain individual based on the KYC check

3. User has no control over when, to whom, and how much of his identity information is being revealed

Duplication in verification: twice the effort, twice the cost

Most KYC vendor charges per customer. Even if a meager amount of $1 is charged for the KYC of a single customer, onboarding 1 million customers would mean paying a million just for onboarding!

This is not the end of the problem. Every new business must pay for the KYC of the customer to its platform even if that customer has been KYC’ed 10 times before.

In the current KYC systems, there is no provision of reusing the previously done verifications.

How Self-Sovereign Identity can solve the above problems

Know Your Customer (KYC) checks and Self-sovereign identity are closely related concepts that are both enabled by blockchain technology. Self-sovereign identity refers to the use of blockchain to enable individuals or organizations to prove their identity in a secure, privacy-preserving, and decentralized manner. This can be used for a variety of purposes, including access control, secure online transactions, and, most relevant to this context, KYC checks.

Self-sovereign identity represents a promising alternative to traditional KYC methods.

By using blockchain to store and verify identity information, self-sovereign identity allows individuals to own and control their own digital identities, rather than relying on third parties to verify their identity. This gives individuals more control over their personal information and reduces the need for businesses to collect and store sensitive data. Self-sovereign identity can also improve the efficiency and accuracy of KYC checks, as individuals can use their digital identities to provide verifiable credentials that can be easily verified by businesses.

Self-sovereign KYC is a specific application of self-sovereign identity that uses blockchain technology to facilitate KYC checks. In traditional KYC processes, individuals typically must provide proof of their identity to a verifier, who then assesses their risk profile. However, with self-sovereign KYC, businesses can use a simple token to verify that an individual has already been checked by a specific verifier. This reduces the amount of personal information that businesses need to collect and store, as well as the number of parties that need to handle this data. Self-sovereign KYC also minimizes the risk of data breaches, as only the verifier needs to store the individual’s credentials, and they must have robust cybersecurity measures in place to protect this information.

Overall, the integration of self-sovereign identity and KYC can help to create a more secure, transparent, and efficient financial system. By using blockchain to facilitate the verification of identity and risk assessment, businesses can streamline their processes and improve the accuracy of their risk assessment efforts. They can also save cost by reusing the previously done verifications. At the same time, self-sovereign identity empowers individuals to own and control their own digital identities, giving them greater control over their personal information and reducing the risk of identity fraud.

In the next part of this series, we talk about what self-sovereign identity really means and how they provide a better alternative to centralized KYC using the powerful concept of Decentralized Identifiers (DIDs).

Hey there, thanks for reading this far.

Plurality is a product that offers Decentralized Identity for the Decentralized Society.

If you like this story, don’t forget to follow our twitter and leave a clap. :)