Verify profile with external services

[kwunyeung]

Feature description

Besides IBC signatures, we need a way to let users to verify if the profile is owned by a public figure. The recent post from Cosmos Network on Mooncake raises this issue. And we don't want to see the scam of the recent and the Twitter hack. If a recognizable public figure is making a post on Desmos, a lot of users may follow on what they are speaking and it's possible to fall in traps if the owner of the profile can't identity in another way.

Profiles on Desmos should leave as anonymous as the first choice but we should leave an option for the users to choose if they want to expose their real identity and connect to the outside social world. If users choose to use their real identity, then we need a way for other users to verify if they are the owners of the outside social world.

One approach is to request for a secret action being done on other platforms. A way Solana is doing is to ask validators to provide a keybase username. Under the public folder of that username, it stores the public key of the validator identity key. The CLI verify if the key exist in the public folder before broadcasting the update transaction. But this is done on the client side not on chain.

https://github.com/solana-labs/solana/blob/1c498369b571284b74474ba2e7f9f51fc4e099fd/cli/src/validator_info.rs#L271

It should break if the validator remove the username verification and build locally.

Is there anyway that we can do that on-chain which can also connect to other channels? Or we can only rely on the clients to verify the keys when they display the profile?

[rmontagnin]

Currently our problem is that once you verify a Keybase account with multiple social networks, and then publish somewhere your public key, anyone being able to read public key can impersonate you. This doesn't mean that Keybase is doing something wrong. It just tells us that how it's being used is wrong.

Cosmos does not verify any association between the address and the verified Keybase, it just tells you "If you copy it here, we're going to get those info to display the picture". The fact that this shouldn't be considered a proper check is also that multiple validators can have the same identity associated to them. To prove this, I've just copied @bragaz validator identity into my validator.

To solve this problem, I think that out approach should be similar to what Keybase is doing. What we can do is define multiple services that can be used to verify the user identity (Twitter, Reddit, GitHub, ...). Ideally, any platform that allows for public access of a part of the user material could be supported. For each service, we need to implement a process that allows us to verify the ownership of a profile on that platform for any given user. The easiest thing to do is generating a content that the user should parse into a public space (Gist for GitHub, tweet for Twitter, etc) and then asking the link to that content. This content should also have an expiration time (like 10 mins) after which it is considered invalid. Then, once the user has verified that service, we store the connected account in a unique way. This would make it impossible for other users trying to steal identities to do so.

[leobragaz]

To solve this problem, I think that out approach should be similar to what Keybase is doing. What we can do is define multiple services that can be used to verify the user identity (Twitter, Reddit, GitHub, ...). Ideally, any platform that allows for public access of a part of the user material could be supported. For each service, we need to implement a process that allows us to verify the ownership of a profile on that platform for any given user.

Considering that probably most of the future desmos' user will not come from the crypto world this type of verification is a must have and it will be widely used on dApp along side the verification through IBC.
From the next week I will start studying how keybase has implemented that and report everything here.

[kwunyeung]

Getting the validator Keybase pubkey has been proven to be a mistake. I see a lot of people copy and paste cosmos document to create validator and that's Peng Zong's key suffix 🤣. The problem is that it's not possible to verify the owner of the key from the Keybase suffix. The Identity field in the types/Validator has been misused. The length of this field is 3000. I guess the original idea of this field was to put a signature from certain kind of message signed by the node operator.

If you see how Solana is doing, they ask the validators to save the Solana id pubkey as a file in the users' Keybase public folder. The CLI would read the signer's address and Keybase username. Then lookup the public folder of the Keybase user and see if that file exist, verify if the tx signer address is the same as the address saved in the file.

The same idea can be applied to Gist or Twitter even domain name TXT records. The problem I'm thinking is this can only all be done off chain before the tx is broadcasted. We cannot do the verification on chain as IBC. If we put the verification part on chain then the full nodes will have to query the external services when they process the tx. That would lead to non-deterministic result. If this can't be verified on chain then imposters can still change the codes to bypass the checking and broadcast the tx to be validated.

If this is what we can only do, we should accept this way and rely on the client side the do the verification. For example if a profile has Keybase username and Twitter handle attached,the client app need to query those services to verify the identity when they display the profile.

[rmontagnin]

The problem I'm thinking is this can only all be done off chain before the tx is broadcasted. We cannot do the verification on chain as IBC. If we put the verification part on chain then the full nodes will have to query the external services when they process the tx. That would lead to non-deterministic result. If this can't be verified on chain then imposters can still change the codes to bypass the checking and broadcast the tx to be validated.

@kwunyeung Those were the same doubts as mine.

In order to find a solution, I've firstly thought about our problems:

1. We cannot rely on external services as they would be non deterministic.
   This means that when a new validators joins, it might have a chance of getting wrong data and consequently a wrong state.
   A solution to this is to have the data somehow stored on the chain.

2. We cannot trust the client to insert the correct data.
   Users might put fake data if asked for the proof of something, making the whole system useless.

A solution I've came up with is by using oracles.

What we can do is use the blockchain as a mere communication layer between users that want to get verified, and external actors that can verify the information by connecting to external services.

The process I've thought about is something like this:
(I will use Twitter as an example but this can be applied to everything)

1. The user creates a tweet to verify his identity.
2. The user asks to be verified, using a transaction inside which it places his Twitter handle.
3. Oracles read the transaction, and get the Twitter handle. They then go into his tweet and get the one he has created.
4. Oracles perform a new transaction telling whether the validity check was successful or not.

This would solve all our problems:

1. The user cannot fake the validation as he is not in control or the result.
2. Once oracles put their result on chain, that becomes deterministic.

I would say that the best way to implement this is to allow for multiple oracles at the same time, and computing the result of the check by an average of all the oracles results.

This system would also allow us to introduce another type of user into the system that might act as a pure oracle, earning Desmos through checking data validity.

[kwunyeung]

@riccardom interesting! I like this approach! We then introduce a new actor on the network with a wider spectrum of incentives. We aso emphasize the importance of the decentralized profile on Desmos.

[leobragaz]

I was reading on this https://book.keybase.io/guides/proof-integration-guide and I wondered if we need some sort of proof when checking user's external services or not. @riccardom

[rmontagnin]

@bragaz Of course we do 😁 The idea is to do exactly what Keybase is doing:

1. We generate a proof to be posted on different social medias (Twitter, Reddit, etc). This is going to be formatted based on the desidered social media.

2. We require the user to post that proof onto his social media.

3. We require the user to perform another transaction when he has done so, to confirm it.

4. From the transaction, the oracles will verify the proof accordingly, and post the result into the chain itself.

[leobragaz]

So probably what we could do is generating it when a user create his profile. Later the user will get this proof when he need to start the verification flow.

One question about Oracles:
Are they supposed to be some sort of flagged accounts known as Oracles? Or everyone could request to be one of them?

[rmontagnin]

@bragaz Actually, I think it's better to generate the different proof at the beginning of the authentication method. This is due to the fact that each social might request a different proof. As an example, on Twitter it must be less than 280 chars long, while on Reddit we do not have any length constriction.

About oracles, I think they should be special accounts. They should have been specified inside the genesis, or maybe elected by the community though a custom governance proposal. I haven't thought about it in depth tho. Any suggestion is welcome.

[leobragaz]

@riccardom I think that probably having them only inside genesis could be a problem if they will no longer active in the future.
To solve this we can use gov proposals as you suggested.
We should also have some checks on Oracles' downtime so if they are not validating profiles for a long time they will be removed from the group. Each one of them also should be already been verified when he start to do profiles' verifications.

[rmontagnin]

@bragaz

We should also have some checks on Oracles' downtime so if they are not validating profiles for a long time they will be removed

I'm not particularly in favor of this. Having a specific uptime requirement might not be the best choice in our case. Suppose as an example that an oracle only validates Reddit connections. What would happen if no user wants to connect his Reddit profile to Desmos? No validations will be required and such oracle would appear as not validating.

Since this could happen with every social media, I would avoid forcing a minimum validation requirement. Instead, we can allow the governance to decide when an oracle should be removed from the set.

---

Each one of them also should be already been verified when he start to do profiles' verifications.

Who should "verify" such oracles? In a centralized world there would be a particular entity responsible for this. But this cannot happen inside Desmos, which we hope will be highly decentralized.

Instead of verifying oracles, I think a better solution is to leave the space open for anyone who might to do this work. In order to mitigate fake verification results, we can then use a probabilistic approach to it.

Suppose that Alice wants to validate her profile, and the output of different oracles is the following:

Oracle	Validity output
Oracle A	Valid
Oracle B	Valid
Oracle C	Not valid

Then the probability of the profile being valid if 2/3 (~66%) which is high enough to be considered true.

Of course this approach works best when a higher number of oracles are present. For this reason, I think we should:

1. Build an oracle daemon software that can be run parallel to a validator easily by anyone.
   This will make it easier to get more and more oracles over time.

2. Incentivize people who run validators.
   What we could do is require users to specify a validation fee when asking for profile validation. Then this fee will be distributed across the oracles that voted the same result as the global one. This way we will incentivize oracles to always act properly in order to have a higher chance of receiving the reward. Also, such fee could be used by oracles to determine the order in which to validate the different profiles.

Please let me know what you think about this as well @kwunyeung

[kwunyeung]

I'm playing around with Band Protocol recently and I think we can share some ideas from them.

Band Protocol

https://docs.bandchain.org/references/technical-spec#d-3-n-system-overview

Validators can activate the oracle from their account. From time to time, validators will receive oracle requests from the protocol. If a validator receives that request, the validator needs to report the prices of the tokens. The following is a list of the report transactions of our validator on the latest testnet.

https://guanyu-testnet1.cosmoscan.io/validator/bandvaloper12w7p4e3suvjpg84mqdh5k5n9h6x7zsc3e8jtwn#reports

This is one of the requests

https://guanyu-testnet1.cosmoscan.io/request/18776

You can see that the request requires a few validators to report. It has a minimum report requirement. If it reaches that minimum number of reports, the price report is consider successful.

They have built different modules in the protocol but not only the chain.

https://github.com/bandprotocol/bandchain

There is an Oracle Binary Interface called obi and an oracle report daemon called yoda (yes obi and yoda). Validators run yoda to subscribe report tx from the chain. Once it sees the report tx includes the validator itself, the validator will send a report tx.

https://github.com/bandprotocol/bandchain/tree/master/obi
https://github.com/bandprotocol/bandchain/tree/master/chain/yoda

The chain runs oracle scripts in WASM to calculate the token prices.

Conditions on Desmos

1. There will be a lot of profiles, assume all accounts are linked to a profile.
2. Profiles will have proofs from different external networks.
3. Profile proof should not be changed frequently.

Suggestions

1. Each profile proof has an expiry date, e.g. 12 months like a domain name
2. As there will be a lot of profiles, we should let the user request for the validation. A user send a tx to request for external validation of the profile. This can be triggered the first time when the user add a new external service.
3. Once the chain gets this request, it emits a request to a group of oracles. For example, a group of 8 oracles, we need 6 of them to report the validity of the proofs, under the circumstances that we take 2/3+ as consensus.
4. Oracles don't have to be validators. We can create a new actor type on Desmos. Agree on @riccardom suggesting on build a daemon, this is like how Band is doing with yoda.
5. The problem is if the address don't have stake, can it be an oracle? We can set a barrier that the oracle has a minimum delegation on the network in order to become an oracle.
6. Oracles should be rewarded. Agree on @riccardom setting a fee for the profile verifications and the fee is distributed to the oracles. We can generate a separate reward pool just for the oracles.
7. On Band, oracles will be deactivated if it's not reporting for a certain period of time. We can do the same thing so that the reward only goes to active oracles.

[rmontagnin]

@kwunyeung I really love this approach, but I have one question.

Each profile proof has an expiry date, e.g. 12 months like a domain name

Why is this necessary? Once the profile is validated, can't we assume it will for the time being? Why do you think that having an expiration date on the proof is better?

[kwunyeung]

What if the owner of the external service account has been changed? Requesting the profile owner to validate again is to confirm that the proof is still valid after a period of time.

[rmontagnin]

What if the owner of the external service account has been changed? Requesting the profile owner to validate again is to confirm that the proof is still valid after a period of time.

Should we then allow users to decide the length of the verification validity allowing them to specify it when the perform the verification?

[kwunyeung]

@riccardom good question. Let's make it a parameter in the module which can be changed by governance proposal.

[rmontagnin]

@kwunyeung What if we allow each user individually to specify the validity of its verification method? This also might be useful to have different connections with different time validities (eg. Twitter 100 days, Reddit 50 days).

Also, some users might want longer times and others might want shorter ones. And thus will provide more freedom to applications as well

[kwunyeung]

@riccardom I am not sure how much benefit will give the users if letting them to choose their own validation period for each network. The validity period is only an indicator to suggest the users should request for validation before a certain day. Even if the validity period not reach, the user can request the oracles to validate the profile every month and the period will be extended. This is similar to requesting a new SSL certificate from the certificate authorities. The certificate will expire on a specific day but you can renew it before the current certificate expire.

[rmontagnin]

@kwunyeung Althought it might not benefit users directly, I think it might be still useful to have it customazible on a per-user base.

Most of the times, accounts will not be created directly by users, but by the application their are using when registering the first time. Since different applications might want different verification validity times (one might want it shorter and another one longer) I think it would be better to have it customizable.

We can make it so that it's optional to specify it and the default value is written inside the module params, so that it can be changed by the governance. This way we would have the best of both worlds: customizability if needed and a default value if someone does not care about a custom value.

[kwunyeung]

Ok! We can have that flexibility. Please go ahead in this direction.

[rmontagnin]

Today I started thinking again about this discussion, since it might be interesting to implement this feature in the near future.

As @kwunyeung mentioned Band, I took a look at their chain code as well as their yoda code. From what I can see, all their chain is thought to work not only with something that is related to prices, but with pretty any verification that should be done by external actors. They allow to create any kind of data source, and inside such source you specify the executable wasm code that should be run to verify a data. In particular, the flow is the following:

1. You create a data source using a MsgCreateDataSource and specifying

• the owner of such data source
• the executable code to be run by validators upon execution

2. Anyone can request a data, using a MsgRequestData and specifying:
   • the oracle script to call
   • the arguments with which to call the executable script
   • the number of validators that should perform the validation
   • the minimum number of validators sufficient to resolve the task
3. Thanks to yoda, validators read the MsgRequestData, get the arguments and call the proper executable script with such arguments.
4. Once execution is completed, each validator reports the result using a MsgReportData

As you can see, since Band allows any kind of wasm binary code to be uploaded, it means that validators can perform any kind of task when submitting some data.

For this reason, I think it might be extremely interesting to use directly Band as a oracle provider. We could create some data sources there and have Desmos ask for data using IBC. This would allow us to delegate all those activities to them without having to worry about any problem that might be, and only have the returned result.

What do you guys think?

EDIT
Adding some references here to Band documentation:

• System overview
• What are data sources

[kwunyeung]

That's great! I haven't thought of this possibility! It will be super interesting if we can rely on Band for getting external network verifications. It's worth exploring further on this idea.

[leobragaz]

Basically what we need to do is:

• create a data source that fetch someone's identity from somewhere;
• write a "contract" that performs some checks on someone's identity;
• compile it to a wasm binary;
• deploy it on band chain (through IBC);
• run the script with users different data
• get the results and confirm the verification

Did I understood well?
I think this is a very clever approach, delegating verification stuff to band which core feature is verification would be a very clever usage of IBC and a good application of separation of concerns principle.

[kwunyeung]

I think it doesn't have to be via IBC. We can deploy the WASM contract on BAND directly. They are not using CosmWASM.

[rmontagnin]

@kwunyeung is right, we don't need IBC to deploy the data sources nor the Oracle contract. The flow will be something like:

1. We create a data source on the Band chain
2. We create a Oracle script on the Band chain
3. Using IBC, we call the Oracle script from Desmos, instead of requiring the user to have the Band CLI installed

On a very high level, the overall process would be something like this:

1. We generate a proof by signing the Twitter username with the user's private key, and we put into a JSON object.
2. We require the user to:
   1. Upload the JSON object on a public place where it can be access by a public link (IPFS, their website, etc)
   2. Post the public link to the proof either in a public tweet or, if their profile is private, inside their bios.
3. The data source will fetch the link from where it has been posted (tweet or bio), and get the contents.
4. The Oracle script will make sure that the proof is signed with the user private key. If everything is valid, the verification proof will be stored on the Band chain.
5. We can access the Band chain proof and store a reference on our chain to signal the link was verified.

[kwunyeung]

We have both rpc of band Mainnet and testnet.

A side note, we will have to consider how to handle the profiles when the DTag ownership is being transferred.