RE: [Asrg] 4. Consent Framework - General

[gep2@terabites.com]

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

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.

>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

Good.

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

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

>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 :-)

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.  :-)

>> 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?

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.

> ...8<...
>
>> > Every one of the current customers knows that sales@thecompany.com 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.

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)

>Sorry to raid your ideas Gordon, but these are good suggestions
>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.



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg