💾 Archived View for rawtext.club › ~sloum › geminilist › 002044.gmi captured on 2020-10-31 at 02:41:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Alex Schroeder alex at gnu.org
Sat Jul 4 19:49:20 BST 2020
- - - - - - - - - - - - - - - - - - -
On Sat, 2020-07-04 at 15:17 +0000, colecmac at protonmail.com wrote:
I think it'd be great to eventually use client certificates for
authentication, but I definitely understand why you went with the
simpler token system for this initial implementation, it's a lot
easier to handle.
Oh, sure. I do think those are two different use cases, though:authentication and authorization. It's not just easier to implement(because I don't really understand the nitty gritty of TLS) but it alsoinvolves a design goal of mine regarding anonymous collaboration.
That's how I understand client certificates, in any case:
If we're using temporary client certificates, then nothing is gained.In a wiki context, we don't need to know about sessions. We don't needto know that this edit was made by the same person that made the otheredit a few minutes ago. (And in fact, Gemini Wiki computes a changing"code" for each contributor and stores that, hopefully allowing us todiscern visually whether two edits made a few minutes appart areprobably made by the same person without allowing us to know whethertwo edits made days appart were made by the same person.)
If we're using permanent client certificates, we've again gainedperpetual sessions which we don't need, or we're using the clientcertificats to hand out capabilities: who is an admin, who is aneditor, who is a visitor, who is banned. We're using them forautorization. I'd like to avoid thinking about that as part of Titan,though. It's already part of Gemini. If anybody needs this, like theywant to restrict people to uploads to their own area of a site, thenthat's fine. That's already covered by Gemini, as far as I'm concerned.
For my use case, tokens straddle that middle ground of anonymousediting, web of trust, friends of friends, and password protection. Wecan pass tokens on to friends and friends of friends, and if it breaksdown, we will issue a new set of tokens. These will again spread fromperson to person (or to anybody who knows where to look them up). Thatis, in any case, how I would like it to be. 😄
And if we really want, then of course we can tie tokens to users, makethem into bearer tokens like they are used in OAuth2: somewhere, youmake an account, you generate a token, and use it for your Geminiclient. On the original site, you can invalidate the token, or theperson running the server can invalidate the token, the token can beassociated with different capabilities, and so on. Tokens allow us togo there... but we don't have to.
Anyway, Gemini Wiki has the notion of "spaces" – separate wikis hostedwithin the same software. These spaces could be tied to clientcertificates, for example, allowing people to have personal wikis thatare effectively read-only for others. The software isn't there, yet,but it's something on my radar, for sure. I'm expecting that this willwork without having to change anything about Titan because clientcertificates are already part of Gemini – and if I go there, I mightdecide that those spaces either don't need tokens, or I might decidethat within those spaces, the people with the right client certificateare admins and get to generate and invalidate local tokens for theirfriends and family. Then we can have both: authentication for admins,and simple token-based authorization for collaborators.
CheersAlex