Ethereum Sidetree Protocol: Technical Breakdown

This is another cool (GUI) addition for the Ethereum fans out there.

Of course, this is an open source repository (original source code can be found here: https://github.com/decentralized-identity/element).

Gist of the Sidetree Protocol

Basically, this is a non-token based use case for Ethereum (gasp! yes, they exist), that is premised on the idea of pegging external protocols / authentication workflows / etc., to fixed data on the blockchain.

The graph below (I feel like a dick for using this - but its so accurate) details how this works in the most literal, straightforward manner possible:

Brief Example

This is pretty abstract, so I'm going to do my best to break this down a bit further.

Note: This has nothing to do with the actual functionality of the platform itself; I'm merely explaining how this works so that you can gain a better understanding of it on a conceptual level. Trust me when I say that this is a lot easier to grasp than it may seem on the outset

Step One: Random Transaction on the Blockchain

We've all done this at some point in our lives - a regular transaction on (any) blockchain (Ethereum in this specific instance though).

Result of the Transaction

Below is a transaction panel (from Etherscan.io):

This is all familiar right?

Step Two: Pegging Some Sort of External, Real-World Significance to the TX Hash

So even though you may forget about the TX IDs of your individual transactions after you're finished sending your cryptocurrency from one wallet to another - that TX hash remains on the blockchain in perpetuity (for simplicity's sake, let's assume that no unforeseen crazy, blockchain reorganizing events manifest).

This means that we should be able to revisit that transaction in, let's say --- four years from now and validate that very same transaction ID.

For clarity's sake, this is the transaction ID that I'm referring to:

Boom, that's it - what you see there in red rectangle. You can ignore everything else below that (although this transaction is fairly interesting...).

Transaction ID = 0x0f276d32a60829cf31e381890851e5d1b8bb8fc99a6a2e40142eeb8be72c7df9

Step Three: Curating Some Ideas For What You Can "Anchor" This Hash To

Imagine you're a Librehash subscriber (crazy concept, right?) and you paid this maniac they call, 'Cryptomedication' for a membership.

But you're an extremely paranoid person (and so is Cryptomedication to an extent), so you guys decide that you'd rather do away with regular logins premised on one's e-mail account (since this contains a lot of personally identifying information).

At first, it seems that you and Cryptomedication are at an impasse where you must inevitably divulge your e-mail address to him so that he has some way of uniquely identifying and differentiating you from other users on the platform (remember, you're a paying subscriber, so it is important that Cryptomedication be able to persistently identify that you are one so that you can retain perpetual access to the various applications, perks and features that accompany an active subscription).

Our Solution = Anchoring the Hash

An alternative to extracting any personally identifying information from you would be to instead:

1. Record the TX ID (hash) of all membership payments.

2. Blockchain API / JSON RPC modules (and an array of countless other query tools), allow us to quickly identify the one responsible for generating said TX hash (i.e., the sending address).

3. If I create some sort of authentication mechanism on my platform that merely requires you to authenticate that you are the owner of said wallet (i.e., like you "signing" arbitrary data / statement with that Ethereum address) - then that's all the assurance that I need to allow you access to various facets of the platform.

ETH DID JWT Tokens

As if things couldn't get any better than this, I was able to find some additional repos (created by the same originators of the Sidetree Protocol implementation), that leverage the JWT API token standard alongside the sidetree protocol.

Explaining JWTs

In a nutshell, these are 'bearer authentication tokens' distributed to your browser via API.

These tokens are presented to the relevant website in question that you're logging into in order to validate that you have permission to be in certain areas.

Example: 'When is This Needed?'

Imagine you're logging into a website like Facebook, right?

Obviously, there is a general login screen / prompt where all users must enter their information in order to access certain features of Facebook.

But, beyond that, there are several other authentication streams that must be accounted for as well (these are commonly referred to as "views").

Explaining What I Mean a Bit More

When you log into your Facebook account, Facebook's servers / system on the backend needs to ensure that you only access information that you're authorized to access.

In other words, when you click on your 'Direct Messages', Facebook needs some sort of implementation in place that ensures that you're only able to view YOUR specific Direct Messages and not the Direct Messages of 'Amy', 'Bob', 'Adam', 'Sue', etc. (for obvious reasons).

This is Where JWT Tokens Come in

These bearer authentication tokens remain in your browser's local storage throughout the duration of your session (and more than likely until your browser history / cache / cookies are cleared).

You won't notice this unless you open up your browser's 'DOM module'(screenshot below):

referring to that black box / module that you see at the bottom of the screen in the screenshot above

Behind the Scenes Authentication is Occurring Repeatedly

Everytime you click on a panel like "Direct Messages" (and virtually anything else), the server will request your bearer authentication token (which is usually relayed in JSON).

Once that payload is received by the server, it determines:

1. What kind of 'view' you should be shown (i.e., if you're just a regular user, the server needs to make sure that you're not shown the administrator's view of the webpage - which more than likely includes a plethora of additional options that regular users cannot see).

2. Whether you are actually authorized to be access the URI resource point that you are attempting to open up (i.e., "Is Bob allowed to be visiting 'www.example.com/files/images/vacation.png' on this server?")

3. What permissions (if any) you should be granted in relation to the resource being accessed

4. Is there anything in specific that should be returned to the client? (i.e., the server can also return information to you based on the bearer authentication token that you present -- an example of this would be the retrieval of your Direct Message history with all of your friends on your profile ; after authenticating your user on the site, Facebook will retrieve your relevant private message history and present it to you in your inbox). Additionally, if anyone attempts to contact you while you're online (or 'authenticated'), Facebook will retrieve that message and "notify" you with an alert of some sort (another example of the JWT tokens + API being used to retrieve data specific to the token itself).

Back to the Ethereum DID Sidetree Protocol

Given what I wrote above, I'm sure that it is becoming increasingly obvious how this Sidetree protocol mechanism could be leveraged for an infinite number of use cases.

Think about it:

1. Blockchains are built to be distributed and decentralized, by nature. So you don't have to worry about any 'man in the middle' distorting the information that you're receiving (unless you're retrieving that information from a singular source...like Infura, but that's another story).

2. Blockchain is built to be 'trustless', so you're not relying on the 'honesty', 'integrity', 'competency', or 'resilience' of any given source or entity to maintain the accuracy of the records you're retrieving from the blockchain (in this hypothetical case, we're sourcing information in relation to the pseudo-transaction ID produced by our Librehash subscriber payment).

3. Ethereum (at least for a short while longer) provides a (virtually) immutable ledger of all transactions that have been confirmed (and attempted) on the chain, which will be persisted in perpetuity for external validation. On top of this, the concept of 'Proof of Work' itself, provides a near-insurmountable barrier for any 'attacker' looking to publish an alternate, "incorrect" version of the blockchain that ultimately out-competes the 'honest' chain (which we're polling data from for verification / validation / authentication in this foe external Sidetree protocol chop shop we've created).

On top of everything mentioned in the numbered bulletpoints above, blockchains provide the additional inherent benefit of mandating the creation and use of wallet addresses in order to receive and send funds on the blockchain.

The Importance of Wallet Addresses

As mentioned at the beginning of this piece (when I first broached the idea of the Sidetree Protocol being leveraged for hypothetical subscriber authentication) - if we were to use your transaction ID / hash as our means of authentication (versus a regular e-mail / password combo for signing in), then the authenticating user (you) would need to leverage your blockchain wallet in order to 'sign' something (as a "proof" that you are the legitimate owner of said wallet).

Reasons Why This Works Perfectly

Blockchain wallets are the product of raw cryptography (in specific, PKI - 'public key infrastructure').

Bitcoin, for instance, formulates wallets by performing an secp256k1 (elliptic curve) operation on data that is (hopefully) generated randomlly in order to produce a private and public key pair that corresponds to two points on a non-hypothetical elliptic curve (as shown below):

Based on the orientation of the two points, which are extracted from this operation - the cyrptographic scheme is imbued with the useful quality of serving as a means of authentication that can be verified publicly (via the public key) via analysis of data that was signed by a private (hidden) key.

Bitcoin and Ethereum Addresses are Imbued With Significantly More Complexity Than This

I won't go into said complexities (because that's a different convo for a different day at this point), but it is worht noting that there are additional transformations that are performed on the public key (as well as base-encodings / compresssions / checksum hexadecimals / data appendates and trimming operations).

Below is a diagram that should provide readers with a solid "gist" of the many additional nuances that go into the formulation of a given blockchain address:

Don't worry, you don't need to know about any of this!

Getting to the Main Point

Basically, when you look at blockchain as a whole (from its design to implementation), it becomes readily apparent that blockchain is more or less suited to provide a bulletproof means of authentication.

And we can see how this has already been put into practice widely on the Ethereum protocol by virtue of 'W3' integrations and compatible wallet manifestations like "Metammask".

Several Drawbacks of These Solutions

• THey require access to API data or an Ethereum full node (the former will usually be the case; shoutout to Infura.io once again)

• While Metamask's developers have proven to be trustworthy, the extension itself is not impervious to compromise (no browser extension is) ; obviously, if one's browser were infected / compromised by a virus / malware / some other malicious browser extension, then the operations performed by Metamask could be extracted with trivial ease by the attackers in question.

• There's always a risk that users download / install the wrong (unofficial / malware) version of Metamask. Given its popularity among crypto users in addition to the (rightfully earned) default trust that it has received, many users simply click 'Download' / 'install' or whatever you need to press in the Google Chrome browser store in order to add this extension add-on. Knowing this, hackers and other bad actors usually attempt to 'sucker' unwitting users into downloading their malicious clones with the hopes that said user will entrust that app with their personal wallet details (jackpot if a mnemonic recovery phrase is entered into the extension to access a prior-created wallet with fund already on it).

How This Solution Elevates Above That

1. This is a stateless solution (apart from the actual creation of the TX hash itself).

2. This does not need to be publicly propagated on a blockchain (since we're not dealing with the exchange of money in any way - this is just an authenticated workflow).

3. Given the stateless nature of blockchains (as it pertains to wallet + TX creation), there's no reason why anyone must know that you're a subscriber on my platform (if I'm practicing proper opsec and you're not running around screaming that you're a user of the Librehash subscriber platform).

If we really have all our ducks in a row, then (hypothetically), users could leverage the Sidetree protocol to gain access to services / goods / etc., without even so much as ever having a conversation with the vendor (ever) ; this would be akin to the process of depositing funds at an exchange, except exchanges still mandate that you attach a significant amount of personally identifying informaiton (th legal / compliant ones do, at least) - so whatever benefits there are to be gleaned from the deposit address scheme that they have deployed is null and void.

True Conclusion

This was a lenghty write-up!

But I wanted to do so because I genuinely believe that there is tons of potential in innovations / architecture designs like the Sidetree protocol.

ALso, the GUI (Graphical Interface) that it comes with makes leveraging its properties a matter of trivial ease for the end user.