Write-up on an idea of "identity servers" used with ActivityPub-enabled social networks to have a central, easily verifiable identity with keys for every social link a person has.

Fediverse Identity Servers.md

Identity Servers

This document is based on a Mastodon thread where I've suggested a concept of "identity servers" that'd contain the neccessary data to use a single profile with many Fediverse services at the same time, eliminating the need to create multiple accounts with separate data if you wish to use, for example, Mastodon for microblogging and a self-hosted platform for an actual personal blog. Right now that'd require the person to register on both servers: say, @lina@mastodon.social and @lina@blog.lina.moe, and if a user wants to follow you for both your blog and your shitposts they have to do that for both accounts. Also this is probably one of the reasons ActivityPub/ActivityStreams has a definition for a Move activity that basically tells your current followers to replace this entry with another one, that has a different name and/or host.

Implementation Details

This, in its original form described here, would require a couple things:

• an optional identity field in the Person actor type, a link to the entry on the identity server:

  {
    "identity": "https://id.lina.moe/users/lina"
  }

• an optional signature field in the Person public key entry:

  {
    "publicKey": {
      "id": "...",
      "owner": "...",
      "publicKeyPem": "...",
      "signature": "base-64 encoded RSAwithSHA256 signature of the same key specified here in publicKeyPem, created during the verification process by the identity server"
    }
  }

• a format for the identity data specified in Person.identity, something like this that'd be returned on a GET request to the URL in the actor data:

  {
    "subject": "https://identity.server/something/username",
    "verify": "https://identity.server/username/verify?url={url}&signature={signature}",
    "displayName": "preferred-name-here",
    "aliases": [
      "https://mastodon.server/users/mastodon-name",
      "https://blog.personal.site/users/name"
    ],
    "publicKey": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
  }

• a process to verify a social link and add it to the identity server's personal entry:
  • the process must be initiated by the profile owner, not the website that wants to add a link to the profile (e.g. the user interaction will be on your.identity.server, not on mastodon.social)
  • the identity server would send a request to the linked account's inbox, having the key signature and the profile URL in the request, for example, as a new Activity type:

    {
      "type": "Identify",
      "actor": "https://identity.server/users/name",
      "object": "https://social.network/users/name",
      "signature": "signature to be put in Person.publicKey.signature here",
      "identity": "https://identity.server/users/name"
    }

  • clients would now be able to check the user's identity, verify it, and display posts from other aliases of this person as well.
• a process to revoke a social link/alias, also doable using just the identity server:
  the identity server would then send another update to the alias inbox, saying that the publicKey.signature and identity fields can be removed

To Do / Help Needed

Technically this would still not eliminate the need to register on multiple instances, only linking them together and serving as a hint clients should follow. A better version would involve submitting own keys to the instances (preferably created for each instance, as sharing a single one would impose a security risk in case an evil actor gets access to the instance's storage) and having supported server software updated to support full @username@host names internally. This approach would require identity servers to also provide an inbox/outbox for each user that'd relay activities to their linked instances, though, which is probably not desirable because of added complexity.

Also I'd like suggestions on the cryptography/verification part of this, as I'm not well-versed in that at all and it's possible that there's a simpler solution available to this.