... only location of a key matters. This is specified in FEP-fe34, and I just published a more detailed explanation of how it all works:
After rereading that FEP, I think I understand better why we have different perspectives on this topic. First, "web origin" is not the same as the AP "same origin policy" described in the non-normativeAP authz/authn primer. These two kinds of "origins" are not computed with the "same algorithm" as claimed by the FEP (or at least it appears to me that this is the claim, it's not completely clear). In this thread, it seems to me that you are using "origin" in the "web origin" sense. If not, please clarify what you mean.
The other issue is that the FEP doesn't appear to be consistent with the W3C SocialCG group report on HTTP Signatures. This document describes an algorithm for verifying an actor/key relationship that does not depend on (or require) either the same web origin for actors and keys or the AP same origin policy. The AP "same origin policy" appears to be described in an authorization policy context rather than for HTTP signature authentication.
The inconsistency I see is that the FEP requires "embedded" objects to have same web (?) origin as the containing object. Keys may or may not be embedded as part of the serialized actor graph. They may only be referenced by URI (even Mastodon supports it), but if they happen to be embedded in the actor graph serialization, I know of no good reason to apply the FEP origin-related constraints to the URIs.
What's important for verifying the actor/key relationship is the mutual references between the actor publicKey and the key's owner (or controller) property. The key itself could be served from a different web origin than the actor document. Furthermore, there's no guarantee that removing the key's URI fragment, if any, will lead to successfully verifying the actor/key relationship, even if the relationship is valid. For example:
key URI: https://keyserver.example/bob/keychain#B54F15A0actor URI: https://server.example/bob
As long as, the document retrieved from https://server.example/bob has a publicKey property referring to the key URI and the key object has an owner or controller property referring to the actor URI, it's a valid relationship.
In other words, removing or ignoring the key URI fragment will not generally work. In this example, dereferencing the key URI might result in a key chain object with several public keys having different fragment identifiers. Even more conventional AP actor documents might have multiple public keys with different fragment identifiers (mentioned in the SocialCG report). Ignoring key URI fragments will not work in this case either.