Step 1. Authentication.
Take Twitter as an example of an online public platform (Twitter will come integrated into Snax blockchain at the time of main net launch).
Let’s assume that you have a Twitter account and that you want to complete authentication in the Snax blockchain using that account. Authentication will be done using the following algorithm:
- Client (user) generates a pair of keys (priv_key, pub_key).
- Client selects any unassigned account name (snax_name) on the Snax blockchain (snax_name account will be registered on the blockchain).
- Client generates a key (K).
- Client calculates a hash function
H(K, snax_name)=hmac_sha256 (K || hmac_sha256 (K || snax_name))
- Client publishes received hash H by creating a tweet from their Twitter account, acknowledging their intent to complete authentication on the Snax blockchain.
- Client sends the following information to an oracle:
– Pair (K, snax_name)
– Their pub_key, for which the account name snax_name will be registered.
– Their account name N on Twitter and a link to the authentication tweet (optional, as the authentication tweet can be found by the oracle on the feed using Twitter API)
- The Oracle then calculates your hash H and compares it with the hash, found in authentication tweet. If the hashes are identical, the Oracle considers the authentication process to be completed.
- Oracle calls on the registration method of the Twitter platform smart contract with arguments of (K, snax_name, pub_key, N, L).
- The Twitter platform smart contract then registers account snax_name with the public key pub_key and adds information to the blockchain about successful authentication of a twitter user N, a public key K, and a link L.
Step 2. Proof.
It is now essential to explain why the third party might not trust a centralized oracle which has completed the authentication of the user.
Let us consider the following possibilities of a vector attack:
- Oracle being compromised.
- Forgery of a user’s authentication request by an intruder.
Main defense against this attacks comes from the impossibility of brute forcing the incoming data (K, snax_name) which would satisfy the authentication hash H.
Because the authentication tweet, which contains hash H, is published on Twitter by the owner of the twitter account, an intruder does not have an ability to generate a valid pair (K, snax_name), apart from the one which was provided by the actual owner of the account.
This way, any third party, at any moment of time, can verify the authentication by the owner of the Twitter account N using the following algorithm:
- Take the embedded into the blockchain pair about the authentication of the user (K, snax_name).
- Generate hash H(K, snax_name).
- Go to the published link L.
- Verify that the account which has published the tweet L indeed belongs to the account of the user N.
- Check the presence of hash H in the tweet L.If the hash is found, then the user authentication is valid.
Step 3. Using Snax account as an authenticator.
Now, that the authentication of a user can be proven, the name of the blockchain account snax_name can be subsequently used as an authenticator of the user of Twitter N. For example, Snax blockchain uses snax_name of the account N for the emission of the SNAX tokens.
This process would also make it possible to create a transaction to any account of the public network, integrated into Snax platform, without a prior invoicing by the recipient. Platforms smart contract will automatically complete the transaction to the snax_name from which the authentication of the receiver has been completed. If the authentication has not yet been finalized, then platform smart contract will wait for its completion to perform the transaction.