Quoting gep2(_at_)terabites(_dot_)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.
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
sales(_at_)thecompany(_dot_)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.
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg