Re: Defining Trust and Reputation

Ed Gerck wrote:

> Yakov Shafranovich wrote:
> 
>>And the trust model that somebody uses would depend on his definition of
>>spam.
> 
> 
> Yes -- and, in general, the threats that need to be considered. 
> However, before we can define spam (the threat), we need to define 
> what we trust. This may seem ilogical to some. Some people like
> to think of the risk model first, and it works for them most of
> the time. There are good reasons, however, to define trust first. 
> Risk can only be defined after one defines what is at risk, and 
> what is at risk must be that which is trusted to some extent -- 
> otherwise, there would be no risk. In other words, risk has to 
> do with loss and probability of loss but only the loss of what 
> is trusted would affect the system. 
> 
> The general process of establishing trust in the presence of risk, 
> goes from its Initiation (Absence of Trust) to the final Verification 
> Decision (Trust or Not Trust?). Trust refinement and risk refinement 
> are two independent internal feedback loops -- one set of processes 
> that "make trust" and other processes that "break trust". To ensure 
> trust, we need to look at what breaks it. 
> This is shown in the diagram at http://nma.com/image/trustprocess.gif
>  
> 
>>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.
> 
> 
> We can start with a simplied model -- trust no one. And refine as
> we go -- for example: yes, we can trust the information if a number
> X of MTAs in different networks (defining 'different' is a challenge 
> by itself) agrees with a margin of Y.
> 
> 
>>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.
> 
> 
> Having incompatible trust models would be... incompatible. Your suggestion
> can work well though, and I go back to my example above, if we parametrize
> the trust model and let different users pick their own parameters
> (for example, X, Y and 'different' above). The model is the same, the
> instantiation is different.
> 

So practically speaking - how would we proceed with this?

Yakov