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.}

[dahlia]

Before I continue reviewing the implementation, I need a few points clarified and corrected.

The PR description identifies the model as “Codex (GPT-5),” and the commit uses Assisted-by: Codex:gpt-5. GPT-5 is a real model identifier, but it was released nearly a year ago, and the current model family is GPT-5.6. Please check the exact model identifier shown in the Codex session or configuration. If gpt-5 is accurate, please confirm that. If it is not, update the PR description and amend the commit so that both identify the model that was actually used. Please do not replace it with the latest model merely because it is current.

The commit also records both its author and committer as junseok <junseok@junseoks-MacBook-Air.local>, which GitHub cannot associate with your account. Please configure your preferred name and a GitHub-verified email address, or your GitHub-provided noreply address, then amend the commit and force-push it.

Fedify's AI_POLICY.md requires an AI-assisted pull request to be fully verified through human use. The PR description says that you reviewed the change and ran the Deno, Node.js, and Bun checks locally. Before proceeding, I need to confirm both your understanding of the patch and what you personally verified.

Please answer these questions in your own words, without using Codex or any other AI tool (영어가 불편하시면 한국어로 답변하셔도 됩니다).

• Why does accepting a standalone key with a mismatched id not allow that key to impersonate another actor?
• Why does the patch continue accepting a standalone key without an id?
• Why is the actor branch’s fragmentless single-key tolerance unaffected by this change?
• Why should a rejected mismatched key be negatively cached under the requested URL?
• How did you verify that the regression test fails without the patch?
• Did you personally run and review the results of each listed Deno, Node.js, and Bun check, or were those checks run autonomously by Codex?

Once these points have been addressed, I can continue reviewing the implementation.