Start portable chains from objects with compatible identifiers

[dahlia]

Background

Property accessors dereference references in portable mode when the caller passes verifyPortableObject, or when the parent object is in a portable chain (#1084, #1090). In portable mode, a reference is fetched through gateways and verified by its DID's proof, and fails without a verifier. isInPortableChain() in packages/vocab-runtime/src/internal/portable-dereference.ts is true for objects obtained from portable objects and for objects whose ID is an ap: URI, but not for objects whose ID is a compatible identifier.

tootik identifies all its portable objects by compatible identifiers. Since #1093, an inbox authenticates such an activity by its DID's proof, but the objects it refers to are not. Take a Create from tootik whose object is the URL of a Note:

const note = await create.getObject(ctx);

Context carries no verifyPortableObject, so this fetches the Note as an ordinary HTTPS URL and trusts it because of its origin. The same Create with an ap: ID would start a portable chain, and the Note would have to carry a proof by its DID.

#1090 decided to keep the HTTP(S) behavior for compatible identifiers when verifyPortableObject is not given. That decision was about references to compatible identifiers from ordinary objects; whether an object with a compatible ID should start a portable chain was not discussed.

Proposed work

Decide whether objects whose ID is a compatible identifier start portable chains, and if so, make isInPortableChain() true for them, so that their accessors dereference references as portable objects.

Design questions

• Without a verifier, portable mode rejects every reference. Starting the chain alone would therefore make getObject(ctx) on tootik's objects fail even when they are properly signed, although it works in Fedify 2.3, which would be a breaking change. Should Context instead carry verifyPortableObjectProof() as a default verifier for accessors, so that only unsigned or forged objects are rejected? That would be hardening rather than a breaking change, like the key ownership fix for GHSA-q9f8-5hc7-898f, though it changes which requests are made and applies the Trust policy for unsecured portable collections #836 policy to unsigned collections.
• Alternatively, the chain could start only when a verifier is available. That changes nothing for existing calls, but leaves the getObject(ctx) idiom unprotected.
• Should a malformed compatible ID start a chain, so that its references are rejected rather than fetched?
• An object parsed from arbitrary JSON is not verified just because its ID is a compatible identifier. Chain membership must not be taken as verification; how should that stay clear in the API?

Scope

This issue covers property accessors of objects whose own ID is a compatible identifier. It does not include the inbox, which #1093 covers, or references to compatible identifiers from ordinary objects, which #1090 covers.

Tests

• an accessor of an object with a compatible ID dereferencing a reference through its gateway and verifying it;
• the same accessor rejecting an unsigned object at the reference;
• whatever behavior is chosen without a verifier;
• unchanged behavior for objects with ordinary HTTP(S) IDs.