Re: [Geopriv] RE: [Simple] Changes in xcap-auth

From: Jonathan Rosenberg ^lt;>
Date: Sat Nov 08 2003 - 00:46:52 EST

inline. wrote:

> At 3:21 PM -0500 11/07/2003, Jonathan Rosenberg wrote:
>> To summarize (correct me if I am wrong), I think your suggestion
>> was that exceptions can be handled by expanding the lists
>> associated with the domain. As such, even though the user sees an
>> exception rule in the UI, the underlying system pushes a
>> permission with everyone in it.
> I'm saying that's the protocol's view of the permission and the
> structure in which they're encoded and sent. How the underlying
> system store the permissions is, I think, a local optimization.

Agreed. Thats different from what I was saying above, which is that
the way a UI shows permissions, and the protocol's views of a
permission, can also be different.

>> My concern is that I believe this will be very difficult to
>> manage. It requires the users to have access to the set of users
>> in the domain from which the exceptions are being specified. That
>> list is undoubtedly dynamic, and potentially pretty large. When a
>> new employee joins the company, everyone would have to update
>> their permissiosn (or have their agents do it automatically
>> somehow), and similarly when someone leaves. The result will be
>> odd behavior for users, where people that a user believes to have
>> permission, actually doesnt.
> This gets one of the points I was trying to make earlier; the
> difficulty here depends on how the group data is structured. Let's
> assume that we have a very wide, flat identifier, like
> ""; granting to domain "" with an
> except on the basis of that identifier would be tough.

Why? I don't understand. This identifier is not flat - it has a clear
user and domain part, which are separable.

> If the
> identifiers were not email-like, though, but based on group
> identifiers that were more distributed, then granting them is
> slightly more tedious, but the except clauses become easier--as it
> is a flat grant to groups 1-100, and increased grant to groups 1-9
> and 11-100, an increased grant to member 1,3,4 of group 10, and a
> failure to grant to member 2 of group 10. This does mean that
> adding to member 5 to group 10 creates a synchronization problem.
> There are ways around that, and they are tedious and potentially
> flakey.
> You don't need to use them, though, unless you are doing exception
> based processing. If this is very common, we may need to change
> our view of what is critical. In the short term, I believe that
> getting to the point where the user can grant permissions on a
> "domain" (not necessarily DNS label) is considerably beyond where
> we are today, and I think a lot of the real need in GeoPriv is
> handled by the explicit grant case.

For consumer applications, I would be inclined to agree. I don't see
this as practical at all for any enterprise applications of geoloc.
That is, applications where a wireless provider is providing an
application (such as a sales force automation app) to an enterprise.

> Doing exception based processing might be possible, but it seems to
> put a burden on the processor that requires it to ensure it has
> processed *all rules* before it can proceed (perhaps a better way
> to put this is that it has processed all "includes" before it can
> proceed). If it does not process all rules, there seems to be a
> not trivial risk that (a.k.a. Member 2 of group
> 10) gets data that the privacy policy doesn't allow. That's simple
> not okay in the GeoPriv view of the world.

In the exception model I am talking about, this is not the case. It is
not true that lack of processing of a rule can leak data that
shouldn't be leaked. Hopefully my response to Henning clarifies this.
I think the disconnect is that I am NOT proposing pure exceptions. I
am merely using exceptions as a short hand to avoid enumerating long
lists of people to whom a rule applies. That is, an applies-to
statement has a positive component (the domain to which the rule
applies), and a set of exceptions that remove users from THAT domain.
THis is functionally equivalent to enumerating all users in the domain
except the ones I don't like, which is clearly an additive permission.

-Jonathan R.

Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft                     FAX:   (973) 952-5050                      PHONE: (973) 952-5000
Geopriv mailing list
Received on Sat Nov 8 00:48:30 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST