Hello!

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

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:

https://blog.trailofbits.com/2019/07/08/fuck-rsa/

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.

Is there more on the client+relay model posted anywhere? I wonder if this helps support a model where private keys are held client-side.

I don't know how much you have in common with Friendica, but they had a similar problem: https://github.com/friendica/friendica/issues/12815#issuecomment-1685307304

Hello!

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

Looks like there is a flaw in eddsa-jcs-2022 cryptosuite and that might lead to its deprecation and replacement with a new version: https://github.com/w3c/vc-data-integrity/issues/225

No action is needed right now, just something that we should be aware of.

Thanks, for this FEP being adopted.

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.

Hello!

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

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?

In theory, yes, but I'd agree with @bumblefudge that HTTP Signatures are here to stay. However, there are other uses for integrity proofs:

• Forwarding from inbox
• Efficient Announce with signed embedded object (recipients don't need to fetch it from origin)
• Federated groups (for example, FEP-8b32 is used in Conversation Containers).
• Data portability.

Hello!

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

Hello!

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

Hello!

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

Hello!

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

I'm updating the FEP: https://codeberg.org/fediverse/fep/pulls/232

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.

Several solutions were proposed - embeddedObjects

This sounds a lot like JSON-LD @included:

{ "@context": "https://www.w3.org/ns/activitystreams", "id": "https://activity.example/", "actor": "https://actor.example/", "type": "Announce", "object": "https://object.example/", "@included": [ { "id": "https://actor.example/", "name": "Someone", "type": "Person" }, { "id": "https://object.example/", "type": "Article", "name": "Top 10 AS2 examples -- number 3 will surprise you!" } ]}

If you ignore all the JSON-LD stuff, the "plain JSON" document is just this:

{ "id": "https://activity.example/", "actor": "https://actor.example/", "type": "Announce", "object": "https://object.example/",}

If you flatten the first example or convert it to N-Quads, the @included block goes away. The @included block is just a framing tool so that the "plain JSON" can match a specific schema (say one where actor and object are required to be JSON strings). It's broadly similar to JSON:API's concept of "included", as JSON-LD 1.1 points out... except it keys off of @id only (instead of both type and id).

A canonicalization scheme could define that included blocks are stripped before hashing and signing, and that therefore the information included in an included block is not trustworthy on its own without its own signatures. I guess you could profile JCS if you wanted to depend on the JSON serialization, or profile RDFC if you wanted to depend on the N-Quads dataset (minus the included statements).

Claire:

how would you “make sure” the object is indeed a <https://www.w3.org/ns/activitystreams#object> while keeping the object’s JSON representation intact? Off the top of my head, I see no way to do that safely.

If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have lately come to the conclusion that JSON-LD and JSON cannot coexist in the same network.

The way you "make sure" that object is specifically is via one of the following mechanisms:

• JSON-LD @context expansion. A JSON-LD processor loads the declared contexts (modulo other document loader safety concerns) and normalizes everything to its full IRI reference.
• IANA media type signaled via HTTP Content-Type header is application/activity+json or equivalent. Per definition, that media type includes the semantics that the object key is defined as . For JSON-LD compatibility, this is also achieved via "context injection", i.e. when you encounter this specific IANA media type, you can convert it to an application/ld+json document by tacking on "https://www.w3.org/ns/activitystreams" as the end of the @context array in case it is missing.

The latter is the closed-world / centralized variant of the former. They clearly already co-exist in the same network. The issue arises when you use terms that aren't defined by application/activity+json or its equivalent JSON-LD @context, but this isn't JSON-LD's fault -- the issue's real cause is that people can and will disagree on what terms mean, as with any other matters of language. You can't assume everyone always agrees with everything you do or say 100%. The point of having keys and terms be expandable to IRI references is that http(s): IRIs conveniently include an authority component, so you can workaround the lack of authority in the data model and disambiguate two different definitions of the same term. Having a way to detect that there is a conflict does not create the conflict; the conflict is still there even if you don't have a way of detecting it.

tl;dr,

how one is expected to handle proofs of embedded objects

depends on canonicalization. Embedding an object from one document into another document should be done with the recognition that documents and objects are not the same thing, and that embedded information about an object is necessarily scoped to the current document in which that information is presented.

For example:

GET /foo HTTP/1.1Host: domain.exampleAccept: application/activity+json

HTTP/1.1 200 OKContent-Type: application/activity+json{ "id": "https://domain.example/foo", "type": "Activity", "object": { "id": "https://domain.example/bar", "type": "Object" }}

Here, the statement that /bar is an Object is a statement being made within /foo. You can GET /bar and obtain different information (e.g. that /bar is a Tombstone). That doesn't make the statement in /foo incorrect; it could be that statements in /foo and statements in /bar were made at different times.

When signing or verifying objects, it's crucial to consider what you're signing. As the author of /foo I can sign my own statement about /bar within /foo, and this is different than a signed statement about /bar from the author of /bar within /bar. If you don't distinguish or qualify statements by their source[^1], you will get confused.

[^1]: This is what quads are supposed to be in RDF -- they contextualize triples by the graph they came from. But you don't need to use quads, you just need to use some kind of contextualizing thing, like an HTTP resource; the statements in that resource can still be modeled as triples, while you reason about them as quads in order to explicitly consider who said something, or when they said it, or whether or how much you trust that statement.

I can't get too much into this further, since anything else depends heavily on what your trust model is. But for the purposes of signatures, you have to look to the current document (and possibly infer additional information from HTTP headers).

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

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?

Additionally, I’m not sure how one is expected to handle proofs of embedded objects: indeed, if you consider the whole document as JSON-LD, the JSON-LD API does not give you much to unambiguously access a precise attribute other than expanding, compacting, or framing the document, but all these operations may change the JSON representation and thus break the signature.

A similar concern was raised by @helge in another thread: https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/10. Several solutions were proposed - embeddedObjects, re-defining object as @json, etc.

Later, I opened an issue in w3c/vc-di-eddsa bug tracker - https://github.com/w3c/vc-di-eddsa/issues/81. They said it is fine to embed a signed object and I didn't ask any more questions.

E.g., in https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md#signed-activity-with-embedded-signed-object, how would you “make sure” the object is indeed a <https://www.w3.org/ns/activitystreams#object> while keeping the object’s JSON representation intact? Off the top of my head, I see no way to do that safely.

If I understand the question correctly, this problem also arises in client-to-server context. An object published by a client can be parsed differently by the originating and receiving servers due to JSON-LD/JSON differences. This could cause security issues, and I have come to the conclusion that JSON-LD and JSON cannot coexist in the same network.

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

Hello!

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

Hello!

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