Hello!
This is a discussion thread for the proposed FEP-ae97: Client-side activity signing.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.
Summary
Existing Fediverse servers manage signing keys on behalf of their users. This proposal describes a new kind of ActivityPub client that lets users sign activities with their own keys, and a server that can distribute client-signed activities to other servers.
Iâm not sure I understand the purpose of this. It seems like it just adds a DID as an authentication mechanism for AP clients. But it doesnât seem to do anything with that identity. I would have expected it to serve as the base to make identity portable across AP servers, but it doesnât as far as I can tell. So if itâs just an authentication mechanism, that doesnât seem valuable enough to me to alter the core semantics of how the outbox works. Iâm particularly concerned because the ID is a URI, and allowing the client to specify any arbitrary URI seems unwise.
I donât think that this a FEP that is ready for implementation yet, or ever will be. However, as I always say these are Fediverse Enhancement Proposals, so it is not necessary that something submitted as a FEP is ready for implementations.
Letâs move on to the topic of the FEP.
In my world, clients correspond to devices, i.e physical things owned by the end user. My understanding is that one wants to associate a different cryptographic identity to each of these devices [1]. So what I would like to see is something like an interface
{
"registerIdentity": "https://server.example/register_identity",
"verifyIdentity": "https://server.example/verify_identity",
"addIdentity": "https://server.example/add_identity"
}
where addIdentity needs to have a workflow that ensures the different identities acknowledge each other. This then requires some analysis that attackers cannot add new identities.
[1]: One device breaks. You send it off to be repaired. You want to invalidate the cryptographic identity of the device before sending it off, and generate a new one for it afterwards.
When client-side signing is used, recipients of activity can verify that it has not been changed by the server that delivered it. This might be useful if some sensitive data is being transferred. Recipients may also accept a signed activity if it was sent from a different server or directly from the client, though this is already possible with FEP-8b32 alone.
Yes, this FEP leads to portable identity, but this requires further research and Iâm not sure if it is possible without breaking compatibility with existing fedi software. For example, one could use DIDs for actor IDs.
I agree, the server should not allow arbitrary IDs. Rather, IDs should match the URL template the server is using. Iâll update the proposal.
I think one user account should correspond to one DID (DID = identity in the context of this FEP). In the simplest case the same signing key can be shared between all devices (this works even with did:key). If this is not acceptable, device keys should be added to DID document as additional verification methods, or some kind of capability based delegation might be used.
Iâm not sure multi-device or multi-client complexity needs to be folded into the content signing/verification level-- that workflow for adding new devices with unique keys and rotating those keys doesnât necessarily need to be foisted on all future consumers of the data and all other servers. The latter might be less willing to support multiple keys than something simpler, particularly if it breaks more of their status quo and creates more legacy problems for them. The least painful upgrade is something that allows non-upgrading custodial systems to peacefully coexist for a while with servers going live with client-side signing options.
Or, to put it another way, interop is better served by simpler DID Doc semantics, i.e. âthis key is the current signing key, every time you fetch content from this user you might want to check back that it hasnât been rotated by running the same query again, hereâs the kind of signatures the current key producesâ. A DID doc might include additional keys like the ârecoveryâ/backup/rotation/update keys that many systems use, hashlinks or other verifiable links to previous versions of the doc, etc, but counterparties that donât care and donât use those functions should be able to ignore them in the confidence that it doesnât affect their security. This is why a finite allowlist of DID methods (and thus a finite enumerated list of properties that can be safely ignored in them) may be preferable to some than âany DIDâ or âany URIâ 
This gets into a pretty dicey political game of line-drawing, tho. Perhaps the FEP doesnât need to create a shortlist, but a separate informational/meta FEP can curate known examples and each implementation can choose how careful or closed-world to be.
I would mention that AFAIK, bluesky and nostr both have multiple keys that are relevant to other client<>server functions but only one thatâs relevant for servers trying to verify content was actually produced clientside by that user before consuming or replicating it.
Nobody likes to use PGP due to being in this âsimplestâ case. Itâs the simplest case to implement and the hardest case to use.
Itâs the simplest from the implementation perspective because nothing special needs to be done 
I agree this is not a good UX, and I hope weâll find a better solution. Some form of delegation of authority from âmaster keyâ to device key or application key would be the best. In my opinion DIDs should represent personas, not devices.
This is the dominant pattern across the DID Methods Iâve worked on or audited (which is most of them). Enabling multidevice by delegating to (and revoking from) device-bound keys is the norm AFAICT-- see also Wallet Connect, WhatsApp, Discord, Telegram, iMessage, etc. Signal I believe goes the other way for various reasons, but it has its discontents and I suspect that MLS (aka âSignal v2â) might actually end up aligning more with the aforementioned, because they are going after smoother-UX use-cases and would thus need to support delegated/revocable multi-device as well. Itâs also worth mentioning that WebAuthN/PassKey, which is coming down the pike fast, opens up similar UX even in browsers (delegating account privileges to unique browser-bound keys on each device for smoother UX), so I suspect this pattern to get even more dominant in coming years.
I would also add that some dayjob colleagues (including long-time fedi-nerd @ Bengo) have been working on a OAuth-like authZ system thatâs less client/server and HTTP-bound called UCANs, if youâd like to avoid ârolling your ownâ multidevice delegation system and would like to use a common signing flow and receipt/logging structure for debugging and auditing. They even have a snazzy website outlining the pros and cons, whatâs prod-worthy and whatâs still moving, etc. Thereâs even some early work on using delegating UCANs (delegable capability objects) directly to device-bound WebAuthN device keys specific to a given service, if you want to get really cutting-edge!
I would prefer ZCAPs or Verifiable Credentials because they use the same âintegrity proofâ building block weâre using in FEP-8b32 and FEP-c390. That makes implementerâs life a bit easier.
Entirely fair for the âActivityPub is a JSON-LD standard anywaysâ crowd! There is some amount of interop/translation possible between the two, but if youâre already doing Linked-Data style signing of content, itâs probably much easier to just reuse that tooling for the delegation stuff . I think the main appeal of UCANs is interop with systems like WNFS that use them throughout, but that may be of interest to exactly zero of todayâs AP implementations 
@aumetra has been exploring the UCAN path:
It also means interop with Noosphere (uses UCAN), which is quite relevant to the fediverse as a âtool for thoughtâ.
Yep, I was exploring the direction of UCANs, mostly for their simple delegation properties.
Since youâre most likely gonna have a long-lived key representing your identity, you probably want to delegate as far away from that ârootâ secret as possible, to act as a preventative measure to somewhat counteract compromised identities
Is the following pattern of adding ?host=domain1,domain2 used in other applications (not necessarily Fediverse) already?
`did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2?hosts=server1.example,server2.example`
I havenât seen this particular pattern anywhere. Magnet links is the closest thing I can think of, where query parameters are used to specify trackers and peers: bep_0009.rst_post
magnet:?xt=urn:btmh:<tagged-info-hash>&dn=<name>&tr=<tracker-url>&x.pe=<peer-address>
tr is a tracker url, if there is one. If there are multiple trackers, multiple tr entries may be included. The same applies for x.pe entries.
Proposal has been updated: #166 - FEP-ae97: Update proposal - fep - Codeberg.org
I added some clarifications regarding object ID validation, added requirement to sign wrapped objects and an intentionally vague section on server-independent object IDs (this section may evolve into a separate FEP).
After rereading Decentralized Identifiers (DIDs) v1.0 I think the host fits quite well into the concept of did-parameters. One probably needs to work out a lot of details like ids that agree except the hosts parameters are the same, e.g. for updates.
However, I think it should be pretty clear how to build an application associated with a did, that publishes under that did, where signatures ensure validity of the documents.
Iâm thinking about connecting actors identified by DIDs with the rest of the network. This can be done by an activity translation service, but the challenge is in generating webfinger addresses for such actors.
One possible solution is percent encoding, but Mastodon currently doesnât allow % in usernames (see this issue Percent encoding and `~` are not handled for accounts · Issue #17222 · mastodon/mastodon · GitHub).
To work around this, we can use some combination of allowed special symbols (.-_). Libervia performs translation of XMPP identifiers using this technique: https://repos.goffi.org/libervia-backend/file/970b6209526a/libervia/backend/plugins/plugin_comp_ap_gateway/__init__.py#l698
For example, this actor ID:
did:example:123456/actor
can be translated into this fediverse address:
@___did.3aexample.3a123456.2factor@proxy.example
(proxy.example is a domain where activity translation service is hosted)
This section has indeed evolved into a separate proposal: FEP-ef61: Portable Objects (discussion). Iâm not removing this section yet, just adding a notice: #210 - FEP-ae97: Add deletion notice to "Server independent IDs" section - fep - Codeberg.org