[Top] [All Lists]

4d. Consent Framework (was Re: [Asrg] 3. Requirements - Consent Framework)

2003-09-30 23:14:34
Jonathan Morton wrote:
I think I have got a handle on Yakov's proposed Consent Framework, or at least what it attempts to achieve. The actual document remains sadly opaque to me. I'll try to summarise my understanding below. Yakov, feel free to correct me if I'm completely off-base.

Just a minor correction on the subject line, the consent framework has a separate item number. Also, I am basing the framework on the charter, so I don't know if it is correct to call it mine.

The "Consent Framework", while presently documented in an extremely formal and opaque manner, is nothing more than a "system of systems", aimed at combining the best-of-breed proposals (the exact ones to be determined at some time in the future) into a single, cohesive, implementable e-mail system. Preferably, of course, leveraging the existing SMTP infrastructure, because that makes implementation several orders of magnitude easier.

Sorry for being "formal and opaque" but I followed the similar model used for IMs defined by the IMPP WG (see RFC 2778). I have been considering for a long time whether to rewrite the document to be less formal and opaque, and recent discussions especially the thread with Gordon has been strongly pointing in that direction.

Jonathan is correct - the consent framework seeks to tie in all of the existing and future solutions into one system. The central tie-in point to the whole framework is the notion of consent which is presently absent from the email system while being present in some form in other messaging systems such as Instant Messaging (IM). From the charter (

"Therefore, we generalize the problem into "consent-based communication". This means that an individual or organization should be able to express consent or lack of consent for certain communication and have the architecture support those desires."


"The research group will investigate the feasibility of: (1) a single architecture that supports this and (2) a framework that allows different systems to be plugged in to provide different pieces of the solution."

What the consent framework tries to do is to introduce this notion in a standard way with protocols and formats, that can be carried over all anti-spam tools. But I think Jonathan has expressed this in much better way than me :)

I believe another goal is for additional components to be added to the framework as and when necessary, and therefore the system will be governed by some extensible protocol and/or message formatting standards.


The main components of the framework might be:

- Sender identification
- Whitelist for stable sender/recipient relationships
- Monetary payment (using tokens issued by trusted authorities, eg e-stamps)
- Computational payment (generating tokens autonomously, eg hashcash)
- Trust directories (identifying which payment and/or authentication authorities are trustworthy)
- Message category labelling

The charter summarizes it into three components:

o Consent Expression Component: This involves recipients expressing a policy that gives consent or non-consent for certain types of communications o Policy Enforcement Component: This involves subsystems within the communication system that enforce the policy. o Source Tracking Component: This component provides deterrence to parties that consider violating the policy by facilitating identification and tracking of senders that violate the policy

Consent expression component interfaces with the user to specify what settings the user wants. Policy enforcement components are the anti-spam tools that actually process the mail based on those settings and input provided by source tracking components. Most of the items mentioned above would be source tracing components with the whitelist possibly being the policy enforcement component.

Sorry for being "formal" but I am following the terminology of the charter.

- BCPs for effective recipient filtering based on above facilities
- BCPs for senders (of various categories) for efficient use of above facilities

BCPs are basically the policy documents to make sure that the framework is used properly - kind of like manuals.

Based on the above, it might be a good idea to split my own "E-mail Authentication" paper into two parts, one dealing with the authentication itself, and one dealing with establishing the trustworthiness of the MAA (Mail Authentication Agent). Then both would fit neatly into positions in the above list, along with other people's hashcash, stamp authority, labelling, and whitelist schemes.

With any luck, that should make things a heap clearer for everyone (myself included), unless of course Yakov is going to point out how incorrect I am. :-)

Jonathan - your explanation has been extremely heplful. As a matter of fact, it seems that I will need additional help rewriting the framework document, specifically on how to rewrite it so "normal" humans can understand it :) If you wish to help with the writing and the editing, please contact me.


Asrg mailing list