[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



add mine to the list of apologies for long delays in responses..

more inline.

Henning Schulzrinne wrote:

Ted Hardie wrote:

I agree that having the <except> clause for applicability within the
rule is better than the cases GeoPriv was most concerned with (it's
always processed at the same time, so the evaluation order problem
isn't salient).  It is, though, a negative permission--it's a grant
to all followed by a revoke to a limited set.   One of the issues I
expressed is that the limited set isn't useful, because of identity
minting. The other is that the except clause here forces a change to
the processing model. I'm concerned that changing the processing
model to (Grant, followed by revoke) will open us to things that will
have the problems GeoPriv wanted to avoid.


I don't quite agree with the statement of the model made above. This is
not "grant, then revoke". Rather, the exception condition restricts the
matching of the rule. Logically speaking, rule processing proceeds in
two phases:

(1) Determine if the rule matches a request (subscription, location
request, etc.)

(2) Execute the actions and grant the permissions (it's a bit more complicated, but irrelevant for this discussion).

The "all except" part only affects the matching (step 1), not the action
(step 2).

This is an important difference, as it avoids the privacy unsafety
issues that grant-then-revoke would have. Rules are binary in matching,
i.e., they either match or don't, and thus the consequences you seem to
fear cannot occur, inside or outside of the geopriv context.

I want to make the difference clear since I was also confused on this
point when this whole discussion started a year or so ago.

Thus, to make up another example that avoids the identity-minting issue,
"Apply this rule at any location except New York" would be perfectly fine.

The distinction becomes clearer if you consider hypothetically that we might allow regular expressions in the matching part. We could have something like

[^0-9]

which can be phrases as "any character except 0-9". Or, if we had a numeric matching condition, something like "x > 9 || x < 0" could just as easily be phrased as "any x except between 0 and 9". Clearly, neither of these examples are "grant/revoke" conditions.

Right. Put another way, putting an exception in the matching condition is just another way to define the set of users to whom the additive permissions apply. The only difference is that the set of people to whom they apply is potentially large, but there is no change in the model.


Ted previously wrote:
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.

This concern is valid under the assumption that users directly manipulate these rules. I dont think that this is going to be the case. I think that web applications and other things will provide nice UI for these, and present the user with decisions they can understand. An application might ask the user to define the set of watchers that are to be blocked. Separately, the user might provide lists of people to whom various information is to be granted. I think the web application would automatically add the blocked users to the exception list for every rule. This preserves the expected user experience.



I've been on the fence on this topic for a long time, but at this point I am pretty solidly in favor of supporting exceptions for users within a domain rule, and exceptions for domains within an any rule.


-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple