Subject: Re: [Simple] <except-domain> element issue for common policy

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Jun 2005 10:20:36 -0700

Hi Jonathan,

For some bizarre reason, both copies of this just now turned up in my mail box;
I apologize for the long delay in replying.  If there are other messages you
have out to me for which you're expecting a reply, please re-send.

At 12:13 PM -0400 5/25/05, Jonathan Rosenberg wrote:
>A question inline.
>
>Ted Hardie wrote:
>
>>that the automation of the disposition decision does the same job; I can
>>set up a process (note, not a *rule*) that moves things out of (pending) on
>>my behalf.  That process can use whatever heuristics I describe and they
>>can be lots more granular or clever than the <except-domain> can be
>>(e.g. remove requests from (pending) when there are more than N requests
>>with the same username substring within Y seconds).  That process
>>can also be me, the human, when I don't care to automate anything.
>
>I'm not sure I understand the difference between a process that 
>moves things out of pending on my behalf, where presumably that 
>process places them into "rejected" if they are from select domains, 
>and a rule that works in the same way.

There are a couple of things that I was trying to get at here.  One 
of the issues
that drove geopriv to the additive permissions only point of view was that
you didn't necessarily know what order permissions would be granted in
(especially where some are incorporated from external sources).  That means
the processing model for an additive/subtractive model requires all of
the rules to be present and somehow sorted correctly to get to the intended
state.  If you can't resolve an external reference in that case you either
get nothing (because you're very conservative) or you reveal to much (because
you're insufficiently paranoid). In going to an additive permissions model,
you know that whatever permissions have been granted up to a specific
point are intended and that you are being at least as conservative as
was intended.  You also are free to process the directives in any order.

Except clauses that are clearly tied to specific directives are better
than all-out negative permissions, but they can remain problematic
in their interaction with user expectations.  If I say "Grant anyone
access to my timezone, except Hisham" and also say "Grant any
wg chair in APPs access to my full location", Hisham will get my
time zone--but this may not be what a user expects, especially
if the user expectation is driven by a sense of "override" and
wrote the "except Hisham" after the first rule was in place.

For a process model, all of the additive rules are done first
before a process kicks in--this means that you can guarantee an evaluation
order-- all the rules and then later the processes (which I should probably
call something other than "process").  Personally, I think that helps,
especially if the rules are constructed so as to put those which
require post-rule evaluation into what are essentially pending
states (as this leaves the "you are being at least as conservative
as intended" in place).  A human can do the post-rule evaluation,
or it can be done by a process/agent/heuristic engine of whatever
complexity is appropriate.

That's the other main point--I believe that the "grant any, except
domain" is so close to useless that it is not worth it; it is trivially
easy to mint identities that escape this clause.  To get to something
that actually successfully excluded someone here, I think you'd
eventually need something of close to arbitrary complexity, and
that this does not belong in the rules language "Anyone may know my timezone
except those whose identities are associated with domains that have been
recently minted, are in this list, or were paid for by credit cards
traceable to "Hisham Khartabil" or were paid for in ways that are
not traceable." *might* succeed in keeping Hisham from knowing
what timezone I'm in.  But even then, he has only to get a friend
to loan him a cc to get past it.

			regards,
				Ted

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