Re: Defining Trust and Reputation

Clarification:

I'm not talking about humans, even though some examples are
anthropomorphic. I am talking about EMAIL ADDRESSES, MTAs, 
MUAs, END POINTS. Trust at the end points -- the end point 
is able to do TCP/IP, end points are not human. Senders and
receivers are machines. It is also not relevant if there is, 
or there is not, a human in control of an end point. It can 
very well be another machine.

I also mentioned that trust betwen machines should be based 
on the same definition we use for millenia between humans. 
Why? So that machines could use well-developed, real-world, 
tested notions of trust -- and be thus useful to us as our 
agents.

Cheers --/Ed Gerck

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.
> 
> In terms of trust as I defined before here [1], an email address
> should have a *minimum* of three possible values: +, 0 and -
> 
> +       trusted according to policy(+)
> 0       trust value not assigned
> -       distrusted according to policy(-)
> 
> Of course, the positive and negative range can be expanded
> in values as well. How to assign these values? How the trust
> model works? Let me copy from an earlier discussion elsewhere.
> 
>  This is the wrong question to ask. The real answer is, "what trust
>  model would you like?" There is a built-in notion (given by the
>  abstract trust definition in [1]) of the meta-rules that a trust
>  model has to follow, but I might buy a trust model from someone
>  and add that, design my own, or even augment one I bought. Thus,
>  I can ask for a fingerprint and check it against the FBI, Scotland
>  Yard, and Surite databases, check their PGP key to make sure that
>  it was signed my Mother Theresa, ask for a letter of recommendation
>  from either the Pope or the Dalai Lama (except during Ramadan, when
>  only approval by an Iman will do), and then reject them out of
>  hand if I haven't had my second cup of coffee.
> 
>  As flippant as I'm being, this has a lot of value. I write with a GUI
>  framework because I don't have to worry my pretty little head about the
>  details of how to draw a checkbox. I ask the system to draw it for me, and
>  it does. It even handles what happens when it's clicked. I just ask the
>  checkbox if it's on or off, and it tells me. If I want a special checkbox,
>  I can make one of those as a subclass, and once I've done that work, I
>  don't have to think about it again, I just use it. Similarly, if I use
>  such a concept of trust, I may have to do some up front work to get
>  things the way I want but I can always use an off-the-shelf validity
>  mechanism. In either case, I just ask the trust framework if the
>  trust assertion is valid. The framework can combine rules of thumb
>  with special-cases as appropriate, and without my having to worry my
>  pretty little head about it.
> 
> 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