Reminds me of this

https://blog.cloudflare.com/red-october-cloudflares-open-sou...

Analogy = Nailed! Can we use that one?

So many great points raised here! Allow me to try and cover as much as possible. In a way, you can say TideCloak uses the Fabric as a key vault for (1) each user's authority (2) its own central authority. This way, even when TideCloak is completely breached, neither its users or own authority and authorization can be compromised. For simplicity, let's call those "authorities" keys. Whenever use of those keys is required, TideCloak makes a request to the Fabric, and as a swarm, the Fabric manifest that request in a multi-party fashion (a few steps up from standard SSS) and replies with the required artefact (access token, ephemeral decryption keys, signed consent, etc) in such a way that the secret keys are never assembled or exposed. Tidecloak itself, therefore, holds no user credentials or root certificate, so a breach of the IAM or an administrator is far less consequential. That API request is, for all intents and purposes, the coordination you mentioned. The Fabric is a "centralized dependency" as much as DNS is, or the internet. Yes, without the Fabric, those vaults are inaccessible – but the Fabric is robustly highly-available and resilient. Regarding the potential flak you mentioned, if you meant from describing the technology in high level terms, noted! If you meant because the approach we’re proposing introduces (and requires) a shift from today's paradigm, I think you’re devastatingly spot on. We’re expecting this concept to attract pushback, because it demands relinquishing centralized ownership of those authorities to some "ineffable" vault that no one can access. It's a big ask – but, it's also the only guarantee that if no one can access it, it can never be compromised. In my mind I’d liken it to the objection "on-demand hosted" architecture attracted in the early 2000s, which later became the ubiquitous "cloud". We can't avoid the resistance to change other than by continuing to push forward with the help of the significant academic scrutiny we’ve received to date, and the tailwind of a community interested in advancing it through participation.

Yep - there's already a working group in the Keycloak community aligning with various standards. In our case, the Cybersecurity Fabric is the component that handles ownership, secure portability and revocation.

You understand it perfectly. This is an example of an SPA that displays content based on authentication/roles – all client side. This was to demonstrate the simplest, most straightforward implementation in a few minutes. If you look closer, the authentication is secure by a signed-JWT which can easily be extended to server side content customization and direct api/db access. Developers in our beta program are already doing this across ReactJS / NextJS / Java / Dotnet / PHP/ Etc.

Thanks. The ideal end game is for the Cybersecurity Fabric to become a de-facto standard for best practice security inside the biggest platforms in the world (Entra, Okta, AWS, Google etc). So individuals can login with Tide (i.e. with their own authority). The protectionism only works until one plucky provider decides to use an open standard and starts winning business from the others... But let's assume that's years down the track, if we're right about that.

For now we're quite happy to provide an alternative for platform developers not bound to the big end of town.

The TideCloak (Keycloak) component does provide for options like federating or synchronizing with other IAMs in greyfield enterprise environments, to stage the integration.

Cheers! The idea is that anyone can tap into the Fabric, but also participate in it (coming soon)

The multi-party-computation and zkps used to generate the keys, authenticate to them, encrypt / decrypt and sign with them are PQ resilient. The key presentation layer (i.e. the key standard we've currently deployed) are elliptic curve based, so in theory would be susceptible. We're already working on other key presentations, including PQC algorithms, all handled in multi-party. We're already able to manage SSH keys in the Fabric.

They're working with a quantum safe research team from Wollongong Uni to create a quantum safe key. The whole scheme by itself is based on shamir SS that is quantum safe.

Absolutely true! And that’s only half of it. In schemes like this, how can you even tell the operators are following protocol? How do you know it's not a façade? At the edge of all those schemes, there's a point where you simply must rely on blind trust. Solving this challenge was one of our greatest motivations – and the only way to replace blind trust is through total verifiability. As far as we’re aware, our approach is the only one that allows verifiability on all facets: 1) access to source code, 2) having the ability to verify client-side code in run-time is another (in two different ways), and 3) last, but most important, anyone can opt to run parts of their keys on their own privately hosted nodes – so even if the entire network is colluding, you have the guarantee your own nodes aren't. Happy to elaborate.