search

swicg / activitypub-e2ee

Coordination of work on end-to-end encryption with ActivityPub
20 stars 0 forks source link

Non-repudiable activities, objects, etc. (i.e. Activities whose authorship can be verified.) #23

Open bobwyman opened 5 months ago

bobwyman commented 5 months ago

"As an ActivityPub user, I want to be confident that the activities I observe were, in fact, created by those who claim to have created them."

A useful subset of a system that provides E2EE would support the creation of un-encrypted activities, objects, etc. in such a way that a receiver or reader of such data can be reasonably certain that claims made about its authorship can be verified and cannot be repudiated.

I should be able to "sign" activities, etc. that I create in such a way that those who receive them will be able to reasonably certain that I did, in fact, create these things, without having to trust any of the potentially large number of intermediaries in the path between my creation software and the receiver's system(s).

An ability to create non-repudiable data would not only allow one to combat spoofing, it would also open up a variety of new AS/AP application spaces. For instance, if messages are non-repudiable, they might be used to reliably communicate consent. Such an ability might form the foundation of social systems which support offers-to-sell or -buy, or offers-to-hire or be hired, etc...

evanp commented 5 months ago

Is this one in conflict with #19 ?

ag-eitilt commented 2 weeks ago

Non-repudiation certainly has its place, like you list in your last sentence, but I really want to push back on using it by default, and particularly using it at rest outside of those very specific, opt-in contracts. Any server receiving something should be reasonably certain that it's not feeding the user spoofed data, but after that point maintaining non-repudiation means that you're binding the people you talk to in a way which can be proved by any hacker that gets into the database, doxxer who sends screenshots of their own conversations, or law enforcement who targets a weak link rather than getting a warrant for the sender directly.

This does have some overlap with E2EE in that it would likely use a number of the same primitives, but on the whole I feel it's a bit odd to state this as a goal here, when most E2EE protocols I know of (which admittedly isn't many) actively try to incorporate some form of inherent deniability or transience.