Several solutions were proposed - embeddedObjects

This sounds a lot like JSON-LD @included:

{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://activity.example/", "actor": "https://actor.example/", "type": "Announce", "object": "https://object.example/", "@included": [ { "id": "https://actor.example/", "name": "Someone", "type": "Person" }, { "id": "https://object.example/", "type": "Article", "name": "Top 10 AS2 examples -- number 3 will surprise you!" } ]}

If you ignore all the JSON-LD stuff, the "plain JSON" document is just this:

{ "id": "https://activity.example/", "actor": "https://actor.example/", "type": "Announce", "object": "https://object.example/",}

If you flatten the first example or convert it to N-Quads, the @included block goes away. The @included block is just a framing tool so that the "plain JSON" can match a specific schema (say one where actor and object are required to be JSON strings). It's broadly similar to JSON:API's concept of "included", as JSON-LD 1.1 points out... except it keys off of @id only (instead of both type and id).

A canonicalization scheme could define that included blocks are stripped before hashing and signing, and that therefore the information included in an included block is not trustworthy on its own without its own signatures. I guess you could profile JCS if you wanted to depend on the JSON serialization, or profile RDFC if you wanted to depend on the N-Quads dataset (minus the included statements).

Claire:

how would you “make sure” the object is indeed a <https://www.w3.org/ns/activitystreams#object> while keeping the object’s JSON representation intact? Off the top of my head, I see no way to do that safely.

If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have lately come to the conclusion that JSON-LD and JSON cannot coexist in the same network.

The way you "make sure" that object is specifically is via one of the following mechanisms:

• JSON-LD @context expansion. A JSON-LD processor loads the declared contexts (modulo other document loader safety concerns) and normalizes everything to its full IRI reference.
• IANA media type signaled via HTTP Content-Type header is application/activity+json or equivalent. Per definition, that media type includes the semantics that the object key is defined as . For JSON-LD compatibility, this is also achieved via "context injection", i.e. when you encounter this specific IANA media type, you can convert it to an application/ld+json document by tacking on "https://www.w3.org/ns/activitystreams" as the end of the @context array in case it is missing.

The latter is the closed-world / centralized variant of the former. They clearly already co-exist in the same network. The issue arises when you use terms that aren't defined by application/activity+json or its equivalent JSON-LD @context, but this isn't JSON-LD's fault -- the issue's real cause is that people can and will disagree on what terms mean, as with any other matters of language. You can't assume everyone always agrees with everything you do or say 100%. The point of having keys and terms be expandable to IRI references is that http(s): IRIs conveniently include an authority component, so you can workaround the lack of authority in the data model and disambiguate two different definitions of the same term. Having a way to detect that there is a conflict does not create the conflict; the conflict is still there even if you don't have a way of detecting it.

tl;dr,

how one is expected to handle proofs of embedded objects

depends on canonicalization. Embedding an object from one document into another document should be done with the recognition that documents and objects are not the same thing, and that embedded information about an object is necessarily scoped to the current document in which that information is presented.

For example:

GET /foo HTTP/1.1Host: domain.exampleAccept: application/activity+json

HTTP/1.1 200 OKContent-Type: application/activity+json{ "id": "https://domain.example/foo", "type": "Activity", "object": { "id": "https://domain.example/bar", "type": "Object" }}

Here, the statement that /bar is an Object is a statement being made within /foo. You can GET /bar and obtain different information (e.g. that /bar is a Tombstone). That doesn't make the statement in /foo incorrect; it could be that statements in /foo and statements in /bar were made at different times.

When signing or verifying objects, it's crucial to consider what you're signing. As the author of /foo I can sign my own statement about /bar within /foo, and this is different than a signed statement about /bar from the author of /bar within /bar. If you don't distinguish or qualify statements by their source[^1], you will get confused.

[^1]: This is what quads are supposed to be in RDF -- they contextualize triples by the graph they came from. But you don't need to use quads, you just need to use some kind of contextualizing thing, like an HTTP resource; the statements in that resource can still be modeled as triples, while you reason about them as quads in order to explicitly consider who said something, or when they said it, or whether or how much you trust that statement.

I can't get too much into this further, since anything else depends heavily on what your trust model is. But for the purposes of signatures, you have to look to the current document (and possibly infer additional information from HTTP headers).

I am looking at implementing this into Mastodon, and I’m unable to verify the test vectors in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.feature although I’m able to verify these: https://www.w3.org/TR/vc-di-eddsa/#representation-eddsa-jcs-2022

This might be due to the presence of floating numbers in fep-8b32.feature document. Some JCS libraries don't handle those correctly. Which one do you use?

Additionally, I’m not sure how one is expected to handle proofs of embedded objects: indeed, if you consider the whole document as JSON-LD, the JSON-LD API does not give you much to unambiguously access a precise attribute other than expanding, compacting, or framing the document, but all these operations may change the JSON representation and thus break the signature.

A similar concern was raised by @helge in another thread: https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/10. Several solutions were proposed - embeddedObjects, re-defining object as @json, etc.

Later, I opened an issue in w3c/vc-di-eddsa bug tracker - https://github.com/w3c/vc-di-eddsa/issues/81. They said it is fine to embed a signed object and I didn't ask any more questions.

E.g., in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#signed-activity-with-embedded-signed-object, how would you “make sure” the object is indeed a <https://www.w3.org/ns/activitystreams#object> while keeping the object’s JSON representation intact? Off the top of my head, I see no way to do that safely.

If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have come to the conclusion that JSON-LD and JSON cannot coexist in the same network.

This might be due to the presence of floating numbers in fep-8b32.feature document. Some JCS libraries don’t handle those correctly. Which one do you use?

That was it, thanks! We use the \json-canonicalization\ gem that we already had an indirect dependency on.

The next non-patch version of Mastodon should support incoming top-level Object Integrity Proofs using \eddsa-jcs-2022\. We are also looking at supporting \mldsa44-jcs-2024\ defined in https://www.w3.org/TR/2026/WD-vc-di-quantum-resistant-1.0-20260616 , it's very similar, though the proof config handling of \@context\ is different, and it mandates Base64 instead of Base58-btc. This is fine for us as our Multibase implementation supports deconding both anyway.

For embedded objects, I still have to read up on the recent suggestions, but I'm afraid this is going to be quite complex even though this would be valuable to us (for instance, to bundle quoted objects with a short-lived proof that they have been accepted, and avoid the costly and failure prone initial round-trip).

Talking about short-lived proof, is there any recommendation as to what to do with \created\, or support for \expires\?

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.

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.

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.