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 problems
or 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.
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 problems or 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 and nomadic identity.
Here’s an interesting use case: integrity proofs can be used to implement client+relay model, where the signing key is stored on the client and activity signing is done by client as well. The relay (server) accepts signed activity via C2S and delivers it to the audience. The relay can refuse to deliver activity but it can not change the activity in any way, because that would invalidate the signature.
This post was inspired by various discussions about Nostr protocol where identities are key-based and client+relay model is used. Client-side identity is possible in Fediverse too, and I even created a proof of concept, which makes use of FEP-8b32 and FEP-c390 extensions. I talked about this in Nomadic Identity thread:
I’m still not entirely convinced that client+relay model makes sense. But this is something we can explore – all building blocks already exist.
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.
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.
Only a small number of proof suites (methods) has been standardized so far: Verifiable Credentials Extension Registry. I’m mostly improvising and inventing my own suites. If you want to create an interoperable implementation, we can discuss it here or somewhere else, but I don’t want to include non-standard proof suites in the proposal (JcsRsaSignature2022 is used in the example but without it proposal would be incomplete).
Some servers may process activities in background and respond with 200/202 before authentication is performed.
Should this be a separate section in the proposal? Efficient forwarding is not the only use case of object integrity proofs, so if we talk about this we may as well mention other use cases.
I think a section on sample use cases would really help this proposal.
Another possible use case is to include the object being announced in an Announce activity. This would reduce the peak loads on servers, as only servers not having cached the public key, would need to fetch it.
An idea, I had is to use key expiration as a method to decide if content needs to be refetched. I’m not 100% sure if this is a good mechanism, but I thought it might be a good idea to put out there.
One of the remaining issues here is a lack of clarity regarding proof type. When I read Data Integrity spec I get the impression that it recommends using DataIntegrityProof type along with cryptosuite property, but it is not clear how cryptosuites are registered.
I think the Verificable Credential documentation’s state is described in Status of The Document as
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Given that it contains plenty of stuff marked ISSUE in red, I’m leaning towards: Give the authors another 6 months and then check back if it is usable. I’m not sure what I would do if waiting 6 months is not an option. The results of not waiting for a finalized draft can be witnessed in Mastodon’s Documentation on Linked Data Signatures.
I write the above in full appreciation that delaying proper integrity proofs due to unavailability of good credentials will delay a whole other bunch of stuff. However, the alternative currently seems to descent into a possible world of not understandable requirements due to updating definitions.
Integrity proofs are used in many examples throughout the Verifiable Credentials Data Model v1.1 document, which is already a W3C Recommendation. I doubt that Data Integrity spec will change substantially. Terminology and property names have been relatively stable for the past few years. The cryptosuite concept is new but it looks like it is designed to be backwards compatible.
I think the main challenge for FEP-8b32 implementors would be coming to agreement about which algorithms to use. Currently FEP recommends these:
Hashing: SHA-256. I guess this is non-controversial.
Signatures: RSASSA-PKCS1-v1_5. Everyone in Fediverse already uses it to create HTTP signatures. However, ECDSA and EdDSA have smaller key sizes, so if we’re ever going to migrate, FEP-8b32 is a good starting point.
Canonicalization: JCS. This is most difficult one because servers that already support LD signatures (e.g. Mastodon) use RDF canonicalization. If I understand corretly, RDF canonicalization is still a working draft, and it is much more complicated than JCS. I think there’s a good chance that some programming languages will never have a decent RDF library, although today JCS libraries are also hard to find (I haven’t found anything for Ruby and Elixir).
The RDF canonicalization algorithm is actually called URDNA2015. I searched for libraries implementing this algorithm and found Ruby, Python, Javascript, Go, Rust and PHP implementations. This covers all popular AP servers except Pleroma and Mobilizon (written in Elixir). There’s no JCS implementation in Ruby (for Mastodon). I think this is a bigger blocker, so URDNA2015 could be a better choice after all.
Shouldn’t JCS be the clear favorite because it’s faster? I cannot find any analysis of the performance of the two algorithms, but it’s my expectation knowing roughly what they do.
I prefer JCS, but if the goal is to replace Linked Data signatures, we need to get Mastodon on board. I finally found a Rust library that implements URDNA2015 so I’m going to support both algorithms.
It’s unlikely that JCS is part of URDNA2015 because JCS is relatively new standard (2020). They are different algorithms, or at least they appear to be.
I’ve been waiting for Data Integrity spec update, but this may take some more time, it seems. I think it would be better to change the example of signed activity right now, to reflect the recommendation given by @msporny in this comment:
DataIntegrityProof is what we’re hoping the communities using this technology will adopt as they move forward.
The reason for DataIntegrityProof is so that there is a single JSON-LD type for most Data Integrity Proofs instead of the path we were headed down, which would require an entirely new JSON-LD Context for every type of Data Integrity Proof AND would require the inclusion of that context whenever you did a signature of that type. Instead, what we’re trying to do is reduce the number of JSON-LD Contexts an implementation has to pull in, ideally to 1 base context (ActivityPub or Verifiable Credentials)
In summary, I’ll make the following changes:
Replace JcsRsaSignature2022 type with DataIntegrityProof
Add cryptosuite property with the value jcs-rsa-2022
Explain that jcs-rsa-2022 is non-standard and give a link to the spec for a similar cryptosuite, jcs-eddsa-2022: EdDSA Cryptosuite v2022
Hey @silverpill, thanks a ton for shifting towards the new DataIntegrityProof work! I noted above that you plan to create a suite for RSA. I’d strongly advise against doing that for the reasons included here:
New applications SHOULD NOT be using RSA unless there is a very good reason (like being compatible w/ broadly deployed systems in ways that makes it impossible to upgrade to more modern cryptography).
If FIPS HSM support isn’t an issue (and I don’t think it is for activitypub), then you should be using EdDSA ("cryptosuite": "jcs-eddsa-2022"). Also note that we might change the “jcs” name to something else.
RSA was chosen to make implementation process easier for developers. Today the de-facto standard for server-to-server authentication in Fediverse is HTTP signatures with RSASSA-PKCS1-v1_5 algorithm. Every interoperating server already stores an RSA key for each user and knows how to verify those signatures. In order to implement FEP-8b32, developers only need to find some JCS library and adjust their activity construction and validation procedures. And while I understand that jcs-eddsa-2022 is preferable, implementing it would require more effort and that may discourage people. Of course, this is just a guess, and the recommendation will be revised based on a feedback from developers.
I would say: It’s better to encourage people to bite the bullet now then later. If the FediVerse is successful, there will be more projects to convince to make the switch than there are now. Furthermore, it should be a lot easier to find an ed25519 library than a jcs one.
for this FEP being adopted.