I have been thinking about explicit consent models and representations.
The one place that I think is crying out for explicit machine-verifiable
consent is opt-in and opt-out. Because current practice is so free-form
and unconstrained, there is a (growing) grey area of deniability where
even well-meaning mailers make it too hard to opt out, are too tempted to
share their opted-in information.
As I composed this note, I noticed that it touches on work item 5.b.:
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
HOWEVER, I'm thinking larger: codify both opt-in and opt-out practice to
(1) make consent creation explicit,
(2) make opt-out uniform and unequivocal,
(3) reduce the inventives to share indiscrimately, by making it obvious
who shared what.
Here is a minimal consent model, that happens to map cleanly onto current
"best practice" confirmed opt-in, while extending it in desirable ways.
Automated support at the MUA is not required (but is a desirable outcome).
a. Consent means that a proposal has been presented and accepted.
b. Initial email contact is not really known to be consented to, but
recipients can help senders through their filters by supplying
a proto-token as a free pass through incoming filters.
c. A consent token (representing a security association) should contain
opaque data from both proposed sender and accepting recipient.
Both ends have the opportunity to encode information for future reference.
d. The handshake between sender and receiver also offers the opportunity
to generate a shared secret (e.g. via Diffie-Hellman protocol), which
may be useful for HMAC or other purposes.
e. Every message should provide the consent token, AND annotate it with
URIs (at least mailto, optionally other methods) for (i) unequivocally
revoking consent [no dialogs, are-you-sures, checkboxes, etc] and
(ii) examining the sender's current understanding of what is consented
to.
f. A DSN-like structured representation of proposal text may be a good idea.
g. Potentially automated management of all those emailed passwords
(initial password and output of "forgot-your-password?" resets) should
probably be included, as it is a common feature of email-based
authentication.
This would be attractive to legitimate list owners, as a (standardized
non-proprietary) legitimizing technology to avoid overzealous filters.
It is not hard to implement, is not different in principal from the numerous
implementations already in place, and confirmed opt-in sofwtare could adopt
as a "small matter of programming".
This is an end-to-end idea (tokens contain opaque data), but there are
opportunities for delegating processing, by sharing some information with
MSAs/MTAs. (E.g. recipients share information with MTAs too, and embed
MTA-useful information in what the sender thinks is opaque data). That's
similar to the HMAC Message-ID ideas already succinctly summarized by Phillip
Hallam-Baker and others.
It does not require any third-parties, trusted or otherwise.
I have much more specific ideas, and after hearing some feedback will decide
whether to write this up more formally myself or in a small offline group.
Of course, if someone says it's not worthwhile, I guess that'll be it ;-}.
Keep those cards and letters coming.
Liudvikas Bukys
bukys(_at_)cs(_dot_)rochester(_dot_)edu
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg