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

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Nov 2003 13:46:02 -0500

[email-masked] wrote:
> Hi,
> 
> I've followed this thread from SIMPLE WG point of view. I agree
> mostly with what Jonathan is writing below. I summarize my main
> points here: 

- In many "domains" (run by corporates, ISPs, operators)
> it is not possible to ad hoc create new identities, and in any case
> authentication is always required when an identity is used. This
> means that getting around "black lists" is not as trivial as in
> e-mail. 

As I pointed out before, authentication does not guarantee uniqueness or 
difficulty in acquiring new identities. In any event, it's pure 
speculation at this point where and how easy it will be for users to 
acquire new identities, so there's probably not much point in continuing 
that particular thread.

- I agree that the usefulness of exceptions depends on how
> "group" information is structured. In many cases, especially in
> corporates, people use groups/lists that they themselves are not able
> to manage (and in some cases not even see their content). This
> happens with e-mail, calendars etc. I believe similar shared groups
> to be useful for hobby-clubs, families etc. too. In those cases it is
> important to be able to disclude some members by doing exceptions,
> e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list
> EXCEPT my boss". I understood Ted's point that UI and protocol can be
> separated, but I share Jonathan's concern below. 

These types of groups are rather different from identities as there is 
no way for a user to log in as 'member of bowling team'. Thus, I think 
it would be confusing to treat them just like another identifier.

Whether to allow matching on group membership is another matter, but it 
would likely be a separate 'column'.

The problem with groups is that there is no unique way to check for 
group membership in general. There is also no global namespace for them, 
so that there is no guarantee that two servers that see a rule set 
reference will make the same determination. (We obviously have email 
lists and maybe even SIP replication lists and buddy lists, but they are 
unresolvable outside a very narrow context.)

- I didn't quite get
> why we couldn't define the <applies-to> and <exception> so that if
> the <exception> part for some reason (external reference etc.) could
> not be properly resolved, the whole <applies-to> would result in
> empty set, i.e. at least no leaks would be introduced. - Also I did't
> get what was wrong with Ted's proposal to define a separate
> <restricted-applies-to> element. To me that would be OK as well.
> 

I don't think we're all that far apart.

Since assumptions are rather important in this whole discussion, let me 
state my current view of what can and cannot be done.

- Each rule must have the exceptions atomically encoded in the same 
rule, i.e., the rule cannot refer to exceptions elsewhere. The 
exceptions simply restrict the cases where the rule matches. In other 
words, exceptions within rule A do not influence the behavior of rule B.

- Some systems will have multiple rulesets, e.g., one stored at the 
server and one carried by the location update. In general, we need to be 
sure that it is clear what happens in cases such as

Rule 1:  example.com except [email-masked]
Rule 2:  example.com except [email-masked]

In the additive model, Bob will get the permissions in Rule 1. This may 
or may not be what users want. (If people are happy with that, I think 
we can make that work.)

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Nov 2003 00:59:41 -0500

Henning Schulzrinne wrote:

> unresolvable outside a very narrow context.)

I agree that groups are a separate issue.

However, in xcap, it currently does allow for things like "applies to 
everyone on golf-list, but Joe". It does that by having each group 
defined by an xcap resource (i.e., an http URI) that can be used to 
fetch the group list. Then, membership in the group is determined by 
authenticating as one of the identities in that group.

If you can't fetch the list, the permission isnt granted, and thus its 
privacy safe.

If, for some reason, a user specifies a rule based on a list in 
another domain, with members in other domains, the server can't 
authenticate those users, and thus permissions are not granted, and 
thus its privacy safe.

You *would* have problems if you could have an exception defined by an 
external list, but I agree we shouldnt do that.

So, given this design and assumptions, I dont see a problem with 
groups per se. There is a scope question, but I dont see a technical 
problem.

> words, exceptions within rule A do not influence the behavior of rule B.

Agreed.

> or may not be what users want. (If people are happy with that, I think 

I think that is fine. It is consistent with the exception semantics I 
have been arguing for.

The main thing is that the semantics are clear. How these things are 
presented to users is something else.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Sun, 9 Nov 2003 20:13:56 +0200

Hi,

I've followed this thread from SIMPLE WG point of view. I agree mostly with what Jonathan is writing below. I summarize my main points here:
- In many "domains" (run by corporates, ISPs, operators) it is not possible to ad hoc create new identities, and in any case authentication is always required when an identity is used. This means that getting around "black lists" is not as trivial as in e-mail. 
- I agree that the usefulness of exceptions depends on how "group" information is structured. In many cases, especially in corporates, people use groups/lists that they themselves are not able to manage (and in some cases not even see their content). This happens with e-mail, calendars etc. I believe similar shared groups to be useful for hobby-clubs, families etc. too. In those cases it is important to be able to disclude some members by doing exceptions, e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list EXCEPT my boss". I understood Ted's point that UI and protocol can be separated, but I share Jonathan's concern below.
- I didn't quite get why we couldn't define the <applies-to> and <exception> so that if the <exception> part for some reason (external reference etc.) could not be properly resolved, the whole <applies-to> would result in empty set, i.e. at least no leaks would be introduced.
- Also I did't get what was wrong with Ted's proposal to define a separate <restricted-applies-to> element. To me that would be OK as well.

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 07 November, 2003 22:22
> To: Henning Schulzrinne
> Cc: Andrew Newton; Naoko ITO; Simple WG; [email-masked]
> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> inline.
> 
> >>> I don't understand why the except clause in each permission
> >>> statement should be dismissed while the separate exception list
> >>> model can be supported.
> > 
> > 
> > The exception list is restricted in its functionality to avoid the
> >  privacy problems caused by exception entries. Mixing the two means
> > that both list types would need to be restricted as described.
> > 
> > Also, having unbounded except lists makes processing more
> > complicated since the simple row model no longer applies (it's no
> > longer a relational table).
> 
> I share Ito-san's confusion here. Assuming the same kind of
> restrictions you have asked for - no external references, no
> wildcards, no domain-scopes, I dont see the difference between:
> 
> <applies-to>
>    <domain>example.com</domain>
>    <except>
>      <uri>[email-masked]</uri>
>    </except>
> </applies-to>
> 
> and:
> 
> <applies-to>
>    <domain>example.com</domain>
> </applies-to>
> 
> <exception-list>
>    <uri>[email-masked]</uri>
> </exception-list>
> 
> THe differences seem merely syntactic, but maybe I am missing
> something here.
> 
> Henning also wrote:
> > Blacklists were popular for spam-protection early on, but I think
> > everyone has realized by now that they are close to useless. I'd
> > hate to create a complicated, brittle, difficult-to-predict system
> > just to find out a year later that this expensive feature turned
> > out to be mostly an empty promise, in terms of increasing user
> > privacy.
> 
> There are some serious differences here with the email spam case. 
> Firstly, the systems we are talking about require authentication, 
> which is absent in email. Secondly, and perhaps most 
> importantly, I am 
> not interested in rules like "allow anyone in the world but 
> [email-masked]", as I agree this is silly. We are talking 
> about rules 
> like "allow only people from example.com EXCEPT 
> [email-masked]". That 
> is, I expect these systems to require a user to explicitly grant a 
> permission, but an extremely common case, I think, will be to 
> grant it 
> by indicating a domain with a set of exceptions.
> 
> Ted wrote:
> > To take up your point on implementation, I note that
> > folks do seem to be assuming a connection between
> > the UI and the protocol behavior.  I can easily see
> > a UI saying "Grant all buddies civil geolocation data
> > at City level, except $ex-spouse, who should get
> > my timezone" and translating that as a grant of
> > timezone to all buddies and a second grant of
> > City to each of those that isn't the ex-spouse.  From
> > the user point of view, it's an "except", where from the
> > protocol point of view it is additive permissions.
> > 
> > There is no question that there are engineering trade-offs here.
> > You gain simplicity and have an easy method to
> > ensure maximal privacy, but you may get increased
> > object size and you may need to structure group data
> > in ways that ensure it fits this model reasonably
> > efficiently.  Neither choice is perfect, but this one
> > does have some very useful characteristics for a
> > large number of GeoPriv cases.  There may be other
> > usage patterns in other uses of XCAP that mean
> > we can't have a perfect fit, but if we can keep that
> > split to a minimum, I think it's worth it.
> 
> 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.
> 
> 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.
> 
> -Jonathan R.
> 
> 
> -- 
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Nov 2003 14:46:07 -0500

> If you can't fetch the list, the permission isnt granted, and thus its 

Clearly, fetching group lists adds significant complexity: expiration 
(presumably you don't want to fetch it every time) and the inability, 
without significant overhead, to implement a permission system using any 
reasonably efficient query mechanism.

> 
> If, for some reason, a user specifies a rule based on a list in another 
> domain, with members in other domains, the server can't authenticate 
> those users, and thus permissions are not granted, and thus its privacy 
> safe.
> 
> So, given this design and assumptions, I dont see a problem with groups 
> per se. There is a scope question, but I dont see a technical problem.

It just makes efficient implementation difficult to impossible.

> presented to users is something else.

If nothing else, the discussion has hopefully clarified the semantics a 
bit beyond what's in the drafts and meeting minutes.

I guess at this point, if anybody wants exceptions beyond that, they 
should speak up.

I would also like to get consensus to rule out random wildcard matching 
and, less importantly, domain exceptions. Thus,

applies-to: foo.*.example.com

and

applies-to: example.com
except cs.example.com

seem far less useful and add significant complexity.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Nov 2003 16:52:15 -0500

> reasonably efficient query mechanism.

I think the required functionality should drive the protocol choices 
and implementation, not the other way around.

That said, it is certainly possible to have efficient implementations 
of policies that involve an external fetch of a group. This is not a 
radically new concept. You can do a really good job at it when the 
lists are in the same administrative domain as the location server, as 
then you can in fact do various kinds of cached optimizations.

> It just makes efficient implementation difficult to impossible.

As I mentioned above, this is not a radically new capability. Policies 
based on external lists are not a new concept.

That said, I would be willing to buy that this is out of scope for the 
initial revision of the specs.

> seem far less useful and add significant complexity.

Agreed these are out of scope.

-Jonathan R.