FEP-8b32: Object Integrity Proofs

I’m updating the FEP: #232 - FEP-8b32: Update proposal - fediverse/fep - Codeberg.org

Added a warning about eddsa-jcs-2022 stability and clarified how integrity proofs and linked data signatures can be used together.

@Mario Have you figured out why Mastodon is refusing to accept your messages? If you’re going to open an issue in their bug tracker, please let me know and I’ll mention it in the FEP.

1 Like


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, or just further tax/annoy/bully the devs who don’t use LD for anything? I was under the impression that RDFC is a lot more feature-complete and street-ready than it was a year ago, but that is more anecdotal/hearsay than based on personal experience.

I think it’s better to stay away from anything JSON-LD/RDF related. Developers don’t like it, and for those few who do JSON-LD processing it seems to be a constant source of problems.

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.


Sorry for the late reply… Nope, no progress so far. Have not opened an issue yet. Will post here if i do…

1 Like

I think this FEP should point out somewhere that:

  • When verifying an Activity, the controller parameter of the proof, should be the actor of the Activity.
  • When verifying an Object, the controller parameter of the proof, should be the attributedTo of the Object.

I think this would be a step forward in clarifying what integrity constraints on ActivityPub objects mean. The advantage of starting in this FEP is that the conditions should be pretty uncontested. The two points above should “obviously” be true.


Did you mean verificationMethod?
controller is not listed among possible properties of an integrity proof: Verifiable Credential Data Integrity 1.0

1 Like

I opened a pull request that adds “Nested objects” section to this proposal: #287 - WIP: FEP-8b32: Update proposal - fediverse/fep - Codeberg.org

Well no. I meant controller. My understanding of the mechanism is:

  • Signed Document -> (base document, proof, verificationMethod)
  • verificationMethod → (via lookup of the URI) (key material, controller)
  • If valid, the claim is “controller states base document is valid”.

As it only makes sense for a controller to claim their own documents are valid, I would expect controller == actor.

In the Fediverse context, I would expect the ActivityPub Actor to be the controller (in the sense of Data Integrity). On a side note: I somewhat prefer the term controller over actor, as actor has a different meaning in programming. Controller pretty much captures what the Actor does in AP. It asserts that the entity behind it controls the inbox, outbox, and corresponding keys.

1 Like

I started by introducing the concept of a controller document in FEP-521a:

For FEP-8b32 the relevant part of specification seems to be section 4.7: Verifiable Credential Data Integrity 1.0.

FEP-8b32 is being updated as well. I removed the controversial recommendation to re-define object (will add it in a separate PR later), and added a paragraph about activities:

The controller of the verification method MUST match the actor of activity, or be associated with that actor.

In FEP-ef61 proofs are signed by identity, not by actor, so it is not as simple as controller == actor.

Objects are even more complicated, so I’ll leave them out for now.


Recommendations for nested objects: