Subject: RE: [Asrg] 4. Consent Framework - General

From: Andrew Akehurst <[email-masked]>
Date: Tue, 26 Aug 2003 21:48:06 +0100 (BST)

Quoting [email-masked]:

>> As part of the work on consent frameworks, is there a proposal
>> somewhere to allow a user or delegated administrator) to see the
>> consents that s/he has in place? 

> The process I proposed involves a normal flat file file, editable
> locally by the  recipient, that allows them to have a complete local
> copy showing all their granted permissions and (likewise) restrictions.
> That could be simply uploaded to the ISP or domain provider, should
> the filtering be done there rather than by a local application running
> atthe user's own site.

It should be the case that, whatever syntax is used to express and
exchange consent, the user should be able to override their entire
policy at any time: to cancel any previous policy and issue a new
one to replace it.

This suggests two requirements for any protocol for passing on consent
policies:

 (1) A "consent sharing protocol" must allow a reciever to replace
     their entire consent policy when they require

... and to prevent abuse of (1):

 (2) A "consent sharing protocol" must only allow a consent policy 
     to be replaced by the "owner" of that policy. This implies a
     need for some form of authentication so that spammers couldn't
     arbitrarily replace policies on the behalf of end-users.

Common sense of course, but I've not seen these stated thus far.

Also I don't recall seeing anyone giving a name to such protocols.
I'd suggest that, to be consistent with section 2.5 of the consent
framework document, we refer to these as "Consent Sharing Protocols"
(or CSPs for the lazy :-)

> Normally, they could simply upload the complete file to their ISP,
> whether by FTP or via an E-mail attachment or even perhaps through
> a Web site upload link or something.  

This is something which a CSP would address. Until we have one we
can leave the details slightly vague.

I think there were some people around here who were interested in
the CSP area. Danny?

 ...8<...

> > Every one of the current customers knows that [email-masked] is
> the way to get in touch when they want to buy things from us, so the
> email address is itself, a thing of value and an asset that was valued
> in the asset purchase agreement.
> 
> Sure, and there's no particular reason to have to abandon it.  Again,
> I'd simply set that incoming E-mail address to strip HTML-
> alternative attachments (indeed, probably attachments of ALL kinds). 
> If there is (for whatever bizarre reason) someone you want or need 
> to get attachments or HTML from to that address, you can list those
> approved senders with those specific appropriate permissions.

This is another type of test that would form a useful part of a CPDL.

> Yup, for example.  And even if they DO come across your wire, you 
> ought to be able to still trash them immediately under the 
> specifications of your permissions list, without ever seeing them.

This is akin to the "discard" Sieve action I mentioned in a previous
message.

Sorry to raid your ideas Gordon, but these are good suggestions
which could go into the melting pot for a standard CPDL. :-)

Andrew

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 27 Aug 2003 00:19:46 -0500

>policy at any time: to cancel any previous policy and issue a new

Yes, and I think it is a good idea from a reliability standpoint to ENCOURAGE 
that it in fact be done that [all-at-once] way... it removes a lot of problems 
that happen with 'incremental' updates.  It also means that there will be at 
least two copies, stored separately, with their permissions entirely expressed.

>     their entire consent policy when they require

Good.

>.. and to prevent abuse of (1):
>

Also good.

>Common sense of course, but I've not seen these stated thus far.

Excellent point.  This shouldn't be left to interpretation, or just 'common 
sense'.

>(or CSPs for the lazy :-)

I don't think that "sharing" is as much the key aspect as it is that these 
things are set by the RECIPIENT to control access permissions (on a 
per-sender-basis) to THEIR (recipient's) E-mail inbox.

Keywords then might include things like E-Mail, Access, Recipient, Addressee, 
Permissions, List.... let's see, that so far would give EARAPL, but maybe I'd 
better leave acronym construction to somebody else.  :-)

>I think there were some people around here who were interested in

Personally, I think what's most important here is that we come up with a good, 
simple, intuitive model which users (even) are comfortable manipulating.  I'd 
not like to see something which is inscrutable and obscure (and I'd hold up the 
DNS system as a bad example).  Efficient and workable, it may be... but damned 
difficult for anybody other than an "accomplished wizard" to understand and 
manipulate successfully, it seems.

>This is akin to the "discard" Sieve action I mentioned in a previous

Yes.  For example, I know that I get consistent E-mails from incredibly annoying 
and persistent spammers, who just won't leave me alone.  My incoming mail 
filtering system now dumps their crap straight into the "spam" junkbin (at least 
unless it finds something else there which indicates that I *might* want to give 
it another look, first... just in case)

>which could go into the melting pot for a standard CPDL. :-)

Thanks for the nice compliment!!  That's what I'm here for... to try to help 
offer my ideas and suggestions which hopefully will help us to at least REDUCE 
this huge and very annoying problem.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.

---

From: [email-masked]
Date: Wed, 27 Aug 2003 01:49:40 -0500

On Tue, 26 Aug 2003, Yakov Shafranovich <[email-masked]> wrote:
>At 04:48 PM 8/26/2003, Andrew Akehurst wrote:
>Who would like to participate and/or perhaps coordinate efforts in the 
>consent framework and consent protocols area?

I wouldn't mind taking that on, at least on a provisional basis. 

As for "protocols", I would hope that existing protocols will be adequate... 
Web, FTP, SMTP, POP.... I don't see any compelling reason to change existing 
subsystems there.

Any HIGHER level protocols that we might need ought to be able to be built, I'd 
think, on top of those existing standards.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 26 Aug 2003 23:27:31 -0400

Yakov