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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Jul 2005 16:46:42 -0400

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

There is one substantive change to the model, I think. Previously in the GEOPRIV work, we had the following design goal: if an external ruleset (one included in the PIDF-LO object by reference) could not be accessed, then the worst thing that could happen is the policies would be more restrictive than they need to be.

If a local ruleset has a rule that says everyone can have access to element Y except Alice, and an external ruleset that says everyone can have access to element Y except Carol... then it would seem that if the external ruleset cannot be acquired by the policy implementer, this results is a less restrictive policy.

For the record, and as I said at the last SIMPLE meeting, I agree with Ted that the efficacy of negative permissions in this sort of system is very limited, and that policies along these lines are not likely to yield useful protections for a presentity.

Jon Peterson
NeuStar, Inc.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Jul 2005 20:40:17 -0400

> There is one substantive change to the model, I think. Previously in
> the GEOPRIV work, we had the following design goal: if an external
> ruleset (one included in the PIDF-LO object by reference) could not
> be accessed, then the worst thing that could happen is the policies
> would be more restrictive than they need to be.
> 
> If a local ruleset has a rule that says everyone can have access to
> element Y except Alice, and an external ruleset that says everyone
> can have access to element Y except Carol... then it would seem that
> if the external ruleset cannot be acquired by the policy implementer,
> this results is a less restrictive policy.

I'm not sure this is true, but maybe we're talking about two different 
cases. Let's take your example:

(R1) Anybody except Alice can access Y
(R2) Anybody except Carol can access Y

For now, assume that R1 and R2 are accessible.

By the standard rules, permissions are *additive*, thus, by R1, Carol 
can access Y. (Carol matches R1 and accumulates all the permissions that 
R1 grants.) Similarly, Alice can also access by virtue by R2. Thus, the 
matching constraints don't restrict any access. This is not a new 
problem, even without these matching constraints. [If you grant Bob very 
narrow right but Bob is also part of a domain match with "better" 
access, Bob will get the domain rights.]

If (R1) is inaccessible, things work as expected: Carol can no longer 
see Y, even though she could before.

Thus, the matching constraints don't impair the additivity and privacy 
safety, but they do mean that exceptions have to be in every 
domain-based rule to be meaningful, i.e.,

(R1') Anybody except Alice,Carol can access Y

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Jul 2005 20:58:30 -0400

inline.

> access, Bob will get the domain rights.]

I agree with Henning here. The problem is exactly the issue that Ted is 
concerned about; that folks will assume that if they have a rule that 
says "give Y to everyone except Alice", that this revocation of 
permissions from Alice occurs after the grants have all been accumulated.

That experience can still be simulated with privacy safety if a web 
application keeps track of set of blocked users and adds them as an 
exception to each rule. As such, you wouldn't end up with rules like R1 
and R2 above, you'd probably have:

R1: grant Y to everyone except Alice and Carol
R2: grant Z to everyone except Alice and Carol

and this continues to have the desired property - if R1 cannot be 
fetched, less information is given out, not more.

-Jonathan R.

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