Background
The initial map-local compound-proof profile in #1041 accepts exactly one direct inline proof per secured map. Proof arrays are rejected as an unsupported shape.
Fedify's ordinary activity signer creates one Object Integrity Proof for each Ed25519 key configured for the sender. A portable actor with several Ed25519 keys can therefore produce a proof array that a Fedify inbox rejects, even when every proof is otherwise valid.
Goal
Prevent outgoing compound portable documents from silently using a proof shape that Fedify's map-local inbox profile rejects.
The implementation should make the key-selection or rejection rule explicit. Supporting proof sets during verification is a separate interoperability-profile decision, not a producer-side workaround.
Acceptance criteria
- A producer with one Ed25519 signing key continues to emit one direct proof.
- A producer with several Ed25519 keys either selects one through a defined API or fails before delivery with an actionable error.
- Fedify does not silently emit a proof array for a compound portable map that its own inbox rejects as unsupported.
- Ordinary signing behavior for documents outside the map-local compound profile remains unchanged.
- The behavior is covered on Deno, Node.js, and Bun.
Non-goals
This issue does not add inbound proof-set verification, proof chains, proof aliases, remote proof references, or recursive controller-key discovery. Preserving a signed child's JSON value through typed parent serialization is tracked separately.
Related to #938 and #1041.
Background
The initial map-local compound-proof profile in #1041 accepts exactly one direct inline proof per secured map. Proof arrays are rejected as an unsupported shape.
Fedify's ordinary activity signer creates one Object Integrity Proof for each Ed25519 key configured for the sender. A portable actor with several Ed25519 keys can therefore produce a proof array that a Fedify inbox rejects, even when every proof is otherwise valid.
Goal
Prevent outgoing compound portable documents from silently using a proof shape that Fedify's map-local inbox profile rejects.
The implementation should make the key-selection or rejection rule explicit. Supporting proof sets during verification is a separate interoperability-profile decision, not a producer-side workaround.
Acceptance criteria
Non-goals
This issue does not add inbound proof-set verification, proof chains, proof aliases, remote proof references, or recursive controller-key discovery. Preserving a signed child's JSON value through typed parent serialization is tracked separately.
Related to #938 and #1041.