Use cases of fep-8b32: Object Integrity Proofs

ActivityPub
21

This is the price I’m willing to pay.

Signed embedded objects are now used in production (example: Streams and its Conversation Containers where both activities and their objects are signed) and FEP-8b32 should say something about it. Sadly, Verifiable Credentials workgroup still haven’t provide us with any guidance. Unless there are other arguments against re-defining object, I’ll describe this hack in the proposal.

22

:+1:

I think the general problem of how to attach meta data, such as integrity proofs, is outside the scope of work on the Fediverse. We are not the ones designing the JSON-LD/RDF data format.

Hopefully people will release that these are problems actual users of these specifications face, and work on resolving them upstream.

1 Like
23

I should actually clarify something here. The so called hack’s purpose is for stuff to remain valid JSON-LD, not to break compatibility with JSON-LD processors as suggested above.

In particular:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://www.w3.org/ns/credentials/v2"
    ],
  "actor": "https://first.example/users/first",
  "cc": [
    "https://second.example/users/second",
    "https://first.example/users/first/followers"
  ],
  "id": "https://first.example/users/first/statuses/1097854/activity",
  "object": {
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://www.w3.org/ns/credentials/v2"
    ],
    "id": "https://second.example/users/second/statuses/109724234853",
    "type": "Note",
    "content": "Hello world",
    "proof": {
        "type": "DataIntegrityProof",
        "cryptosuite": "eddsa-jcs-2022",
        "verificationMethod": "https://second.example/users/alice#ed25519-key",
        "proofPurpose": "assertionMethod",
        "proofValue": "z3sXaxjKs4M3BRicwWA9peyNPJvJqxtGsDmpt1jjoHCjgeUf71TRFz56osPSfDErszyLp5Ks1EhYSgpDaNM977Rg2",
        "created": "2023-02-24T23:36:38Z"
    }
  },
  "published": "2023-01-31T19:11:46Z",
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "type": "Announce",
   "proof": {
        "type": "DataIntegrityProof",
        "cryptosuite": "eddsa-jcs-2022",
        "verificationMethod": "https://first.example/users/first#ed25519-key",
        "proofPurpose": "assertionMethod",
        "proofValue": "fixme",
        "created": "2023-02-24T23:36:38Z"
    }
}

is an invalid json-ld documents. As we will want to sign objects containing signed objects. This is unacceptable.

Finally, by changing the enveloping context to

    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://www.w3.org/ns/credentials/v2",
         {
           "object": {
             "@id": "as:object",
             "@type": "@json"
           }
         }
    ],

one can resolve this problem.

24

And create others, since the JSON-LD processors will treat the object value as a string during RDF deserialization (as described previously).

25

i haven’t been following the whole conversation here, but isn’t this what envelopes are meant to solve? no need to redefine object, just put the whole thing in an envelope and sign the envelope instead. when you open the envelope you get your jsonld/rdf/whatever working just fine.

26

What is an envelope? Could you provide an example?

If we redefine object, JSON processors won’t notice anything. Same activities and objects, but signed. Implementations that use JSON-LD processing may break, but there are only a few, and they can be dealt with on an individual basis (?).

27

A basic example of a signed envelope is “base64 encode the payload, then sign that encoded string” Magic Signatures - diaspora* federation protocol

28

But how to apply this in a case where object is embedded? Example: we have Create activity and we want to sign both activity and the created object.

29

That was sort-of one of my earlier ideas I pitched before Portable Objects: to have a variant of the object with DID-based identifiers, that’s base64’ed and embedded in a ‘normal’ ActivityPub object (with standard “surface web” URL identifiers); thus able to not break any compatibility with non-DID-aware ActivityPub servers, and still have portability. Although it wasn’t something I tried to bring up as a serious consideration, given how much more it’d bloat the object.

30

I think the topic for FEP-8b32:

is the better one to discuss how to implement signing objects.

The point of this thread is more:

We have signed objects now. How do we use them?

These are two distinct topics. I also think that currently there is no alternative proposal of FEP-8b32. Maybe, there is a better alternative. However, I wouldn’t expect one to emerge in this decade. So we are left with analyzing the consequences and working with them.

3 Likes