silverpill:

trwnh@socialhub.activitypub.rocks

silverpill:

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

silverpill:

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,

Claire:

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

silverpill@socialhub.activitypub.rocks

hongminhee:

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.

silverpill@socialhub.activitypub.rocks

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.

robey@socialhub.activitypub.rocks

I see, so "https://w3id.org/security/data-integrity/v2" should replace "https://w3id.org/security/v1" in the standard context block at the top? We should probably call that out explicitly in the next revision of the FEP. (I think most servers write the boilerplate template once and then ignore it.)

helge@socialhub.activitypub.rocks

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)
If valid, the claim is "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.

helge@socialhub.activitypub.rocks

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.

silverpill@socialhub.activitypub.rocks

Proof generation and verification algorithms in eddsa-jcs-2022 are changing:

https://github.com/w3c/vc-di-eddsa/pull/79

To ensure smooth transition, I propose the following plan:

Implement new proof verification algorithm (section 3.3.2), specifically step 4.
Give everyone some time to upgrade (a couple of months)
Implement new proof generation algorithm (section 3.3.1), specifically step 6 where @context is being copied from the document to the proof.

silverpill@socialhub.activitypub.rocks

I’ve never used Gherkin before, but I was able to read and edit your FEP-8b32 feature file without reading any docs. The syntax is intuitive and that makes Gherkin a useful tool for spec writers. My implementation tests for FEP-8b32/jcs-eddsa-2022 are not based on it though, as I try to avoid adding new dependencies. I simply copied inputs and outputs from the feature file.

robey@socialhub.activitypub.rocks

silverpill:

Your implementation of FEP-521a appears to be correct (I was able to fetch lobsters actor you mentioned in readme; can’t verify FEP-8b32 because my Follow activity is being rejected with FST_ERR_CTP_INVALID_MEDIA_TYPE).

Thanks for checking it out! It looks like the follow requests were getting dropped by fastify because the content-type was “application/ld+json” instead of json or activity+json. I’ve just added that to the list of accepted content types.

silverpill@socialhub.activitypub.rocks

@robey Did you change the proof.@context? I saw an activity from your test actor few days ago, and it still had wrong context.

helge@socialhub.activitypub.rocks

My current plan is to locate all my Gherkin features in that repository. This includes both FEP and ones that test other aspects of the Fediverse. I have no idea if different repositories for features and docs are a good split. As having a features repository already means that I split code and tests, it doesn’t seem like a big deal to me. I probably won’t have a firm opinion on what a good structure looks like in the next few weeks.

helge@socialhub.activitypub.rocks

bumblefudge:

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,

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.

silverpill@socialhub.activitypub.rocks

I opened a pull request that adds "Nested objects" section to this proposal: https://codeberg.org/fediverse/fep/pulls/287/files

silverpill@socialhub.activitypub.rocks

JCS context injection PR has been merged, test vectors have been updated as well. I will update my implementation in two stages, according to the plan:

silverpill:

To ensure smooth transition, I propose the following plan:
Implement new proof verification algorithm (section 3.3.2), specifically step 4.
Give everyone some time to upgrade (a couple of months)
Implement new proof generation algorithm (section 3.3.1), specifically step 6 where @context is being copied from the document to the proof.

Two remaining unresolved issues are context injection when object doesn't have @context and proving integrity of nested objects.

silverpill@socialhub.activitypub.rocks

Removing warnings about nested objects from the FEP: https://codeberg.org/fediverse/fep/pulls/396.

Also, there was a sentence saying that proof.verificationMethod can be a DID. I think this is not correct because the fragment identifier of the verification method should be included as well, and that makes it a DID URL.

silverpill@socialhub.activitypub.rocks

@helge Are you planning to move this file to fediverse-features? I want to add test vectors for FEP-8b32, but I am not sure how to do it. Gherkin syntax looks nice. It is human readable, and it is definitely better than plain JSON files. However, I think it would be better to put test vectors alongside the FEP, and not in a separate repo.

silverpill@socialhub.activitypub.rocks

I'm not familiar with JWKs, but according to RFC-8037 the "d" parameter is a base64url encoded private key. I tried to decode it, and the value I get is different from the multibase-encoded one.

silverpill@socialhub.activitypub.rocks

jcs-eddsa-2022 description was fixed a couple of days ago (PR). I proceeded with implementation of the algorithm and incorporated it into my software (here is the signing function). However, I'm not sure how to distribute EdDSA keys. The most logical place for them seems to be publicKey property, which can take the form of array where the first item represents RSA key and the second item represents EdDSA key. But servers may expect publicKey to be an object and fail to process an array, making gradual upgrade impossible. So we need to either use some new property (authentication?) or keep RSA as the recommended signature algorithm.

silverpill@socialhub.activitypub.rocks

VC workgroup changed the name of cryptosuite from jcs-eddsa-2022 to eddsa-jcs-2022. The FEP has been updated accordingly.

https://codeberg.org/fediverse/fep/pulls/142

helge@socialhub.activitypub.rocks

silverpill:

However, I’m not sure how to distribute EdDSA keys.

One option would be to use the mechanism from fep-4adb and just use a did-key as identity, i.e. have an actor of the form:

{ "@context": [ "https://www.w3.org/ns/activitystreams", { "xrd": "http://docs.oasis-open.org/ns/xri/xrd-1.0#", "aliases": { "@id": "xrd:Alias", "@type": "@id", "@container": "@list"}, } ], "id": "https://chatty.social/bnm789", "preferredUsername": "ben", "aliases": [ "acct:ben@chatty.social", "did:key:z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5" ], ...}

I don't see any disadvantages in this approach compared to using a "publicKey" property or similar. I see some advantages in this approach, that's why the above fep discusses it.

fedi wiki

silverpill:

Suggestions