Reject standalone keys with mismatched IDs

[ojspp41]

Background

fetchKey() accepts either an actor document containing keys or a standalone CryptographicKey/Multikey document.

The actor branch already checks candidate key IDs against the requested keyId. The standalone branch previously accepted any object of the requested key class without checking its id. As a result, a document fetched from one URL could declare a different ID and still be returned and cached under the requested URL.

Although this does not let the key impersonate another actor—the owner/controller checks remain responsible for binding a key to an actor—it leaves the fetched key identity inconsistent with its lookup and cache key.

Changes

• Accept a standalone key when it has no id, preserving the existing compatibility behavior.
• Accept a standalone key with an id only when its URL exactly matches the requested keyId.
• Reject and negatively cache standalone key documents whose present id differs from the requested URL.
• Keep actor key resolution unchanged, including the existing fragmentless single-key tolerance.
• Add a changelog fragment for @fedify/fedify.

Regression coverage

The regression test supplies standalone key documents whose IDs differ from their requested URLs and verifies that:

• both CryptographicKey and Multikey documents are rejected;
• the first lookup returns { key: null, cached: false };
• the unavailable result is cached under the requested URL; and
• a repeated lookup returns the negative cache entry with cached: true.

I also confirmed that the new regression test fails against the previous standalone-key behavior and passes with this change.

Existing cache entries

This change validates newly fetched standalone key documents. It does not retroactively validate or evict mismatched key objects that may already exist in a persistent KeyCache from before the upgrade.

I kept existing cache-entry handling out of scope because #963 specifically concerns resolving a fetched standalone document, and cache storage and retention are provided by the application. I am happy to add validation or stale-entry handling for cached keys in this PR if the maintainers prefer that behavior.

Testing

The following checks passed locally:

• mise exec -- deno test --check --doc --allow-all --unstable-kv --trace-leaks packages/fedify/src/sig/key.test.ts
• mise run check-each fedify
• mise run test-each fedify (Deno, Node.js, and Bun)
• mise run check

Fixes #963.

AI usage

Implementation, regression-test drafting, code review, and local verification were assisted by Codex (GPT-5). I reviewed the resulting change and exercised it locally using the Deno, Node.js, and Bun workflows listed above.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 7066b08b-7a38-41e5-9157-79e6213275ed

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}