Sessionless support

[zach-planet-nine]

Overview

Sessionless is a protocol for establishing public key infrastructures (pki)s in arbitrary distributed systems. Below I will discuss possible implementations, and their pros and cons.

If you're unfamiliar with pkis, the tl;dr is that instead of some identity credentials (in the case of the passport plugin this is good ol' email/password) being exchanged for a token representing those credentials, the credentials themselves are used to cryptographically sign requests, which are then verified by the server. I am incredibly bias wrt the benefits of this scheme so I'll leave it to the group to discuss more :).

There are four approaches I can think of to using sessionless in the federated wiki, and to talk through them we need to make a distinction between authentication (authn), and authorization (authz). The former is how a user, in this case the wiki owner, establishes that they are who they are, and the latter is how they subsequently make calls to the server while maintaining that establishment.

Because signatures are made by whomever has the private key for the user, and that private key can be stored anywhere within the system, there are more options than with traditional sessions.

Options

Option the first: Sessionless sessions
The first option most closely mimics the current passport implementation. In it, the user provides some credentials (these can be email/password or any other credentials the user wants), and the server creates a key for them at that point, stores it in a secure same-origin cookie, and uses that key to sign subsequent requests.

Pros: Allows for interoperability with other sessionless services, which could be used by plugins and mechs.
Cons: Still passwordy, and not nearly cool enough.

Option the second: Offline sessionless sessions
The second option takes away the pii element, and utilizes an offline key to establish authn, which then creates a temporary key that's stored in a cookie for subsequent requests.

Pros: Interoperability, and much more is available for key storage
Cons: Would require an app on mobile to work

Option the third: The browser extension
My work includes a browser extension for key storage and signing since browser storage isn't sufficient. This would take modifying the wiki client as well as the server (I think. Could be that wiki.origin.put is tied to something on window that I can modify from the extension, but I doubt it), but let's users save keys for reuse.

Pros: Reusable keys open up options for user continuity, and meaningful interactions.
Cons: Requires a browser extension

Option the fourth: Offline editing
Afaict there's no way to edit your wiki offline and locally, and then push it to a remote server. This can be trivially done with sessionless.

Pros: Great for when you want to just jam out some wiki and/or don't want your changes to be out on the web right away.
Cons: May be deviating too much from how wiki is intended to be used.

How to get there

All four of these would take the same security file, so it's more a matter of if/when we would want to implement the different options. I think Option the second would just work™ without anything other than the security file, and I think there are already some options for non-passport credentials so option one may just work™ too.

I have no qualms with implementing all of or none of these. I would be curious if anyone would like to try and get their hands dirty with sessionless though. I've found it pretty fun to work with once you get the hang of it.

Conclusion

Sessionless can open doors to federation and interperability that traditional session-based auth cannot. As the horizon of what wiki can do continues to expand, I think it can be a powerful tool in its toolbox for enabling the kinds of connections that this group believes are possible.