I feel like making something this week.
I’m thinking, Spotify playlists but for conversations. Decentralised MeetUp.
I couldn’t sleep last night because I was thinking (again) about how to kill passwords but ultimately ended up doing a small amount of research that lead me to be believe that solving the problem with passwords isn’t a technical one, but more of a fundamental problem encompassing identity and trust.
I caught myself thinking that a decentralised identity built on the blockchain could solve this issue and so could a public/private key-based solution. But ultimately neither of those provide a solution to the problem of being able to reliably authenticate a known identity AND provide an easy way for the identity to be reestablished if the identity is lost or stolen.
In an article titled “5 Identity Problems Blockchain Doesn’t Solve”, Blake Hall - CEO of id.me points out that “digital identity and authentication are, for the most part, layers and steps that precede the blockchain application layer…"
To replace passwords with a public-private key pair would be naive to the fact that decentralised trust models do not solve the problem of how to recover identity once it has been lost or reliably and demonstrably be associated with an actual person or entity.
With a centralised approach, the trust model is “boot-strapped” via email which is assumed to be a secure channel to the user associated. The user has delegated trust to their email provider such that their email account can be trusted to receive password reset URLs, account confirmation emails, not to mention potentially sensitive information pertaining to the user’s account, their finances and other things.
In a decentralised world, their is currently no de-facto mechanism by which to “boot-strap” the trust model, by the nature of today’s centralised main stream culture.
If a hypothetical app, let’s call it Tritter, wants to authenticate a new user who uses some hypothetical decentralised method of identity, Tritter from the get-go has to trust the source of authentication. But if the source of truth for this identity is decentralised, there is nothing to stop someone else from having the same identity. There’s no way to prove for sure that the requesting user is not a bad actor that has gained access to the identity.
This is not true of a centralised identity, because the trust is not placed on the requesting user but on some system that is assumed to be trustworthy which nowadays will range from email providers to social networks.
The centralised identity itself will be authenticated through some other method which is assumed to be trustworthy, such as a password login or an email account.
Anyway, none of this is new - the identity problem has raged on for years. Interestingly there is a newly published working draft from the W3C on “Decentralized Identifiers (DIDs)" just yesterday: https://w3c.github.io/did-core/ which looks interesting.
DIDs appear to be a standard for decentralised identity concerned with the technicalities of such a system. It is unclear how wide-spread the adoption of DID actually is.
This sentence from the abstract strikes me as particularly interesting: ”…the design enables the controller of a DID to prove control over it without requiring permission from any other party."
The use-cases section are still a draft, but describe a tonne of really interesting use-cases for DIDs. In short, they describe a myriad of ways where a decentralised identity can improve existing trust models, improving UX in fairly concrete ways.
Among the DID docs, Verifiable Credential (VC) issuers are mentioned and are described as authorities that issue DID credentials based on verified subject attributes (e.g. national ID or age or basically any fact that can be verified).
One such VC issuer, Onfido (which coincidentally sits on another floor of the building I currently work for) is actually using what seems to be a proprietary Self-Sovereign Identity (SSI) created by Sovrin to allow users to port digitally verified identities across multiple companies. They did so in a trial with the FCA last year. In this instance, Onfido is known as a “trust anchor” that provides identity verification capabilities that are user-friendly, for example taking selfies or short videos and using them in the identity verification process.
It’s unclear whether Sovrin DIDs are based on the W3 spec for DIDs, although there isn’t any mention in their docs.
Anyway, back to our example: in the future, “Tritter” could trust any number of VC issuers to verify that a given decentralised identity belongs to the claimant - connecting the real person or organisation with the decentralised identity.
This is fairly similar to how TLS certificate authorities work, but instead of assuring a secure connection to a specific website, Onfido assures the trustworthiness of an independent claim on identity. Note that CAs are centralised and built on reputations of organisations, such as Symantec, GeoTrust and the famous open source CA, Let’s Encrypt: see this article from WordPress that has a comparison of these.
Onfido’s proposition seems to be to become one of the first CAs of decentralised identity.
Meanwhile, Evernym are trying to productise portable credentials and they have a webinar this week that looks pretty interesting. I might try to register…
Anyway, this was a bit of a random surface-glancing look into a small slice of the SSI world. I’m definitely keen to look into this a bit more, and maybe consider whether Urbit is solving this particular issue of verifiable decentralised identification.
This week I am going to write so many blogs and so much code. It’s going to be amazing.
I will also meet up with friends for the first time in four months! :)
I’m done with lockdown, thanks. Thanks for nothing covid.
I need to write a big old blog about how this lockdown is going so far.
But I literally only have energy for watching Netflix, specifically “The Last Dance” right now so I guess it can wait.
I’ve got a week off next week anyways so I can save it for then.
I cannot wait for some downtime.
Work related: I’m now organising an effort to improve the robustness of our OAuth implementation that we use to integrate the two auth domains of the web app.
One day I will blog all about it, but for now I will just say I am very excited to write a load of tests that will give us confidence that our OAuth integration is functioning as expected.
The next steps are documenting and test planning. 🚀
I’ve now re-written a new implementation for the terminal buffer in nomad but I’ve realised that despite the integration tests passing, the terminal still doesn’t survive being resized drastically.
I’ve realised that I should definitely write some integration tests that make sure that the terminal can be resized whilst maintaining a buffer in the viewport that is vaguely what the running program would expect it to be.
When a resize occurs:
- the cursor should be in the same position
- the part of the bottom part of the buffer shown in the viewport should be the same (as if the buffer were “pinned” to the bottom of the viewport)
- the part of the buffer that was in the viewport before but has now been pushed off the top of the viewport should still exist in memory and after an increase in viewport height should now be visible
I’m not sure whether all of this functionality should be included as part of the buffer or should be considered separate. I will continue to consider it separate until it is clear that it would be beneficial to make it a function of the buffer itself. This could be for the benefit of easy testing.
Anyway. Cool. Progress.
I’m finding myself blogging without actually looking at my rendered site and it’s really quite nice. I can’t quite put my finger on it, but maybe it’s the fact that I have faith in my auto-deployment system now.
Little update on terminal progress: I’ve finished writing a new implementation of the terminal text buffer as an array of strings (which of course it always should have been).
I now need to integrate it by replacing the current implementation which exists as a JavaScript Object and a much of methods on the main terminal class.
But at this moment in time I need to watch “Dark”.
I just started watching the third season of “Dark” on Netflix and oh my god it does not disappoint. SO. GOOD.
I just cannot use Ableton anymore, it takes me so much time to get ideas down and I really do not have the patience with it.
I just find the OP-Z so much more immediate in terms of taking an idea and very quickly being able to get something meaningful out of it.
Eventually I’ll share my OP songs on here, but that will take yet another blog format :)