Gemini Identity

Bubble moved to bbs.geminispace.org; I learned about identity certificates!

Initially I just created a new certificate for `bbs.geminispace.org`, then realized that this was the wrong thing to do: it meant I was effectively creating a new “account” and could not make use of my post history or keep using the “Morgan” display name.

Of course I then discovered that Lagrange makes it easy to reuse certificates across sites.

Not really understanding how to use certificates effectively I’ve been creating them all over the place, and with random expiry years.

Reset

I deleted the identities I don’t really need, created one identity with expiry year 4999—I’m an optimist—and used Bubble’s “password” feature to link my “account” there to the new certificate.

I exported the new certificate to a safe place so I could import it across all my devices.

Okay! I think I’m now holding this right.

Musings

Client certificates are a really nice foundation for user identity across capsules.

It’s simple, secure, and makes “account creation” a breeze.

I wonder if we can make them do just a little more.

Gemini-wide Identity

Client certificates mean I have full freedom in how I represent myself to servers.

I can maintain one identity across Gemini, or one per capsule, or even multiple per capsule; or any variation in between.

Well, it’s pretty clear what I personally want: one identity across all Gemini, unless some special case comes along where I want to add privacy by using more identities.

And here is where there is a bit of a gap. I’m going to identify myself securely and identically to most Gemini servers; but every server is going to say “Looks like you’re new, welcome! What should I call you?"

So despite this powerful—optional—mechanism for fully unified identity, the experience is fragmented.

Each server knows who I am, but it doesn’t connect that information to anything external or pass it on in any way, even if I want it to.

My display name on Bubble is “Morgan”, and here; but I have no claim on the name, and nothing links it back to me.

So I see two things that could be improved:

First, I’d like servers to “just know” that my default display name is Morgan.

Second, I’d like that others seeing the display name “Morgan” on any capsule can determine whether it’s me-Morgan or some other Morgan.

Opportunity

I don’t think this is particularly important or urgent, nor do I think it’s a hole in the Gemini spec.

Rather, I think we’re exploring new territory here, and there may be a possibility for doing something nice.

“Nice” in the domain of online identity is extremely hard, so I won’t be surprised if my musings end up leading to nothing useful. But it seems worth exploring.

Thinking In Code

If at all possible I like to do my thinking with the aid of executable code, so I set about adding client certificate support to my Dart Gemini server.

Here I hit a problem: Dart has apparently never been used with self-signed client certificates! The network code just bails out.

Fortunately I was able to pinpoint the exact point in the networking library where self-signed certificates could be allowed instead of rejected; I filed an issue to the SDK github tracker and am using a patched version of the SDK for now.

What I Made

I set up a new subdomain `id.gemlog.org` to play with.

On this domain, the URL `/s/<base64 sha of identity>` is the canonical URL for an identity.

So any server can provide a link to `id.gemlog.org` for its users; Bubble could say, “to find out more about Morgan, go here”:

gemini://id.gemlog.org/s/jC3tFNqbobEOtWf+SQ1Fa4/hQ44=

If you supply no credentials, the page is obviously read-only.

If you supply matching credentials you can add metadata, and this is of course where the server could be useful.

Currently, you can add your preferred display name, and a “capsule URL”.

Both are visible to unauthenticated users. The “capsule URL” doesn’t do anything; I can imagine adding a way to verify that the identity actually controls the specified capsule.

Display names become usable as links, so this is now a valid link:

gemini://id.gemlog.org/Morgan

which gives you a way to find out, from my display name, what client certificate I use.

Utility

This is not at all a production-ready service, just me playing with ideas.

For display names some functionality will be needed to either enforce uniqueness or differentiate somehow between duplicates.

Other servers can look up display names from client certificate sha1s if they like, fulfilling my desire that servers “just know” that my display name is Morgan. Before that, though, the name should be presented in some conveniently-machine-readable or at least stable format.

Capsule links will become a lot more useful if they are verified—presumably by asking capsule owners to add backlinks from the capsules to `id.gemlog.org`.

Once an identity has a verified capsule, I can imagine making the capsule—optionally—“in charge” of the identity. This could mean for example that it can mark multiple client certificates as belonging to the same person.

Yet another idea would be to use this same site as an out of band way to verify server certificate fingerprints.

Privacy and Other Concerns

At a first glance all of this looks non-scary. Client certificates have provided us with something very powerful: I can create useful server about identities without it having to ask users to hand over the keys to those identities. You could spin up another server with the exact same capabilities as `id.gemlog.org`; people and servers could always choose to use it, or not.

From a security point of view, it’s worth noting that servers are free to lie about the sha1s of their users; this is not end to end security. But if a server wants to serve misleading content, it can do plenty of damage in other ways—trusting it not to lie about its user identities seems okay.

I do see some security concerns if it ends up used as a way to verify server fingerprints, or if anything else important or critical ends up relying on it. If it’s just an optional way to provide optional identity metadata, that should—as far as I can see—be fine.

If anyone wants to point out any concerns with any of this, please do! I would be very happy to learn of problems in advance. There is plenty of time for “in advance”, since I’m just experimenting and have no particular plan to launch this as a supported service. I’m interested to see if anyone is interested.

Visual Hashes

There have been various efforts to make “visual hashes” so that cryptographic identities can be recognized and checked by a human; for Gemini it seems like we would probably want ASCII art. OpenSSL has something called randomart, but I think there are more fun possibilities here.

It occurs to me that words can be used to add a lot of entropy to the visual hash in a way that people can relate to and remember. I remember xkcd had a similar observation about passwords. So, I experimented with this for a while.

Here the current output for my identity:

This is fun enough that I’ll probably iterate on it for a while, even if it doesn’t turn out to be useful for anything. I like the idea of an ASCII art visual hash that’s both visually appealing and useful. The current iteration doesn’t actually have any ASCII art decoration, I think it should, maybe something like this:

Fewer words and/or smaller word lists would be needed if extra entropy was added via symbols, so of course the words for my identity would change. The word lists anyway need some work, I did some manual filtering to “memorable and not overly offensive” but it’s quite labour-intensive work.

Wrapping Up

If nothing else, I now know how to make use of client certificates and user input on my server. I’m sure there will be more experiments in future, and I’ll be sure to write about them.

Feedback 📮

👍 Thanks!

👎 Not for me.

🤷 No opinion.

Comments.

So far today, 2024-05-12, feedback has been received 2 times. Of these, 0 were likely from bots, and 2 might have been from real people. Thank you, maybe-real people!