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

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 
(http://www.irtf.org/charters/asrg.html):
"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."
and

"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.
Correct.

> 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.
Yakov


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg