Reading back the discussion, I don’t see any good solution for embedded proofs using JCS… this is a bit disheartening, as I was looking forward to using embedded signed objects for approval stamps.

Do you think embedded signed objects will cause problems in real-world situations?

@hongminhee implemented FEP-8b32 in Hollo, which is one of the ActivityPub servers that actually does JSON-LD processing, and didn't encounter any issues (as far as I know).

Do you think embedded signed objects will cause problems in real-world situations?

Well, unless it has to do Linked Data Signatures validation, Mastodon is currently optimistic about the shorthands matching its own context, but that is not correct behavior and this is already an issue with Bookwyrm which use the same quote shorthand for a different property than Mastodon, causing compatibility issues. This is something systematic JSON-LD processing would fix, but it would render embedded signatures useless, as the underlying JSON would be changed by JSON-LD processing (either compaction or expansion). In themselves, JCS embedded signed objects would not break anything, but they would be basically unverifiable and just be a waste in the payload.

@hongminhee implemented FEP-8b32 in Hollo, which is one of the ActivityPub servers that actually does JSON-LD processing, and didn’t encounter any issues (as far as I know).

My understanding is that Fedify currently only supports verifying top-level FEP-8b32 signatures, by verifying them before JSON-LD processing, and does not support embedded signed objects yet.

Hello!

This is a discussion thread for the proposed FEP-8b32: Object Integrity Proofs.Please use this thread to discuss the proposed FEP and any potential problemsor improvements that can be addressed.

Summary

This proposal describes how ActivityPub servers and clients could create self-authenticating activities and objects.

HTTP signatures are often used for authentication during server-to-server interactions. However, this ties authentication to activity delivery, and limits the flexibility of the protocol.

Integrity proofs are sets of attributes that represent digital signatures and parameters required to verify them. These proofs can be added to any activity or object, allowing recipients to verify the identity of the actor and integrity of the data. That decouples authentication from the transport, and enables various protocol improvements such as activity relaying, embedded objects and client-side signing.

JCS embedded signed objects would not break anything, but they would be basically unverifiable and just be a waste in the payload.

I think they can be verified deepest-first, which does require walking the entire JSON document and verifying proofs in reverse depth order.

The question is if outer proofs include the inner proofs, or if the proofs are simply "included" (@included) alongside the data. Generally it makes more sense to do the former, although nested proofs has the same complexities as nested contexts -- it's way easier to do this with a document boundary rather than compound documents, because then you don't have to deal with any cascades.

I think RDFC has the same issues because it's not immediately apparent if the signature input includes the entire graph or if it includes a subgraph. You have to understand if a property is semantically defined as @container: @graph or not. The RDFC proof is scoped to the immediate parent graph. (In Activity Streams 2.0's normative context, none of the properties are currently defined as graph containers, so proofs typically apply to the entire AS2 document.)

With JCS proofs, the scoping issue is in the reverse direction; it's about whether the proof applies only to the current JSON node or to subnodes as well. In other words, using compound documents is unexpected and discouraged.

For more on proof graphs, see https://www.w3.org/TR/vc-data-integrity/#proof-graphs

I think the intended solution might be the previousProof property: https://www.w3.org/TR/vc-data-integrity/#previous-proofs

also tangentially i noticed this part of the FEP:

The proof type SHOULD be DataIntegrityProof, as specified in section 3.1 DataIntegrityProof

@silverpill actually the type MUST be DataIntegrityProof per current spec (TR from May 2025). relatedly, the data-integrity/v2 @context definition scopes all properties to this type, so none of the proof properties mean anything unless this type is present

per https://w3id.org/security/data-integrity/v2

{ "@context": { "DataIntegrityProof": { "@id": "https://w3id.org/security#DataIntegrityProof", "@context": {...} } }}

this allows using more generic terms like "created", "expires", "challenge", "domain", and "nonce" in other parts of the document without conflicts.