Deprecation/removal of JSON-LD signatures? #373

Open
opened 2023-04-13 04:22:24 +00:00 by helene · 2 comments
Contributor

Only relays really make use of the complex JSON-LD signatures. HTTP signatures are preferred and preferable for the rest of communications.

JSON-LD signatures were fairly controversial when introduced (and still are) due to the format, requiring JS-specific behaviour and including signatures in the data being signed, as well as privacy/behavioural concerns (activities now contain irrevocable proof of authorship and contents).

Mastodon has introduced JSON-LD signatures first as far as I'm aware, and is also deprecating them. They do not recommend implementing them anymore or using them.

Most fediverse software does not support JSON-LD (very few do, like possibly PeerTube?) either, so removal/deprecation would not result in breakage (except possibly for relays, but Pleroma/Akkoma encounter the issue as they do not support JSON-LD).

Removal of JSON-LD signatures could greatly improve in code clarity and readability, simplifying processing of incoming and outgoing activities while removing attack surface.

Only relays really make use of the complex JSON-LD signatures. HTTP signatures are preferred and preferable for the rest of communications. JSON-LD signatures were fairly controversial when introduced (and still are) due to the format, requiring JS-specific behaviour and including signatures in the data being signed, as well as privacy/behavioural concerns (activities now contain irrevocable proof of authorship and contents). Mastodon has introduced JSON-LD signatures first as far as I'm aware, and is also deprecating them. They do not recommend implementing them anymore or using them. Most fediverse software does not support JSON-LD (very few do, like possibly PeerTube?) either, so removal/deprecation would not result in breakage (except possibly for relays, but Pleroma/Akkoma encounter the issue as they do not support JSON-LD). Removal of JSON-LD signatures could greatly improve in code clarity and readability, simplifying processing of incoming and outgoing activities while removing attack surface.
Owner

The only way in which LD signatures are used currently is outgoing to specifically configured relay inboxes. As for incoming I don't see how it would be a big threat. I think we should be liberal in what we receive and stricter in what we send out. I think the current use of LD-Signatures accomplishes that.

The only way in which LD signatures are used currently is outgoing to specifically configured relay inboxes. As for incoming I don't see how it would be a big threat. I think we should be liberal in what we receive and stricter in what we send out. I think the current use of LD-Signatures accomplishes that.
Owner

I reviewed how incoming LD-Signatures are handled. HTTP signatures are actually required on incoming activities: 808ad2a505/packages/backend/src/server/activitypub.ts (L30-L35)

As such, LD-Signatures are only checked if the validation of the HTTP Signature fails. The reason that I could come up with why HTTP signatures are required but LD-Signatures are also there is that relays do a HTTP Signature but since they aren't the original author they also need the LD-Signature. That does not explain though why the HTTP Signature may be invalid (independent of if the signature was made by the original author).

I still think it would be a good idea to allow to receive activities from relays, I'm just not sure how they send stuff.

I reviewed how incoming LD-Signatures are handled. HTTP signatures are actually required on incoming activities: https://akkoma.dev/FoundKeyGang/FoundKey/src/commit/808ad2a505fea104a16f27184750e16e00aa62d2/packages/backend/src/server/activitypub.ts#L30-L35 As such, LD-Signatures are only checked if the validation of the HTTP Signature fails. The reason that I could come up with why HTTP signatures are required but LD-Signatures are also there is that relays do a HTTP Signature but since they aren't the original author they also need the LD-Signature. That does not explain though why the HTTP Signature may be invalid (independent of if the signature was made by the original author). I still think it would be a good idea to allow to receive activities from relays, I'm just not sure how they send stuff.
Sign in to join this conversation.
No Label
feature
fix
upkeep
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: FoundKeyGang/FoundKey#373
No description provided.