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