Support cryptographic origins for `ap:`/`ap+ef61:` URIs

[dahlia]

Background

FEP-ef61 says that authentication and authorization for portable objects are based on FEP-fe34, but with cryptographic origins instead of ordinary web origins.

For HTTP(S) object identifiers, Fedify can use the usual URL origin tuple. For portable object identifiers, that does not work. The origin of an ap: URI is the DID authority of its canonical form, and the origin of a DID URL is its DID component.

For example, these identifiers should have the same cryptographic origin:

ap+ef61://did:key:z6Mkabc/actor
ap+ef61://did%3Akey%3Az6Mkabc/objects/1
did:key:z6Mkabc#z6Mkabc

Their origin is:

did:key:z6Mkabc

Fedify already has FEP-fe34-style cross-origin protections in the vocabulary lookup and object parsing layers, but those checks currently rely on JavaScript URL.origin. Portable object support needs a shared origin helper that can handle both web origins and cryptographic origins.

This issue depends on the portable URI parsing and canonicalization work under #288.

Proposed work

Add origin computation helpers that understand both ordinary web origins and FEP-ef61 cryptographic origins.

The helpers should:

• compute the origin of HTTP(S) URLs using the existing web origin semantics;
• compute the origin of ap: and ap+ef61: URIs from the decoded DID authority of their canonical portable URI form;
• compute the origin of DID URLs from their DID component;
• normalize ap: input to ap+ef61: only where portable URI canonicalization requires it, while keeping the origin itself as the DID;
• reject unsupported or malformed identifiers instead of silently treating them as same-origin;
• expose an equality helper for comparing origins across supported identifier forms.

The intended API can be decided during implementation, but it should be usable from places that currently compare URL.origin directly. Roughly:

getFe34Origin(input: string | URL): string;
hasSameFe34Origin(left: string | URL, right: string | URL): boolean;

Update Fedify call sites that enforce FEP-fe34 origin checks so they use the shared helper instead of direct URL.origin comparison where portable identifiers may appear. Likely areas include:

• lookupObject() cross-origin checks in @fedify/vocab;
• generated vocabulary object parsing where embedded objects are accepted or rejected based on same-origin trust;
• proof and key ownership policy code that needs to compare an object identifier with its owner or verification method.

Scope

This issue is only about origin computation and origin comparison for portable identifiers.

It does not include:

• gateway dereferencing;
• compatible HTTP identifier conversion;
• DID document resolution beyond extracting the DID from a DID URL;
• verifying Object Integrity Proof signatures;
• enforcing the full FEP-ef61 portable object proof policy;
• inbox or outbox forwarding.

Those should be handled in follow-up issues under #288.

Tests

Add regression tests for the shared origin helper and the updated FEP-fe34 call sites.

The tests should cover:

• ordinary HTTP(S) origins still comparing as before;
• decoded and encoded ap: URI authorities;
• decoded and encoded ap+ef61: URI authorities;
• DID URL origins, including did:key:...#...;
• equality between an ap+ef61: identifier and a matching did:key verification method origin;
• non-equivalence when DID authorities differ;
• non-equivalence when HTTP origins differ;
• rejection of malformed portable identifiers;
• existing cross-origin lookup behavior for HTTP(S) objects remaining unchanged.