Trust policy for unsecured portable collections

[dahlia]

Background

FEP-ef61 requires actors, activities, and objects identified by portable ap: URIs to contain FEP-8b32 Object Integrity Proofs. Collections are different: portable collections, including inbox and outbox collections, may be served without integrity proofs.

The spec adds a separate trust rule for those unsecured collections. A consuming implementation must not process an unsecured collection attributed to a portable actor if it was retrieved from a server that is not listed in the actor's gateways array.

For example, if a portable actor declares:

{
  "id": "ap+ef61://did:key:z6MkAlice/actor",
  "gateways": [
    "https://server1.example",
    "https://server2.example"
  ]
}

then an unsigned collection retrieved from this gateway may be acceptable:

https://server1.example/.well-known/apgateway/did:key:z6MkAlice/actor/outbox

but an unsigned collection retrieved from this gateway must not be processed:

https://evil.example/.well-known/apgateway/did:key:z6MkAlice/actor/outbox

This policy is separate from the normal FEP-ef61 proof policy for portable actors, activities, and objects. It depends on gateway dereferencing because the verifier needs to know which gateway served the collection.

Proposed work

Add a trust policy for unsecured portable collections retrieved through FEP-ef61 gateways.

The policy should:

• detect portable collections identified by ap: or ap+ef61: URIs;
• allow signed portable collections to use the normal Object Integrity Proof verification path;
• handle unsigned portable collections separately;
• determine the portable actor that owns or controls the collection when this is unambiguous;
• fetch or use the actor document and read its gateways property;
• compare the gateway that served the collection with the actor's declared gateways;
• reject or mark as untrusted unsigned collections fetched from gateways not listed by the actor;
• reject or mark as untrusted unsigned collections when the owning actor cannot be determined safely;
• integrate with gateway dereferencing so the fetch source is available to the policy;
• avoid weakening the existing FEP-fe34 cross-origin policy for non-portable collections.

The initial implementation should focus on collection ownership cases that are clear enough to enforce safely, such as portable actor inbox and outbox collections. More complex inferred ownership cases can be handled later.

Scope

This issue is only about trust policy for unsigned portable collections consumed from gateways.

It does not include:

• FEP-ef61 proof policy for actors, activities, and non-collection objects;
• gateway serving endpoints;
• gateway dereferencing itself;
• inbox or outbox POST handling;
• gateway-to-gateway forwarding;
• full generic collection ownership inference;
• FEP-ae97 client-side signing.

The policy should be designed so it can be used by gateway dereferencing and future collection traversal code.

Design questions

The implementation should settle these details:

• Should untrusted unsigned collections be rejected by throwing, returned as null, or represented by a structured result?
• How should the policy determine the owner of inbox and outbox collections?
• Should collection pages inherit trust from the parent collection fetch, or re-check against their own fetch source?
• Should a signed collection still be required to match the actor's DID authority, or is proof verification enough?
• How should this interact with traverseCollection() and generated collection dereferencing accessors?

Tests

Add regression tests for unsecured portable collection trust behavior.

The tests should cover:

• accepting or trusting an unsigned portable outbox collection fetched from a gateway listed in the actor's gateways;
• rejecting or marking untrusted an unsigned portable outbox collection fetched from an unlisted gateway;
• rejecting or marking untrusted an unsigned portable collection whose owner cannot be determined;
• accepting a signed portable collection through the normal proof verification path;
• preserving existing behavior for non-portable HTTP(S) collections;
• ensuring the policy receives and uses the actual gateway fetch source, not just the collection ID;
• collection page behavior according to the design chosen for this issue.

This should be added as a sub-issue of #288.