Re: Defining Trust and Reputation

Yakov Shafranovich <[email protected]> Thu, 18 Mar 2004 18:09:53 -0500
Newsgroups gmane.ietf.asrg.smtpverify
Organization SolidMatrix Technologies, Inc.
Message-ID <[email protected]>
Ed Gerck wrote:
> While I'm still reading past postings to falimiarize myself
> with what has already been done, I'd like to reply to Yakov's 
> message Re above. Because I need to first deal with a scale 
> for trust values, my answer is actually at the end, where I
> restate some of Yakov's comments.
> 

(sorry that it took a while to reply, I have been flooded with emails)

> In short, trust on the sender cannot be proven by the sender (self-
> assertions cannot induce trust -- e.g., "trust me" doesn't work).
> It must be calculated using sources independent of the sender. The sender 
> may hint to a specific trust service used, and even provide it and its 
> values, but we should be able to get that information from the service 
> directly and/or chose our own trust services independently. In doing so, 
> trust on the sender is what the receiver determines at a specific time 
> based on a behavior model for the sender. If the sender cooperates, 
> the process can be faster and easier. But the sender cannot determine 
> the process.
> 
> The problem is, thus, not how do you determine trust, especially with all 
> the different definitions of spam possible, but how do you want to do it.
> All you need to do is conform to the abstract model of trust [1]. 
> 
> Cheers,
> Ed Gerck
> 
> [1] http://nma.com/mcg-mirror/trustdef.htm
> 

And the trust model that somebody uses would depend on his definition of 
spam.

It seems to me that we have two approaches here:
1. We can try to define a trust model that is reasonable for fighting 
spam. However, with the divergent spam definitions, that might be 
unrealistic.
2. We can try to define a framework for exchanging and queing trust 
information, and let receivers pick their own trust models that they 
want to use. Part of this would be a protocol for providing hints from 
the sender. This might be more realistic, but is still a lot of work.

Yakov