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.
Update:
https://www.w3.org/wiki/Activity_Streams/Primer/Context_document_versioning
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…
I think this FEP should point out somewhere that:
controller parameter of the proof, should be the actor of the Activity.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
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)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.
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:
Proof generation and verification algorithms in eddsa-jcs-2022 are changing:
To ensure smooth transition, I propose the following plan:
@context is being copied from the document to the proof.Hi, I’m trying to implement Object Integrity Proofs in Fedify.
I would like to use ECDSA as the Web Cryptography API does not support EdDSA. Would it be possible to add an example in the test suite that uses ecdsa-jcs-2019 as the cryptosuite?
Also, could there be a cryptosuite that uses RSA and JCS together?
I don’t recommend that because all existing FEP-8b32 implementations use eddsa-jcs-2022. And it looks like WebCrypto support is being worked on? Add Curve25519 by twiss · Pull Request #362 · w3c/webcrypto · GitHub
You can find test vectors for ecdsa-jcs-2019 in sections A.3 and A.4: Data Integrity ECDSA Cryptosuites v1.0.
I think FEP-8b32 should recommend only one cryptosuite to avoid fragmentation and extra work for implementers, and over the course of the past 1.5 years we came to an agreement that eddsa-jcs-2022 is the best option. I may implement ecdsa-jcs-2019 in my personal AP server at some point, but this is not going to happen anytime soon
It is possible, I used RSA-based integrity proofs (with a custom cryptosuite) in the early days of FEP-8b32. But people who work on W3C Data Integrity specification consider RSA outdated and insecure, and have no plans to define RSA-JCS cryptosuite.
Thank you for your kind response!
Thanks to you, I was able to successfully sign and verify with Ed25519 in Node.js, Bun, and Deno. 
I will try to implement eddsa-jcs-2022 into Fedify as you said!
In the future, would it be possible to send activities using only Object Integrity Proofs and not rely on HTTP Signatures? Or are Object Integrity Proofs just a complement to HTTP Signatures?
I would say that HTTP Signatures is table-stakes to federate with the mainstream Fediverse and will remain that way at least in the short-term. I’m not sure which implementations/communities are open to dropping signatures at the server/HTTPS layer in leiu of relying solely on client-managed signing, and I would imagine it’s a liability/regulatory issue for some servers on top of a technical sea change. Suffice it to say that dropping TLS-level signing would be a big protocol change and I haven’t seen much conversation implying such a change is imminent!
That said, while it may not be a replacement for HTTP-Signatures, there are plenty of other reasons to adopt it and promote its general adoption. Lots of developer-community research lately has focused on interoperability with other decentralized networks, and I think the Object Proofs model maps well to how Nostr and Bluesky do client-side per-object signing. A bridge to those networks might be able to validate Object Proofs and resign/countersign/etc individual posts for republishing in those other networks (maybe @snarfed can add color here, I probably have the terminology at least a little wrong?). Additionally, there are some portability corner-cases like the dead-server salvage-migration (see user story 3 here), which might also justify client-signing individual objects even if connections to that server (while it’s up!) are also secured by HTTP-Sig.
In theory, yes, but I’d agree with @bumblefudge that HTTP Signatures are here to stay. However, there are other uses for integrity proofs:
Announce with signed embedded object (recipients don’t need to fetch it from origin)Oh, and it also remains to be seen what per-user keys (client-managed and/or server-managed) implementations will already be implementing for E2EE if they prioritize that feature first-- I know Evan is researching this at the moment and there may be some FEPs around that soon. The more composable these various features are, the smaller the lift for any one FEP becomes 