4d. Consent Framework (was Re: [Asrg] 3. Requirements - Consent Framework)
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
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
- 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
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
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