Getting started with decentralized identity

While I agree that blockchain technologies can quickly fall in bullshit buzzwords, there is still food for thoughts here, but you have to be somewhat familiar with the subject to understand it.

Let me try to explain it from software engineer to software engineer.

The core of web 5 is "self sovereign identity" . That means you (the user) gets to be in control of authentication, identification, and user data access and lifecycle.

Take a typical web 2.0 worflow:

- You sign up on a website / app by providing mail, password, and some other user data like address, phone, etc.

- The website / app stores your information + their own metadata (admin flag, purchase history, whatever) in their database somehow.

- When you log in, you are given a JWT which basically is just a subset of the data you provided + the website metadata, along with a signature to ensure you're not forging all that.

- The website / app have you perform API calls providing the JWT.

The whole idea of self sovereign identity is that you don't need the website / app to own any of your data and metadata in the first place.

If your data is stored in a place _you_ control, and where _you_ can delegate read access to them, as well as the capability for them to enhance it with their metadata that they can sign, then you can pretty much get rid of them storing anything at all about you.

This place where you store your data is a blockchain dedicated for that purpose. You can have all your information stored there, encrypted, and just encrypt for their public key what you are willing to share with them. If you don't want them to know you anymore, just remove the version of your data encrypted for them.

If they need to store additional metadata on you (say an "is_admin" flag), have them store it in your wallet and sign it.

You can pretty much see it as a blockchain of persistent JWT claims that you control. These claims would be accessed through a browser plug-in a-la-metamask.

The overall idea is that by switching to this model, websites / apps will become 99% front-end only, APIs will switch to smart contracts, and you will have total control of your data.

Hope that clarifies a bit the jargon of the article.

Besides, it would be fairly easy to implement at a cdn layer. Just give it a list of valid CAs, and have it set some header.

The real reason is that UI challenges for client certs are really hard. You can see it in the fact that people actual do use client certs in server to server communication (e.g. like between cache and backend)

But why would they want to?

If i understand, the premise of this idea is basically that we don't trust service providers with our data/to have our best interests at heart.

So we make a complex system where service providers (for the sake of argument, i dont know if i buy this) must respect our wishes.

Which raises the question, why would they?

Either a) service providers are good, and this system is pointless.

Or b) service providers are evil and they wouldn't use it and/or would subvert the intention.

> If you don't want them to know you anymore, just remove the version of your data encrypted for them.

Assuming they dont store it. Can't unring a bell.

> The overall idea is that by switching to this model, websites / apps will become 99% front-end only, APIs will switch to smart contracts, and you will have total control of your data.

Idk what y'all are smoking over there, but its clearly the good stuff.

> But why would they want to

Well the overall premise is that if they don't need to, it will become harder to justify to your users. The second premise is that legislation can be put in place to forbid the ad hoc storage of PIIs.

Europe already has in place legislation to allow users to have read and removal access to their PIIs stored by third parties, it does not seem inconceivable that a logical next step would be to actually enforce that users have real ownership of their PIIs by forbidding providers to store them at all.

> Either a) service providers are good, and this system is pointless.

Not really. The issue with personal data is not just good/bad. There is a spectrum in between.

You can be the best intentioned provider and still get hacked. When you think about it, it actually makes no sense to trust any service provider with your data considering 99% of them are not going to be able to properly store and secure them. Why not have a system that is secure by default.

And then there's the whole gray zone of what happens if the company sells your data, exploits it internally, gets bought by another company, changes EULA, shares with her parent company, etc.

> Idk what y'all are smoking over there, but its clearly the good stuff.

Try to be more open about it and don't get dragged on by the anti crypto trend blindly.

Sure there are a bunch of ridiculous things out there, but there's also actually good ideas.