Serverless authentication

[HerbCaudill]

The original proposal for authentication & authorization for Cevitxe took for granted that we would need to depend on external OAuth providers and a key management service for authentication.

So for example, if Alice creates a document and wants to collaborate with Bob, Bob would need to sign to an authentication server that Alice controls. That server would delegate use an Oauth provider (Google, GitHub, etc.) to confirm identity, and would then count on the signal server to guarantee Bob's identity to Alice as they work on the document together.

That approach would work, but having the need for any centralized servers at all would nullify some of the advantages of the whole decentralized/serverless/peer-to-peer model. For example, there are some compelling offline scenarios that wouldn't be possible, like collaborating over a disconnected local network.

Also, the long-term dream is to have direct peer-to-peer communication, and this approach would put us further away from that. We currently rely on a signal server, but we're hoping that's just a temporary solution until direct browser-to-browser communication protocols like WebRTC are more mature and reliable. It makes it harder to take the signal server out of the mix if we're relying on it to provide authentication.

There's also the matter of cost. The signal server is really lightweight, and the auth server would be as well. But realistically they probably can't be hosted for free. And even if they can be deployed with a single command in the console, figuring that out requires a certain technical comfort level; combine that with the need for a credit card and you've eliminated lots of people. A completely serverless solution would have no ongoing costs associated with it at all.

It seemed to me like a solution purely based on public-key cryptography should be possible: If Alice knows Bob's public signing key, then Bob can just sign all of his changes to guarantee to Alice that they're actually coming from him. In that case the problem comes down to a one-time establishment of trust: Alice needs a way of getting Bob's public keys such that she can be sure that they're actually Bob's - and preferably such that neither of them needs to know about or think about public or private keys.

After some digging I found an elegant solution to the problem of establishing initial trust in Keybase's documentation for their Teams product. At a high level, here's how it works:

• To invite Bob, Alice just generates a single-use secret key that she sends Bob via a pre-existing trusted channel. Bob can either type that secret into his client, or click on a link that includes it, e.g.:
  Alice has invited you to team XYZ. To accept, click: http://xyz.org/accept/aj7xd2jr9c8fzrbs

• That key allows Bob's client to derive a signing keypair, with which he can sign his acceptance of the invitation.

• Alice can make the public half of that keypair available to anyone else who has admin privileges on her document, without divulging the secret key to them; so they can verify Bob's identity but can't impersonate Bob themselves.

The surrounding framework for authentication and authorization that Keybase uses for Teams is worth stealing as well: It relies on a signature chain: an append-only log of events (new members, role assignments, revocations, etc.), each one of which contains a hash of its predecessor and is cryptographically signed by the author. This chain is shared publicly within the team, and it replaces the Access control document that I had proposed earlier. (Or rather, something like the access control document would be reconstructed from the signature chain.)

This is something that would be useful independently of Cevitxe or any other framework for communication/synchronization/storage, so I've started work on a new library called Taco.

[reidmporter]

It relies on a signature chain: an append-only log of events (new members, role assignments, revocations, etc.), each one of which contains a hash of its predecessor and is cryptographically signed by the author.

All I heard was "Cevitxe runs on blockchain now." ;-)

I've started work on a new library called Taco.

I feel like you should eat more snacks when you work.

[HerbCaudill]

All I heard was "Cevitxe runs on blockchain now." ;-)

Dude, I'm trying so hard not to use that word