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

I don't think so? This is about having multiple proofs for the same document, but having one of the proofs only be valid if another one is valid too. What we are currently talking about is having a proof on a sub-graph and possibly no second proof. I see nothing in the Verifiable Credential Data Integrity spec addressing sub-graphs, only full documents (excluding proof graphs, but what we want to omit from the inner proof is not a proof graph). But that seems to imply RDFC would have the same issue indeed.

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.

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

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.

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).

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. We could still do that using eddsa-rdfc-2022, which I guess would make sense since we are dealing with JSON-LD to begin with. but I definitely see the value of avoiding the RDF Dataset Canonicalization algorithm if we can.

Verifiers should probably treat expired proofs in the same way as proofs with unsupported algorithms and try other authentication methods on verification failure (e.g. fetch object by its id).

I opened a PR that adds the following text:

If a verifier encounters an integrity proof that uses a verification method that it can't resolve, or uses a cryptosuite that is not supported, or the proof has expired (as indicated by the expires property), the verifier SHOULD ignore the proof and try other authentication methods.

The PR also adds Mastodon to the implementation list and adds "Quantum-resistant cryptosuites" to future work.

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\?

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

@Claire I added intermediary outputs to fep-8b32.feature: canonicalized document, canonicalized proof config and the combined hash:

https://codeberg.org/fediverse/fep/src/commit/90444d8d5e880f2511e09efd8c142e4f0e13e4f6/fep/8b32/fep-8b32.feature#L31-L39

(PR: https://codeberg.org/fediverse/fep/pulls/871)

To ensure smooth transition, I propose the following plan:

• Implement new proof verification algorithm (section 3.3.2), specifically step 4.
• Give everyone some time to upgrade (a couple of months)
• Implement new proof generation algorithm (section 3.3.1), specifically step 6 where @context is being copied from the document to the proof.

Two remaining unresolved issues are context injection when object doesn't have @context and proving integrity of nested objects.

https://github.com/w3c/vc-di-eddsa/pull/79

To ensure smooth transition, I propose the following plan:

• Implement new proof verification algorithm (section 3.3.2), specifically step 4.
• Give everyone some time to upgrade (a couple of months)
• Implement new proof generation algorithm (section 3.3.1), specifically step 6 where @context is being copied from the document to the proof.

Also, there was a sentence saying that proof.verificationMethod can be a DID. I think this is not correct because the fragment identifier of the verification method should be included as well, and that makes it a DID URL.

Good-faith question because I too have mixed feelings about JSON-LD and its tooling/ecosystem support, but would recommending or requiring an RDFC step in signing FEPs (current or future) help the “bad LD” issue,

My opinion is: No, it would not.

The entire JsonLD - RDF - LinkedData space has a list of known problems (In the sense, if you payed me a lot of money, I could write one down with examples). Replacing JCS with RDFC just makes some problems on the list better, and some other problems on the list worse.

Suggestions

[] Include test cases of activities that should be valid using various algorithm pairings. This would at least help me, if I wanted to implement this. [] Specify behavior if Authentication is missing, e.g.

A server MAY require Authentication. In this case a request lacking authentication MUST be answered with HTTP 401.

[] Discuss behavior for AP S2S 7.1.2 Forwarding from Inbox, e.g.

A forwarded activity MAY be used without further verification, i.e. no GET is necessary from the original host.

[] Discuss public key caching. This probably goes beyond the scope of this FEP. So, one might one want add something like This section is non-normative. to it.

https://codeberg.org/fediverse/fep/pulls/142

Your implementation of FEP-521a appears to be correct (I was able to fetch lobsters actor you mentioned in readme; can’t verify FEP-8b32 because my Follow activity is being rejected with FST_ERR_CTP_INVALID_MEDIA_TYPE).

Thanks for checking it out! It looks like the follow requests were getting dropped by fastify because the content-type was “application/ld+json” instead of json or activity+json. I’ve just added that to the list of accepted content types.