"OAuth3" and MFA

[maurerbot]

This is a difficult idea to communicate because it solves a interesting problem with some trade offs.

Problem

Kubelt Cores give developers a very powerful and flexible application platform that delegates authority to the end-user with a crypto wallet-like interface. Kubelt in a sense only provides the framework and non-functional aspects for managing cores so our applications are subject to the same delegation.

What this allows for is any front end to be built for any back end for an n^n possible pairings. For instance the Kubelt dApp front end (dashboard for configuring cores) is configured to permission Kubelt gateway to configure cores with your restricted core as the entry point. The same dApp front end can be reconfigured to swap use an "Acme Core" instead of Kubelt as the gateway.

This means the Kubelt dApp can be "white labeled" which is a desired property and part of the overall design of the platform. In that sense, Kubelt Cores provide a general interface to build any UX for any use-case -- a developer can decide they want to release their own front end for configuring cores specifically designed to their use case. However, this same feature could be abused if a bad actor decides to create a front end that requests permissions to Cores an end-user would otherwise not permit therefore, creating a MIM situation.

The Solution?

Traditionally a couple solutions are used to prevent this sort of attack:

1. CORS
2. OAuth

That said, considering these are well understood patterns, can we provide a similar solution either as a default or option that fits our model?

[Cosmin-Parvulescu]

Would signing typed data help us a bit in this situation? There could be a property dealing with the service provider and this would at least give the user a chance to grok what they are interacting with.

[maurerbot]

Related: https://www.vice.com/en/article/n7ny4x/opensea-sitting-on-ticking-bomb-as-lawsuits-pile-up-over-stolen-apes

[maurerbot]

Also related: https://eips.ethereum.org/EIPS/eip-2255

[maurerbot]

we should try to be compabitble with this. related to #295

[billkube]

I think one thing the kubelt platform is missing imo is a trust service - i think that would solve some of these problems because the mitm application wouldn't have the same trust profile.

Maybe cores could endorse each other similar to a https certificate / certificate authority. maybe anyone can endorse anyone, and kubelt is trusted by default?? could also be a way to discover cores - by inspecting the list of trusted cores. would also contribute to the network effect.

[maurerbot]

Cores right now issue the keys for "sub-cores" we can maybe take advantage of that but, the big problem is trust at the edge.

Any front end can talk to any core. CORS settings could be one step but that would need to cascade to sub-cores as well. A trust gateway where a bunch of information about the core requesting signing is one step that adds a little trust. The second bit is redirecting to the right front end to prevent a possible bad acting front end from trying to get you to auth into a core and grabbing your token client side.

[maurerbot]

Something I'm toying with in my mind right now is private cores offering MFA for all applications. In this model, your private cores register n+1 cores you trust and when those cores request signing our mobile app would prompt you to approve.

This pushes the 3 legged oauth out to the edge/client which is a better solution both philosophically and technically.