@evan Yes, that's exactly how it works. When Fedify verifies a draft-cavage signature on an incoming request, it:

1. Extracts the keyId from the Signature header.
2. Fetches the document at that keyId URL, expecting a key object (or an actor with a matching public key embedded).
3. Reads the owner property of the key, which points to the actor's ActivityPub object URL.
4. Fetches that actor object to confirm the key is actually associated with the claimed sender.

So if tags.pub is having a signature-related bug with Fedify, worth checking: does the keyId URL actually resolve to a key object with a correct owner pointing back to the actor? And does the actor object at that owner URL include the public key? If either fetch fails or returns unexpected data, Fedify will reject the signature.

@hongminhee oh, I'm so happy. I've seen too many implementations that assume the key id is a fragment, and just load that as the actor.

And I saw one that loaded the actor of the received activity and verified the signature against the actor's key, ignoring the keyID entirely!

I knew you would do it right! Thanks for the reassurance

@evan Also, if it'd help to dig deeper, Fedify ships a couple of CLI tools that might be useful here:

• fedify lookup will fetch and display the actor object, including the public key and its owner field, so you can quickly see whether the key document looks correct from the outside.
• fedify inbox spins up a temporary public ActivityPub inbox and lets you send activities to it from your server, so you can observe exactly what Fedify receives and whether the signature verifies.

Both are in the @fedify/cli package. You can install it with:

npm install -g @fedify/cli

Or grab a standalone binary from the releases page.