@kaniini, thank you for explaining in detail! The JWK RFC refers to a parameter registry, and looks like such a registry exists indeed and we could define and publish a @context that assigns URIs to all those parameters. Hm anyone thinks we should talk to whoever is speccing JWK/JSON-LD about this? Or just host that context document here somewhere?
criztovyl, hmmm idk about that. I mean, yes, the OpenSSH key format is what most servers already use and take as user input. What I’m unsure about is the statement that just because SSH keys are used in the SSH protocol and not in AP, they’re opaque data. My thoughts about this:
- ForgeFed is about forge federation. ActivityPub is a tool being used for that. But forges typically involve other things: Interaction via email, VCS push and pull via HTTP(S). via SSH and via custom protocols such as the git:// protocol… so forge federation isn’t defined by what flows through AP inboxes and outboxes: Everything that participates in federating forge functionality is relevant. And SSH keys do. Even if the integration behavior between AP and VCSs won’t be a part of the core specs, and will be in a separate extra spec etc., the SSH keys are still part of the vocabulary.
- I’m not aware of anything else on the Fediverse that uses or plans to use SSH keys, but that could change. Imagine SSH keys started being used for shell access, or by SSH servers that doesn’t use the OpenSSH format. So we may have more people and servers wanting to represent them in AP. Perhaps it’s best to choose now a good longish-term general representation. That may still be the OpenSSH format; I’m just suggesting that those SSH keys matter as a core part of forges, even if they’re used outside of AP message passing.
Summary so far: Nobody is arguing for the PEM format or for the standard SSH2 key format (which looks very much like PEM). The options suggested are:
Personally, I’m leaning towards JWKs, because they’re general-purpose and readable as-is in the AP JSON document, and not tied to OpenSSH. githu8 may be using OpenSSH (idk if they do), GitLab/Gitea/etc. may be using OpenSSH (IIRC they both do), but this could change (OpenSSH is an SSH implementation, not the only implementation), and the OpenSSH format may become much less useful. Also, in a federated situation we have have many ForgeFed server implementations, using different SSH implementations. For example, Vervis (which I’m developing) currently uses an SSH implementation written in Haskell. I could probably just pass the keys as structured data extracted from JWKs and skip the whole parse-OpenSSH-key-format step.
Side note: The format OpenSSH is using is the same as the actual serialization in the SSH protocol, so it’s defined in the SSH specs, but the SSH specs don’t require any storage format AFAIK, so the choice is arbitrary.
Does anyone have more arguments for using the OpenSSH format? criztovyl, thoughts?
Another question, which property name to use? Some ideas:
sshKey (con: doesn’t state that it’s public, pro: private keys aren’t published anyway, although yes they could be shared internally by server components for whatever reason)
publicSshKey (con: longer and stating the obvious, pro: explicitly says the key is public)