Re: Why are we here? What are our goals?

On 1/30/2004 10:58 AM, Chuq Von Rospach wrote:

> interests are in getting around it. So each server should define it's 
> own web of trust with the help of its admin. If the admin wants to hand 
> off part of that job to some third party, fine, let's build in support 
> for that ala RBL. But let's not legislate that into this service or 
> define what it is. Instead, let's define a server who's assumption is 
> one of non-trust until proven otherwise, and takes appropriate steps to 
> be a safe harbor for its users and minimize any damage an unknown 
> entity might cause.

Delegating trust mechanisms is exactly what I'm talking about. But whether
a particular site or a user at a site choose to default to deny-all or
accept-all is for that site/user, not for the service. The service just
needs to provide the verification mechanisms that are necessary for both
extremes to work.

Specifically, the service MUST NOT take a default approach, but must ONLY
provide the infrastructure and mechanisms for decisions to be made.

As to the range of mechanisms, some of the things I've alread described
elsewhere are:

  - private bonders (I vouch for the organization, under bond)

  - public white/blacklists (org has many friends/enemies)

  - grey-listing on a per-domain or per-mailbox basis

  - hascash/other verification systems

The common requirement for all of those is identity verification, while
the mechanics of each particular system are optional. That's why we need
to provide ONLY verification in the core, and then facilitate the layering
of multiple deployable mechanisms, which the end-points can negotiate over
using something like control messages.


-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/