Use cases of fep-8b32: Object Integrity Proofs

ActivityPub
1

Continuing the discussion from FEP-8b32: Object Integrity Proofs:

I’m starting a new topic to collect the cases where using signed documents will be useful. New topic, as I’d like this discussion to be separate from the original topic, that discusses how to implement proofs.

I’m currently aware of three use cases:

  • FEP-c390: Identity Proofs.
  • Forwarding from the inbox if the activity is signed then it can the person that receives the forwarded activity doesn’t need to fetch the activity to check authenticity.
  • Announce activities can contain the signed object. This would require the ability of the server sending the Announce to obtain a signed copy of the object being announced.

Are there more use cases?

Another side note: By signing documents, we turn them from “linked data” into json-ld as a key resolver. I don’t think the signatures survive using another context on the documents, or resolving an URI for the corresponding document. So these signatures are probably similar to HTTP Signatures only good for the transport and forwarding. I haven’t worked out the use cases in sufficient details to have a firm opinion here.

As I was reminded of Should we fork AS/AP specs to Codeberg, create vNext drafts?, let me also make this bridge. Using Fep-8b32 to specify modified Announce / Inbox Forwarding behavior is quite a step to take for evolving AP/AS. I personally think it should be up to the person spending the energy to work out the details if they want to do it via W3C or FEP or something else. However, I think it’s something one should form an opinion on, before submitting a document.

3 Likes
2

Another interesting use case is client-side signing. This requires FEP-c390 (for linking user’s signing key to the actor) and server needs to accept activity ID provided by the client.

3 Likes
3

Not sure that’s how I would implement that. If the client were to sign the Note object (not the Create), I would like to see some type of process where first the Note is assigned by the server an id (and possibly reply, shares, etc… collections), and then the client uploads a signed Note.

Disclaimer: I haven’t worked out the details yet. It relates to a lot of stuff somewhere not at the top of my todo list (like actually displaying something like a public timeline).

4

Yes, there are multiple ways to implement that. I’m using semi-random IDs, so I can generate them on the client and construct object IDs according to the template (https://myserver.example/objects/<uuid>) without requesting ID from the server.
This is on my todo list. I already have a number of API endpoints that enable client-side signing, for example user can sign “profile update” activity and send it as is to followers. It is working but I need to rewrite everything to use AP C2S, FEP-8b32 and FEP-c390.

5

By using signed objects the mechanics of fep-1b12 should extend to activities only addressed to the group. This will lead to “facebook style groups”, i.e. only members of the group can see what was posted to the group.

This might require some UI work in implementations:

  • It should be possible to address a post to a group. The Mastodon mechanic of “mention” + selecting visibility “mentioned people only” might work in theory, but would lead to users unhappy with the UX if they are supposed to use this for group posting.
  • Announce activities from a group need to interpreted correctly, in particular one should be able to reply with the group being the recipient.

I don’t think any of this is hard. It just needs thinking things through properly.

1 Like
6

In theory FEP-8b32 may unlock content-addressing, but I haven’t figured out how to introduce it without breaking compatibility with existing software.

In ActivityPub, id property is required, but one can’t know the hash of the object before hashing it. Possible workaround: sign everything except the id:

{
    "type": "Note",
    "attributedTo": "https://test.example/users/alice",
    "content": "Example",
    "proof": {
        "excludedProperties": "id",
        ...FEP-8b32 proof
    }
}

Let’s assume that IPFS CID of this object is bafybeihc4hti5ix4ds2tefhy35qd. The content URI will be ipfs://bafybeihc4hti5ix4ds2tefhy35qd.

The AP server should also work as IPFS gateway and use /ipfs/<cid> template to generate the ID:

{
    "id": "https://test.example/ipfs/bafybeihc4hti5ix4ds2tefhy35qd"
    "type": "Note",
    "attributedTo": "https://test.example/users/alice",
    "content": "Example",
    "proof": {
        "excludedProperties": "id"
        ...FEP-8b32 proof
    }
}

Implementations that support content addressing can ignore the host name and load object directly from IPFS, they will also know how to re-create ID. Everyone else will fetch it via HTTP. The server may even insert id property when serving objects via HTTP to provide backwards compatibility.

That might work. Unfortunately, Data Integrity spec doesn’t support partial signing, and there’s no such parameter as excludedProperties.

7
1 Like
8

Federated moderation such as sharing results by PhotoDNA should use cryptographic signatures, so there is better accountability.

9

Integrity proofs are good for all kinds of approvals and attestations. And while there are ways in which they can be abused (e.g. inserting centralized attestation services into a network), I think there are many legitimate use cases as well. In the past I suggested that FEP-5624 implementations may use integrity proofs to reduce the number of HTTP requests: FEP-5624: Per-object reply control policies - #42 by silverpill.