Salmon Pixie Dust

Convener: John Panzer

Tags: salmon, authentication, aggregators, spam, abuse, identity   Discussion notes:   Start by visiting salmon-protocol.org for background:   Problem statement for "identifier correlation problem":

• sources need to identify both aggregators and users for abuse prevention.  It should be hard for bot-nets to bring up new aggregators with a good reputation.
• it should be possible for userX@aggregator-one and userX@aggregator-two to show up as the same user (userX, or open id for userX) at the source.

Backing up, new problem statement: how does aggregator authenticate to source?

Option 1: client-side SSL certificates with PKI

Option 2: two-legged OAuth with public key discovery

Example: new aggregator says "Hi, I'm aggregator.com", with certificate from Verisign         

Alternate proposal:

• new aggregator says "Hi, I'm new here, please give me a fresh id"
• source assigns random id
• new aggregator begins using random id

Objection #1: tough to build public reputation based on this

Objection #2: difficult to maintain reputation after key compromise

Possible solution for OAuth public key discovery is being discussed in OAuth + PKI discussion tomorrow morning.

What happens if there is a single bad user at the aggregator?

• can the source blacklist the bad user, rather than the aggregator?
• can the source send feedback to the aggregator about the bad user?

Distributed negative reputation:

• if multiple sources publish information about bad actors, then we have a distributed negative reputation system that can improve spam detection everywhere.

Decision: if we don't need to solve the identifier correlation problem, we can avoid salmon signatures entirely.

• aggregators are trusted to assert identifiers within their domain
• we build reputation based on aggregators
• we lose the ability for people downstream to verify the comment back to the aggregator

Scenario:

• userX publishes on plaxo
• userY adds comment on blogger
• blogger pushes comment to plaxo
• plaxo adds comment to feed
• friendfeed sees comment from userY@blogger

Use case: how can we let a user see a trace of all comments they've made on all aggregators?

e.g john comments from Twitter, and john comments from Blogger.  Later he can edit/delete both comments from Reader.

This seems to bring us back to the identity correlation problem.

Proposal: aggregators gets OAuth capability pointing to a "comment server". Comment server then posts on user's behalf to source.  Comment server can also edit/delete comments.

Again, this is much easier if we give up the ability to delete comments from Reader.  If a comment is made on aggregator X, that comment can only be deleted on aggregator X.

Note this doesn't necessarily hurt usability.  If comments point back to their source, then you can just click a link on the comment, get back to aggregator X, and delete the comment from there.

Q: How can aggregators send public global identifiers (e.g e-mail, or OpenID blog URL) rather than local identifiers?

A: aggregators just assert the public global identifier.  It's up to sources to trust or distrust aggregators that do that.

If an aggregator continuously posts bad public global identifiers, then they will be blacklisted.  In the future, they will do a better job of validating global identifier.

This is similar to how mail relays work.  There are services that track bad mail relays and sell that data to others.

We filter 90+% of mail spam.  We have gotten good at fighting spam in this way. We can keep doing it.