Restrict client certificate scope by default?

[dimkr]

According to the Gemini specification (https://gemini.circumlunar.space/docs/specification.gmi):

E.g. if a request for gemini://example.com/foo returns status 60 and the user chooses to generate a new client certificate in response to this, that same certificate should be used for subsequent requests to gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, etc.

If I understand this correctly, although a client can generate a certificate after the user visits /a (and /a responds with status code 60), then use that certificate for /a/b, /b and even /:

1. If the user wants to use a different certificate for /b later (same host, same port), the previously generate certificate's scope must be limited to /a and /a/b first - is there an easy way to do that? It's not clear if "Use on this page" means "just this page" or "this page and children". I don't know if capsules with two "logged in" directory hierarches (with possibly different certificates) are common, but this scope restriction is meant to allow this use case of client certificates.
2. Contrary to what the spec says, some capsules assume the certificate generated for /a is later used for /, too. For example, gemini://station.martinrue.com has a link to the "join" page, which sends status code 60, but / shows the user profile if the client sends a client certificate (instead of showing the "join page" link). A client that does exactly what the spec says sends the certificate for /join, /join/a, etc', but not for /. Capsules like this one (there are multiple examples) were probably tested with Lagrange, and assume its default behavior is standard. Lagrange is popular, so other clients need to adjust, or find a creative way to solve (1) and avoid a limitation of one certificate per capsule. Maybe, in the name of strict compatibility with the spec and (maybe) better interoperability in the future (once capsules owners restructure the page hierarchy), the default for new certificates should be changed to "Current Page"?

Thank you @skyjake for your work!

[skyjake]

If the user wants to use a different certificate for /b later (same host, same port), the previously generate certificate's scope must be limited to /a and /a/b first - is there an easy way to do that?

The way it should be currently working in Lagrange is that whenever the user activates a certificate for a given page ("Use on this page"), any conflicting scopes are automatically deselected in the other identities.

It's not clear if "Use on this page" means "just this page" or "this page and children"

Like the specification says, it's always "this page and children", but that language is too long/technical for the UI. Identity management in general is a bit tricky from a usability point of view and could use more attention in the app...

I don't know if capsules with two "logged in" directory hierarches (with possibly different certificates) are common

There are a few, but certainly not common I think. For example: gemini://spellbinding.tilde.cafe has /game and /wordo.

gemini://station.martinrue.com has a link to the "join" page, which sends status code 60, but / shows the user profile if the client sends a client certificate (instead of showing the "join page" link). A client that does exactly what the spec says sends the certificate for /join, /join/a, etc', but not for /. Capsules like this one (there are multiple examples) were probably tested with Lagrange, and assume its default behavior is standard.

This feature in Lagrange where a new identity is activated for the current domain by default was introduced in version 1.5, on 2021-05-29, while Station was launched on 2021-05-01, a month earlier. Before v1.5, when Martin was developing Station, you had to activate new certificates separately afterwards, which was a bit of a usability hassle because the user needed to understand they had to go the appropriate root URL to perform the activation. I introduced the default activation feature to help with this usability problem.

In hindsight, a better default would be to activate for the current directory instead of the whole domain. I should add this as an option in New Identity.

in the name of strict compatibility with the spec

I think this issue has more to do with usability than spec compatibility. I suppose the appropriate behavior depends on how the New Identity dialog was triggered. If it was because of a status 60, then it would be good if there was no default selection, and the user was forced to choose the appropriate scope (page, directory, one of the parent directories, domain). Otherwise, when one just opens New Identity from the menu or some other way, the default would be "None" for the activation. I'll need to try this out and see how it feels.

[dimkr]

I think this issue has more to do with usability than spec compatibility.

I agree, the scope thing is not easy to explain in few words, to non-technical users. Some users will run into problems if they must select the scope, but don't understand what this means.

The default of "current domain" makes life easier for users, unless they want to use two certificates for different paths on one domain. I still haven't seen a capsule like that.