[Asrg] 4. Survey of Solutions - Consent Model (updated)

At 01:50 PM 7/4/2003 -0400, Bob Wyman wrote:

> Yakov Shafranovich wrote:
> >I wrote up an document on the consent model
>         I think it would be good to strip from the document the general
> discussion of the spam problem and focus on the technical framework.
> .....
I have posted an updated version of the consent framework online 
(http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html), and 
here. I rewrote the document in-line with Bob's suggestions, and 
restructured it similar to RFC 2778. I also added a history section.
In general I think that a few things are needed. First of all, it would be 
very useful to take a look at RFC 2778 which defines a model for instant 
messaging and base our document on a similar structure. Second of all, this 
document is too much for one person to write, and we need a small committee 
of volunteers to work on it, so anyone who wants to do that please step 
forward. Also, perhaps we should reformat it as an Internet draft?
---------------------------snip--------------------------
Consent Framework for Fighting Spam v0.0.2

Written by Yakov Shafranovich <research at solidmatrix dot com> , last 
updated on July 6th, 2003.
Copyright © 2003 The Internet Society (ISOC). This document is subject to 
copyright provisions described in RFC 2026. This is a working document of 
the Anti-Spam Research Group (ASRG) of the Internet Research Task Force 
(IRTF) and may change frequently. The most current version of this document 
may be viewed at 
(www.solidmatrix.com/research/asrg/asrg-consent-framework.html)
Abstract

This document defines an abstract framework for consent-based communication 
systems. It defines what consent is, how consent is managed, different 
components of consent systems, services provided by these components and 
terminology used in consent systems. The goal of this document is to 
provide a framework for developing, evaluating, understanding and comparing 
anti-spam tools.
1. Introduction.

1.1. Purpose.

The current email system allows Internet users to exchange messages quickly 
and reliably. However in the recent years the problem of unwanted email 
messages, loosely referred to as "spam", has increased in scale, growth, 
and effect; growing to account for a large percentage of the mail volume on 
the Internet. This unwanted traffic stands to affect local networks, the 
infrastructure, and the way that people use email.
Due to the large impact of the spam problem on the Internet, many companies 
and individuals have been developing anti-spam tools for the past few 
years. In order to develop, evaluate, understand and compare various 
anti-spam tools and proposals, we believe that it is essential to first 
develop an abstract model into which these tools and proposals would fit. 
In [CHARTER] the problem of "unwanted email messages" is recast as a 
problem of "consent-based communication" and the model of anti-spam 
response is recast as a "consent model". According to [CHARTER] 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 various anti-spam tools in use today and being proposed 
are geared towards that task of allowing the individuals and organization 
to express their consent. We believe that a single consent framework would 
greatly benefit the Internet community by allowing an overall view of 
anti-spam solutions, facilitating easier evaluation and discussion of 
individual proposals and allowing for development of interoperability 
protocols between various anti-spam tools.
This model does not concern itself with defining what spam is ? one 
person's spam message may be another's freedom of speech. Thus, we only 
seek to define a consent framework ? everything else is left to the 
implementors and the users themselves.
1.2. Document Layout.

The model consists of various components, descriptions of services provided 
by these components and a vocabulary facilitating discussion. In this 
document, each element of the model appears in upper case (e.g., CONSENT 
POLICY). No term in lower case or mixed case is intended to be a term of 
the model. The first part of this document is intended as an overview of 
the model. The second part of the document is the actual definition of the 
model, with terms presented in alphabetical order for ease of reference. 
The overview is intended to be helpful but is not definitive; it may 
contain inadvertent differences from the definitions in the model. For any 
such difference, the definition(s) in the model are taken to be correct, 
rather than the explanation(s) in the overview.
2. Overview.

The idea for consent model within the ASRG was first proposed in [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."
Users, both individuals and organizations, express their wishes as to what 
kind of email they want to receive. This is referred to as CONSENT. On the 
other hand, LACK OF CONSENT is when there is no prior CONSENT expressed by 
the user or when the user revoked prior CONSENT. Aside from manually 
expressing CONSENT by moving or deleting messages, RECEIVERS can also 
formulate various rules under which the software processing their email may 
assume CONSENT or LACK OF CONSENT, and grant or revoke CONSENT on behalf of 
the RECEIVER. CONSENT may not exist in advance of the initial email 
communications, it may be granted or revoked automatically based on the 
CONSENT POLICY. These sets of rules are called CONSENT RULES and a specific 
compilation of those rules related to a specific RECEIVER is called a 
CONSENT POLICY. CONSENT POLICIES have SCOPE which are rules as to when and 
to whom the CONSENT POLICY applies, and with whom it may be shared.
Based on [CHARTER] the consent framework consists of three types of 
components: CONSENT EXPRESSION COMPONENT, POLICY ENFORCEMENT COMPONENT and 
SOURCE TRACKING COMPONENT. CONSENT EXPRESSION COMPONENTS let the RECEIVER 
formulate CONSENT POLICIES. POLICY ENFORCEMENT COMPONENTS enforce CONSENT 
POLICIES on incoming email. SOURCE TRACKING COMPONENTS identify and track 
SENDERS that violate the CONSENT POLICIES. They may also provide data about 
the the SENDERS which may be used by the POLICY ENFORCEMENT COMPONENTS.
In the consent model we have a SENDER and RECEIVER of email that 
communicate with each other. The messages between the SENDER and the 
RECEIVER are processed and transfered by their AGENTS and addressed from 
the email address of the SENDER to the email address of the RECEIVER. The 
messages are transferred between the SENDER and the RECEIVER via a slew of 
mail transfer protocols such as SMTP. The RECEIVER expresses his CONSENT 
POLICY via the CONSENT EXPRESSION COMPONENT. This CONSENT POLICY is made 
available to the POLICY ENFORCEMENT COMPONENT, which will enforce it for 
incoming messages. The SOURCE TRACKING COMPONENT may also provide 
additional information about the SENDER which will be taken into account 
when enforcing the CONSENT POLICY. Aside from that the SOURCE TRACKING 
COMPONENT is also used to track down violators of the CONSENT POLICY so 
action may be taken against them.
2.1. CONSENT POLICIES.

RECEIVERS can also formulate various rules under which the software 
processing their email may assume CONSENT or LACK OF CONSENT, and grant or 
revoke CONSENT on behalf of the user. These sets of rules are called 
CONSENT RULES and a specific compilation of those rules related to a 
specific RECEIVER is called a CONSENT POLICY. CONSENT POLICIES have SCOPE 
consisting of SCOPE RULES as to when and to whom the CONSENT POLICY 
applies, and with whom, when and how it may be shared.
Specific CONSENT RULES may also rely on CONSENT TOKENS which are pieces of 
data exchanged between the RECEIVER and the SENDER, which will grant 
consent to the SENDER in accordance with the CONSENT POLICY of the 
RECEIVER. Examples of such tokens are C/R messages, hash cash tokens, 
e-postage, digital certificates, trusted sender seals (such as Habeas and 
BondedSender), etc. Upon recipient of a valid CONSENT TOKEN, the POLICY 
ENFORCEMENT COMPONENT will grant CONSENT on behalf of the RECEIVER to the 
SENDER to a period of time defined by the RECEIVER's CONSENT POLICY.
A CONSENT POLICY of a specific RECEIVER does not merely reflect his 
choices. It is also based on the capabilities and settings of the CONSENT 
EXPRESSION COMPONENT used, the capabilities and settings of the POLICY 
ENFORCEMENT COMPONENT used, and by the SCOPE of the CONSENT POLICY of 
organization or ISP to which the RECEIVER belongs. The specific 
implementation being used by the RECEIVER, or his organization/ISP might 
support only specific types of CONSENT RULES which will be used in creation 
of the policy. CONSENT POLICIES from multiple RECEIVERS maybe combined to 
create a combined CONSENT POLICY for the entire organization or ISP. The 
organization or ISP may also impose its CONSENT POLICY on the RECEIVERS 
within its domain. Multiple ISPs and organizations may also shared CONSENT 
POLICIES in order to allow for interoperability between themselves. 
Standard CONSENT POLICIES may also be defined as Best Current Practices 
(BCP) documents.
Portions of the CONSENT POLICY may be communicated to the SENDER according 
to the SCOPE of the policy either by the CONSENT EXPRESSION COMPONENT or 
the POLICY ENFORCEMENT COMPONENT. When communicated by the CONSENT 
EXPRESSION COMPONENT, the purpose is to let SENDERS know what kind of 
CONSENT RULES they should follow in order for their email to be accepted. 
Examples of this might be when an ISP publishes a set of email policies for 
other domains which must be followed in order for the email to be received. 
When communicated by the POLICY ENFORCEMENT COMPONENT, the purpose of the 
communications will be to inform the SENDER of LACK OF CONSENT by the 
RECEIVER and to request a CONSENT TOKEN (if applicable). AGENTS 
communicating with each other may share CONSENT POLICIES to facilitate 
communications. They may also pass CONSENT TOKENS between themselves in 
order to dynamically grant or revoke consent to the RECEIVER, all according 
to the CONSENT POLICY SCOPE.
Two aspects must be kept in mind. First of all consent systems may grant or 
revoke CONSENT automatically based on the CONSENT POLICY. The CONSENT 
POLICY does not define CONSENT only, it also defines conditions for 
automatically granting and revoking CONSENT. Additionally, machines cannot 
perfectly reproduce human wishes and the CONSENT POLICY created might not 
match exactly what the end-user wants especially considering other CONSENT 
POLICIES such as the organization's and the ISP's.
2.2. CONSENT EXPRESSION COMPONENT.

This component provides abilities to the RECEIVER to define and maintain a 
set of CONSENT RULES and SCOPE RULES which form a CONSENT POLICY for that 
RECEIVER. This component also communicates with the CONSENT EXPRESSION 
COMPONENTS of the RECEIVER's organization and ISP to comply with their 
SCOPE RULES and CONSENT POLICIES and to perhaps create a combined CONSENT 
POLICY for the organization. This component also communicates the CONSENT 
POLICY to the POLICY ENFORCEMENT COMPONENT which will enforce it.
2.3. POLICY ENFORCEMENT COMPONENT.

This component processes incoming email for the RECEIVER based on his 
CONSENT POLICY as modified by the CONSENT POLICIES of the ISP and the 
organization. This component is also responsible for communicating with the 
CONSENT EXPRESSION COMPONENTS in order to allow the RECEIVERS to define and 
maintain their CONSENT POLICIES. This component may also communicate with 
the SENDER in accordance with SCOPE in order to facilitate email transfer. 
This component may also communicate with SOURCE TRACKING COMPONENTS to 
obtain information about the SENDER to be used for enforcement or to report 
violations of CONSENT POLICIES.
2.4. SOURCE TRACKING COMPONENT.

This component facilitates identification and tracking of SENDERS either in 
order to help the POLICY ENFORCEMENT COMPONENT make decisions or to deter 
violators of the CONSENT POLICY by tracking, identifying and reporting them.
2.5. Protocols.

A MAIL TRANSFER PROTOCOL is used to transfer email messages between the 
SENDER and the RECEIVER. This transfer process may involve one or more 
software AGENTS.
[Ed. more protocols needed:

1. Protocols for sharing CONSENT RULES, SCOPE RULES and CONSENT POLICIES

2. Protocols for sharing CONSENT TOKENS. ]

2.6. Formats.

[Ed. We need to define:

1. Language and format for CONSENT AND SCOPE RULES

2. Format for CONSENT POLICIES.

3. Format for CONSENT TOKENS.

]

3. Model Terminology.

AGENT ? a software tool that is representing a human user

CONSENT ? an expression of wanting to receive specific email

CONSENT EXPRESSION COMPONENT ? components that lets RECEIVERS define 
CONSENT POLICIES
CONSENT POLICY ? a set of CONSENT RULES and SCOPE rules for a specific RECEIVER

CONSENT TOKEN ? a piece of data that is used by the POLICY ENFORCEMENT 
COMPONENT to grant or revoke CONSENT based on the CONSENT POLICY
LACK OF CONSENT ? an expression of not wanting to receive specific email or 
absence of prior CONSENT
MAIL TRANSFER PROTOCOL ? a protocol used to transfer email between the 
SENDER and the RECEIVER
POLICY ENFORCEMENT COMPONENT ? a component that enforces CONSENT POLICIES 
for the RECEIVER
RECEIVER ? user receiving the email

SCOPE ? combination of SCOPE RULES defining how CONSENT POLICIES are shared

SCOPE RULES ? rules defining how CONSENT POLICIES are shared

SENDER ? user sending the email

SOURCE TRACKING COMPONENT ? components used to identify and track SENDERS 
either to help make POLICY ENFORCEMENT COMPONENT make decisions or to deter 
SENDERS from violating the CONSENT POLICY
4. Security Considerations.

[Ed. To be added]

5. Privacy Considerations.

[Ed. To be added]

6. Acknowledgments.

This document is the work of the Anti Spam Research Group (ASRG) of the 
Internet Research Task Force (IRTF).
7. References.

[CHARTER] Charter of the ASRG, current version available at 
(http://www.irtf.org/charters/asrg.html)
Appendix A ? Document History

0.0.1 / July 4th, 2003 / Initial publication

0.0.2 / July 5th, 2003 / Took out non-essential stuff, rewrote certain portions
---------------------------snip--------------------------  

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