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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 6 Nov 2003 10:06:48 +0100

hi jonathan, 

could you describe how the domain authorization procedure works? where do
you get the domain part for the identifier. the problem we saw in the past
was that you have to understand the structure of the identifier in order for
it to work. 

ciao
hannes

btw, another small issue. the name of the authorization draft is very
misleading. there is no need to contain the name xcap in there since the
policies should actually be independent of xcap. i noticed the problem with
the names in various discussions. people automatically think that those two
belong together. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, November 04, 2003 2:06 AM
> To: Henning Schulzrinne
> Cc: Tschofenig Hannes; 'Rosen, Brian'; Simple WG; [email-masked]'
> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > [Starting clean...]
> > 
> > There are two somewhat separate issues:
> > 
> > (1) Splitting into domain and user components, i.e., we could have 
> > permissions that apply to all users in a domain and some 
> that apply to 
> > only specific users. That, by itself, does not break the 
> additive model, 
> > if specific users have at least the permissions of the 
> specific users 
> > within the domain.
> > 
> > While I don't believe that, in practice, domain-specific 
> permissions are 
> > all that useful for organizations of non-trivial size, the model of 
> > "everybody within domain gets baseline permissions, special 
> people get 
> > more" seems plausible.
> 
> In particular, this seems to be a common cases for many small to 
> medium enterprises, where "domain" is the domain of the enterprise.
> 
> 
> > (2) I share Hannes concern about making exceptions on any field, 
> > including the user or domain match. I don't see the real-world 
> > motivation for this and it complicates the conceptual 
> model. (In the 
> > geopriv interim we discussed at length as to why blacklists are 
> > generally a bad idea, even with authentication, unless you 
> can guarantee 
> > that the bad guys you want to keep out can't change their verified 
> > identity to a new one.)
> 
> I think this is a legitimate complaint for the case "accept anyone 
> EXCEPT for Joe". However, for the case "accept anyone from 
> example.com 
> EXCEPT Joe", I dont think this concern is applicable. There, 
> it is not 
> so easy for the user to change their identity to a new one. The 
> classic use case would be a company where I initially allow anyone in 
> my enterprise, but then this one bothersome employee keeps pestering 
> me for information every time I log in, and I want to put him on my 
> black list so he doesnt see my status anymore. This seems like a 
> legitimate case.
> 
> Also, another case where except clauses make sense is where I want 
> different information provided to different people. For example, 
> everyone in my company sees my cell phone status and my PC status, 
> except for that annoying Joe again, who only sees my PC.
> 
> My main point, however, is that none of my arguments above are 
> specific to presence as opposed to geopriv. If blacklists are bad for 
> geopriv, they are also bad for presence, and vice a versa.
> 
> 
> > 
> > At one point, I thought the basic design principle was that 
> we weren't 
> > done until we couldn't *remove* any features - with policies, it's 
> > always tempting to pile on more and more "could be useful 
> somewhere" 
> > items, so I think proponents of particular items should be 
> held to a 
> > fairly high standard of proof as to why a particular feature is 
> > absolutely, positively necessary for a first version. In 
> the geopriv 
> > draft, we spend some time talking about future extensions 
> and how they 
> > are privacy-safe under certain baseline assumptions. We 
> can't anticipate 
> > all the things that we might need and the things that turn 
> out to be 
> > less than useful in practice, so I'd much rather start 
> clean and small 
> > and then expand based on implementation experience. We just 
> don't have a 
> > whole lot (if any) experience with policy languages or rule 
> sets in the 
> > IETF.
> 
> I am with you on removing features, and as you can see have taken the 
> axe to xcap-auth in a pretty serious way. I am also totally in 
> agreement with the value of something being privacy-safe. I think the 
> concerns about except-clauses in the applies-to section only apply 
> when the except-clauses reference external lists. I see several 
> options there:
> 
> (1) don't allow except clauses to reference external lists at all
> 
> (2) allow them to reference lists present only on the same server
> 
> (3) AND/OR if the list cannot be obtained, then the 
> permissions in the 
> associated statement are granted to NO ONE.
> 
> 
> I believe that (1), (2,3) or (3) would make the except clause privacy 
> safe.
> 
> -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
> 
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Nov 2003 14:07:03 -0500

Tschofenig Hannes wrote:

> hi jonathan,
> 
> could you describe how the domain authorization procedure works?
> where do you get the domain part for the identifier. the problem we
> saw in the past was that you have to understand the structure of
> the identifier in order for it to work.

I'm not sure I follow. I work for dynamicsoft.com. All URIs in my 
domain are [email-masked]. I'd like a policy which allows anyone 
in dynamicsoft.com, but blocks a few irritating people, say joe and 
bob. So, I would have a policy like this:

<applies-to>
   <domain>dynamicsoft.com</domain>
   <except>
      <uri>[email-masked]</uri>
      <uri>[email-masked]</uri>
   </except>
</applies-to>

Where is the complexity here?

> 
> ciao hannes
> 
> btw, another small issue. the name of the authorization draft is
> very misleading. there is no need to contain the name xcap in there
> since the policies should actually be independent of xcap. i
> noticed the problem with the names in various discussions. people
> automatically think that those two belong together.

Yes, I realize that - others have commented similarly. I will be happy 
to split it up into pieces, wth the XML schema separately, once we 
have a better grasp of how to bring these two works together.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Nov 2003 14:07:03 -0500

<applies-to>

-Jonathan R.

---

From: [email-masked]
Date: Thu, 6 Nov 2003 14:43:28 -0800

At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote:
> not sure I follow. I work for dynamicsoft.com. All URIs in my domain are [email-masked]. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this:
>
><applies-to>

The complexity here from the GeoPriv side is really in how additive permissions are
meant to work.  In order to ensure that the privacy policy is always within the
user's tolerance, the theory has been to have a very small set of "grants" that
are then always modified by addition.  If the URI at which a specific addition
is made is not available (or the object in which it is contained is not decryptable),
then the results may be less than optimal, but there are no untoward
privacy consequences, as there can never be a "grant statement" that takes
something away.  We talked about "except" in particular at the interim meeting
and, from my memory, we had good agreement that "except" was powerful,
interesting, but conflicted enough with the core theory and the needed functionality
that it wouldn't be a phase one.

Could I suggest that we consider splitting <applies-to> into two, one of which
has except and one does not?  We could have <applies-to> and <restricted-applies-to>.
The first would be the basic grant:
 
<applies-to> <domain>example.com</domain></applies-to>

where the second would allow:

<restricted-applies-to><domain>example.com</domain>
<except><uri>[email-masked]</uri></except></restricted-applies-to>. 

I think that would enable us to overlap a lot of the xcap language between SIMPLE and
GEOPRIV, but allow GeoPriv to punt implementation of <restricted-applies-to> until
a later time when it has worked out more of the surrounding infrastructure.  It is
inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and
this looks like the most direct way to hack past the problem without losing
the basic overlap.
				regards,
					Ted Hardie

---

From: [email-masked]
Date: Thu, 6 Nov 2003 14:43:28 -0800

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Nov 2003 20:28:25 -0500

If there is consensus that we really can't avoid exceptions, I would 
suggest a variation of Ted's approach, namely to have a clear, separate 
exceptions list:

- First, consult the exceptions list. If there's a match in the 
exceptions list, there is no need to consult the second list. If the LS 
or PA can't access the exceptions list, the system delivers no 
information and fails hard for that delivery destination. The exception 
list permits no inclusions, no all-within-domain wildcards and no 
external references. (Permissions within the exceptions list are still 
additive.)

- If no match, consult the normal additive-privileges list, with no 
exceptions.

This supports the all-20,000-Columbia-employees except Alice and Bob, 
but does not support Columbia-except-the-EE-department.

This has the advantage that the row-model is maintained, rather than 
having lists of exceptions attached to each rule.

GEOPRIV might then decide not to support the exception list type, but 
the regular list type would be compatible.

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.

Note that I'm not advocating the solution - I'd rather not add the 
complexity and I'm not sure whether I have caught all the possible 
failure cases.

It would be helpful if others would speak up, as this is an important 
issue to settle, soon.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Nov 2003 20:28:25 -0500

---

From: "Naoko ITO" <[email-masked]>
Date: Fri, 7 Nov 2003 16:37:43 +0900

Hello,

I think a separate excepton list is very useful, corresponding to the
exact concept of 'black list.'
Still, I'd like to have an except clause in a permission statment as
well, which can be used for a differenct purpose, i.e., giving
different permissions to some groups of the watchers.

I don't understand why the except clause in each permission statement
should be dismissed while the separate exception list model can be
supported.

1) introducing a separate exception list but not supporting it,
2) introducing an except clause in each permission but not supporting
  it.

In the case of Option #1, the rule enforcer should drop all the
permission statements in the rule set in order to prevent those
should-be-excepted watchers from accidentally obtaining information, if
there is an exception statement which cannot be understood. i.e., no
permission is granted to anybody at all. In the case of Option #2,  the
rule enforcer should drop the permission statements with unknown except
clauses, which still allows some watchers to obtain information. It
seems to me that both options give us the ways to ensure the
privacy-safe even if the rule enforcer does not support the except
mechanism, and rather the latter is more elastic or fault-tolerant. Or
is this just plausible?

As for maintaining the row-model, I don't think the former model
maintains the row-model, while the entire rule set has no meaning if
the actual rule set once has an exception statement. If it means not
supporting the exception at all, the same thing can be done with the
except clause in each permission.

I see no reason to dismiss the latter approach and would suggest to
keep both.

Regards,
-----
Naoko Ito / NEC

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Tschofenig Hannes"
<[email-masked]>; "'Rosen, Brian'"
<[email-masked]>; "Simple WG" <[email-masked]>;
<[email-masked]>
Sent: Friday, November 07, 2003 10:28 AM
Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth

> >>not sure I follow. I work for dynamicsoft.com. All URIs in my

---

From: "Naoko ITO" <[email-masked]>
Date: Fri, 7 Nov 2003 16:37:43 +0900

Hello,

Regards,
-----
Naoko Ito / NEC

---

From: "Naoko ITO" <[email-masked]>
Date: Fri, 7 Nov 2003 16:37:31 +0900

Hello,

I think the black list aproach still has advantages in some situations
where I'm afraid the white list model may cause another privacy issue.

In a situation like CUG services where the service providers give
admittance to some privileged people, they may see benefits of
accessing to/being accessed by unknown people except some malicious
people. If there are no way to specify the policy like "anybody but
those identified people,"  they need  to list every member, who
otherwise might not be identified/revealed by those people until some
time later.

I think the services should decide which model they support. Some
services may disallow statements giving a permission to 'any' or a
permission including an except clause.

I would expect the specification itself should support both models.

Regards,
-----
Naoko Ito / NEC

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; "Tschofenig Hannes"

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

---

From: "Naoko ITO" <[email-masked]>
Date: Fri, 7 Nov 2003 16:37:31 +0900

Hello,

Regards,
-----
Naoko Ito / NEC

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 09:56:57 -0500

>> should be dismissed while the separate exception list model can be

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

> Neither do I.  But in my opinion, both should be dismissed.

I agree; I'm just trying to find the least harmful set of possible 
solutions. Mixing two models is by far, in my opinion, the worst option.

> -andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 09:56:57 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 10:01:26 -0500

> exact concept of 'black list.'

It is not exactly a black list, although it can be used for that. That's 
why I called it an exception list.

> different permissions to some groups of the watchers.

I'm sorry to sound like a broken record: People requesting features that 
break overall processing models should please have the kindness to 
provide motivation beyond "it could be useful".

> 2) introducing an except clause in each permission but not supporting

See my other message.

> mechanism, and rather the latter is more elastic or fault-tolerant. Or

Please review the discussion on why this doesn't work when rules are 
composed from multiple sources.

> except clause in each permission.

The exception-list model does support the row model. Each rule has 
exactly one field value for each field, including the URI matching.

> I see no reason to dismiss the latter approach and would suggest to

If you're in Minneapolis, I'd be glad to explain this in more detail in 
person, since you couldn't be at the interim meeting, where we went over 
this for several hours...

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 10:01:26 -0500

See my other message.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:02:18 -0500

inline.

Andrew Newton wrote:

> Jonathan Rosenberg wrote:
> 
>>
>> <applies-to>
> What is wrong with using group roles with the syntax specified in the 
> draft?  Such as:
> 
>   <applies-to>
>     <uri>mailto:[email-masked]</uri>
>     ...
>   </applies-to>
> 
> -andy
> 

Assuming a user can authenticate themselves as 
"mailto:[email-masked]", the fact that this is a group 
identity would be irrelevant to the system. As such, it would be 
supported in the sense that it didnt matter.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:02:18 -0500

inline.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:21:34 -0500

inline.

Henning Schulzrinne wrote:

>>> I don't understand why the except clause in each permission
>>> statement should be dismissed while the separate exception list
>>> model can be supported.
> 
> 
>  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:
> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:21:34 -0500

inline.

<applies-to>

and:

<applies-to>

<exception-list>

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:29:58 -0500

Andrew Newton wrote:

> As I recall:  at the interim meeting in September we were fortunate to 
> have two people in attendance that had implemented similar access 
> systems.  It was their opinion that the 'except' clause adds enough 
> processing to be a scalability concern for even moderately loaded 
> systems.  The fastest systems are able to take a set of rules and 
> process them one after another until there is a hit.

For how many users? For how many rules? On what kind of processor? On 
what kind of OS? With what kind of programming language? With what 
kind of database?

I don't buy the argument "it doesnt scale" in the absence of a 
concrete definition about the system in which this conclusion was drawn.

In the systems I am interested in, I see a user as having maybe 50-60 
users to whom explicit permissions are granted, and 1-2 domains. 
Within each domain, there would be one or two users that are excepted 
from the domain. In such a system of this size, I see no real 
scalability issues. An easy implementation of this would do a table 
lookup of the watcher in a uri table, and do a lookup in a domain 
table. If there is a matchi n the domain table, and the "exceptions" 
flag is set (meaning exceptions are present), I do another lookup in 
the exceptions table based on the uri. As such, we are talking about 2 
table lookups vs. 3, in addition to any other kind of processing going 
on (such as alteration of the granularity of location data), which I 
expect to be computationally more expensive than a table lookup. I can 
also think of optimizations which combine the two uri lookups into a 
single table lookup.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Nov 2003 15:29:58 -0500

-Jonathan R.

---

From: Alex Audu <[email-masked]>
Date: Fri, 07 Nov 2003 15:08:44 -0600

All this is not too clear to me yet, but  an exception can be viewed
simply as a form negative addition. Therefore it theoretically shouldn't
violate the "additive permissions theory".

The idea of a black list works fine in an enterprise type environment.
I think I see value in it.

Regards,
Alex.

---

From: Alex Audu <[email-masked]>
Date: Fri, 07 Nov 2003 15:08:44 -0600

Regards,
Alex.

---

From: [email-masked]
Date: Fri, 7 Nov 2003 13:10:30 -0800

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.

>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 "[email-masked]"; granting to domain "qualcomm.com" with an
except on the basis of that identifier would be tough.  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. 

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 [email-masked] (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.

I hope this is at least somewhat more clear, and I look forward to continuing
the discussion when we can scribble on a whiteboard/piece of paper.
				regards,
					Ted

---

From: [email-masked]
Date: Fri, 7 Nov 2003 13:10:30 -0800

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 16:27:21 -0500

[Trimming cc list]

This doesn't work under the GEOPRIV design assumption, where permissions 
may be composed from multiple source and where some of these sources may 
(temporarily) be unavailable. While it is privacy-safe to omit 
unavailable sources if you can only add permissions, it is distinctly 
unsafe to ignore external references if you subtract permissions.

Even if you ignore this particular aspect, subtracting permissions does 
not work as in the basic arithmetic. (It's closer to set operations, 
actually.)

I'm guessing that a user expects that once a permission has been 
subtracted, it can't get added back in by some other rule that also 
happens to match. If you enforce this, you have to enforce ordering on 
the way that permissions are computed: you have to first compute the 
additive permissions for each field, then compute all the negative 
permissions and remove them again. Thus, ordering matters and it becomes 
really difficult to understand the interaction of multiple rule makers 
that operate in sequence (personal policy plus corporate policy). 
Naturally, this also significantly complicates the computation of 
permissions.

If you do allow 'sticky' negative permissions (override everything) and 
non-sticky ones (get overridden), you have now further increased the 
complexity of the rule computation and decreased the predictability of 
the system.

Thus, while it may seem easy to think of adding and subtracting 
permissions as commutative and associative mathematical operations, they 
are not really.

The biggest danger with security rule systems is unpredictable behavior, 
i.e., where the rules get sufficiently complex that the user makes 
mistakes in anticipating what exactly will happen under certain 
circumstances. Teaching users about the intricacies of sticky and 
non-sticky set operations does not seem, to me, a way to increase system 
predictability.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 16:27:21 -0500

[Trimming cc list]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 22:29:57 -0500

> THe differences seem merely syntactic, but maybe I am missing

GEOPRIV has, so far, insisted on allowing inclusions and others have 
insisted on wildcards. By separating the two tables, you can have 
inclusions and wildcards in the 'additive' table, and limit the 
restrictions to the exceptions table.

The WGs need to make an explicit choice between three options:

(1a and 1b) Impose restrictions on table composition (no multi-stage 
policies, no dynamic composition and failure on non-reachability during 
static composition). In that case, exceptions can be made to work, 
either for a single table (case 1a; if the restrictions apply to that 
table) or as two tables (case 1b; if only the exceptions table is thus 
restricted).

Dynamic composition = composing permissions while evaluating rules 
(e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference' 
parameter in draft-peterson-geopriv-pidf-lo-02.txt)

Static composition = inclusion by reference when loading permissions 
into the LS or PA

My understanding is that XCAP currently allows neither mode of 
composition, so the problem is not as pronounced there.

I think it would be really confusing and error-prone if, say, the 
PIDF-LO 'ruleset-reference' could not include blacklists, while files 
uploaded from the RM into the LS could.

(2) Allow dynamic composition, but no exceptions.

Maybe we should first determine if there are other options, so that we 
can pose the correct choices.

> 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 

Authentication is not terribly important here, but rather the ease of 
creating new identities within a domain.

Note, in particular, that the authenticated name in a SIMPLE context may 
or may not correspond 1-1 to the From identifier. There is nothing that 
prevents (or should prevent) allowing something like the foo+anything 
mechanism, with a single login (Digest) identity.

Thus, a user who wants to use blacklists reliably has to have a fairly 
detailed understanding of the identity creation and authentication 
policies in the domain.

I'm not arguing that they will never work, just that they will often 
fail in surprising ways.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Nov 2003 22:29:57 -0500

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 00:39:58 -0500

> unsafe to ignore external references if you subtract permissions.

Henning, we still have a fundamental disconnect here.

No one is saying that there is negative permissions here that can be 
fetched by external reference. In particular, I am NOT proposing that 
you can have a pure exception permission. Rather, a permission is 
always additive, but merely defines the set of users that get added by 
specifying a base plus a set of users to remove from that base. To be 
concrete, I would agree that the set of users listed in any except 
clauses *MUST* also be present in a non-except clause in the same 
applies-to statement. This guarantees that the overall applies-to 
statement is purely additive.

For example, a statement might look like:

<applies-to>
   <domain>example.com</domain>
   <except>
     <uri>sip:[email-masked]</domain>
   </except>
</applies-to>

<!-- specific permissions follow -->

This is an *additive* permission. It defines a set of users (everyone 
in example.com but user) that now get these new permissions. If the 
above statement cannot be obtained, those users won't get the 
specified permissions.

Based on my definitions, the following is NOT A LEGAL DOCUMENT:

<applies-to>
   <domain>example.com</domain>
   <except>
     <uri>sip:[email-masked]</uri>
   </except>
</applies-to>

Here, you would definitely have the problems you describe. I am 
agreeing we should not allow this case.

> non-sticky set operations does not seem, to me, a way to increase system 

Agreed here on all points. Please see my above description. Hopefully 
this clarifies that the proposed exception mechanism is not creating 
negative permissions.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 00:39:58 -0500

<applies-to>

<applies-to>

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 00:46:52 -0500

inline.

[email-masked] 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
> "[email-masked]"; granting to domain "qualcomm.com" 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 [email-masked] (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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 00:46:52 -0500

inline.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 01:11:52 -0500

inline.

> restrictions to the exceptions table.

OK, I can agree to that, but again I dont see the need for a 
physically separated listing. ALl you need to do is specify that the 
set of elements in the exception list cannot be wildcarded.

> (2) Allow dynamic composition, but no exceptions.

Again - the exceptions mechanism I am proposing does NOT have the 
problem of causing leakage of information in the case that the rule 
cannot be fetched, either in the static or dynamic cases.

> creating new identities within a domain.

They are related. Because of authentication, creation of a new 
identity requires establishment of credentials for that identity. 
Since this needs to be handled by the domain administrator, it seems 
that it is much easier to manage these identities.

> I'm not arguing that they will never work, just that they will often 

To me, this feels like throwing away the baby with the bathwater.

Just because there will be domains with name allocation policies that 
make it easy to get new names, does not mean that a system should 
never support black lists. I believe that the need for authentication 
in these systems will go hand in hand with identity management which 
generally will make it hard to readily obtain new names (and in 
particular, new names with new credentials). Of course, there can be 
cases where this is not true. I'd rather deal with that using caveats 
in the spec.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Nov 2003 01:11:52 -0500

inline.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Nov 2003 11:32:46 -0500

> fetched by external reference. In particular, I am NOT proposing that 

The problem is that unless you put content-based restrictions on the 
external reference, they cannot contain exceptions, for the reasons 
noted below.

> you can have a pure exception permission. Rather, a permission is always 
> additive, but merely defines the set of users that get added by 

This is indeed a useful additional restriction, but the problem is 
deeper than that. You also need to make sure that the same domain or 
userid does not appear in other rules. In GEOPRIV, the nice part of the 
rule model is that nothing breaks if you have the same URI appear 
multiple times. However, things get messy if you have to check for

Rule set 1:

applies to: columbia.edu
except: alice

Rule set 2 (by external reference from PIDF-LO):

applies to: columbia.edu
except: bob

The merging of these gets rather messy, as you have to make sure that 
Rule 2 does not have a domain that also appears in Rule 1. You can 
define the mechanism so that rule sets 1 and 2 are individually 
additive, but try to explain to the user why Bob suddenly gets the more 
liberal permissions in rule set 1 after you've told the user that they 
can create blacklists.

As I said before, having a single XML schema, except that rule set 2 
cannot have exceptions, seems really confusing to users. Why should a 
perfectly fine rule set that worked ok when I XCAP-fed it to the PA/LS 
work, but be illegal if it's referenced from PIDF-LO?

> This is an *additive* permission. It defines a set of users (everyone in 
> example.com but user) that now get these new permissions. If the above 
> statement cannot be obtained, those users won't get the specified 
> permissions.
> 
> Here, you would definitely have the problems you describe. I am agreeing 
> we should not allow this case.

You know how much fun comparing SIP URIs is... While this is trivial for 
the simple ASCII examples that you have offered here, checking domain 
equality for exceptions would have to be very tightly circumscribed to 
be tractable. Should 'applies to columbia.edu except 
[email-masked]' be allowed? You now no longer have a simple 
equality match, but have to be far more precise as to what's allowed and 
what isn't.

Also, this can no longer be readily expressed in anything approaching a 
database table. Internally, you would indeed have to create a separate 
exception table, along the lines that I have alluded to earlier since 
each row can only have one matching field (URI).

I'm harping on the database issue not because I believe that every 
implementation will use them, but because they have precise matching 
semantics that we can describe rigorously. I would feel very 
uncomfortable with the reliability of this whole edifice if I can't 
write down a boolean query and know precisely what the outcome will be 
(and can encode this in the specification itself).

> this clarifies that the proposed exception mechanism is not creating 

This 'negative permissions' comment was not in relation to your 
proposal, but in response to what others have offered.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Nov 2003 11:32:46 -0500

Rule set 1:

applies to: columbia.edu
except: alice

applies to: columbia.edu
except: bob

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Nov 2003 11:48:23 -0500

> OK, I can agree to that, but again I dont see the need for a physically 
> separated listing. ALl you need to do is specify that the set of 
> elements in the exception list cannot be wildcarded.

See previous message on related difficulties.

> They are related. Because of authentication, creation of a new identity 
> requires establishment of credentials for that identity. Since this 
> needs to be handled by the domain administrator, it seems that it is 
> much easier to manage these identities.

We have authenticated email submission, but users can submit email under 
an effectively infinite number of identities (related to their core 
identity).

> make it easy to get new names, does not mean that a system should never 
> support black lists. I believe that the need for authentication in these 
> systems will go hand in hand with identity management which generally 
> will make it hard to readily obtain new names (and in particular, new 
> names with new credentials). Of course, there can be cases where this is 
> not true. I'd rather deal with that using caveats in the spec.

I'm sure users and system administrators will read these caveats and act 
accordingly :-)

For policy languages, my bias is towards being underpromising and 
overdelivering, rather than lulling users into a false sense of security 
(or, here, privacy). The more special cases there are, the more likely 
it is that users will have the wrong mental model of what's happening 
and thus make mistakes. From the discussion here, it's clear that it is 
taking even technically sophisticated protocol designers a while to work 
out all the cases that work and don't work.

Thus, I'm trying to find the absolute minimum set of exceptions, rules, 
caveats, disclosures, warnings and algorithms.

Things get complicated if you have multiple sources of policy, such as 
in the GEOPRIV reference + LS model (see the example where the same 
domain with different exceptions appears in multiple policy documents).

After all, if you really need blacklists within a company and a simple 
"please don't subscribe to me" doesn't work, that pestering stalking 
colleague has an incentive to find ways to bypass your blacklist. We all 
agree, I hope, that the domain + exception model is useless for, say, 
aol.com.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Nov 2003 11:48:23 -0500

Henning

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Nov 2003 09:15:29 -0500

-andy

---

From: "Naoko ITO" <[email-masked]>
Date: Sat, 8 Nov 2003 12:04:58 +0900

Hello Henning,

Thank you for your reply.
Comments in-line.

> It is not exactly a black list, although it can be used for that. 
> That's why I called it an exception list.

Sorry, I was not (and am not) very careful about choosing words. 
I understand a black list is one of the application of exception list.
 
> I'm sorry to sound like a broken record: People requesting features 
> that break overall processing models should please have the kindness 
> to provide motivation beyond "it could be useful".

As I didn't want to mix issues; WHY, WHAT and HOW,  
I sent out a separate note on this with a CUG example,
which might not be convincing enough.
Although I carelessly used the term 'black list' to simplify 
the explanation, it could be about any exception to a permission
statement.

> > should-be-excepted watchers from accidentally obtaining
> information,
> > if there is an exception statement which cannot be
> understood. i.e.,
> > no permission is granted to anybody at all. In the case of
> Option #2,
> > the rule enforcer should drop the permission statements
> with unknown
> > except clauses, which still allows some watchers to obtain 
> > information. It seems to me that both options give us the ways to 
> > ensure the privacy-safe even if the rule enforcer does not
> support the
> > except mechanism, and rather the latter is more elastic or 
> > fault-tolerant. Or is this just plausible?
> 

Sorry about my lame explanations.

The issues I tried to raise here are of the influence of 
introducing Capability A which is not supported by its rule enforcer X 
and of the forward compatibility as well.  

This will not be a problem if the rule enforcer supports an exception
capability, 
but I was caught by the statement:
 "GEOPRIV might then decide not to support the exception list type, but 
   the regular list type would be compatible."

It will make all the permission statements useless to introduce 
a separate exception list which is not supported by its rule enforcer 
unless the privacy-safe policy is broken, which should be rather a
problem. 
If it exists in a rule set, not only a separate exception list 
but an entire rule set needs to be dropped. Otherwise those listed
people 
will never be excluded once they are granted by other permission
statements.

Then, suppose this exception list is one of the extenstion to the core 
xcap-auth and belongs to a different namespace.
If this exception clause is separated from the normal permission, 
the rule enforcers without its support should 
 - ignore the entire rule set, 
   * which requires the knowledge about this particular extension, or
   * disallowing any extension at all, which is not forward compatible,
OR 
 - ignore the unknown elements, 
   * which will violate the privacy, as the remaining 

If exception clauses are attached to permission statements, on the other
hand, 
the privacy-safe mechanism mentioned in section 4.4 of geopriv-policy
will work 
and some of the rule set will survive, as only the permission statements
with unknown 
exception elements can be dropped.

I believe the except clause in a permission statement is rather
privacy-safe without 
giving up the entire rule set,  while I think a separate extension list
is more readable 
in some cases. 
 
Regards,
-----
Naoko ITO / NEC

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Nov 2003 09:15:29 -0500

-andy

---

From: "Naoko ITO" <[email-masked]>
Date: Sat, 8 Nov 2003 12:04:58 +0900

Hello Henning,

 

 
Regards,
-----
Naoko ITO / NEC

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Nov 2003 09:19:38 -0500

<applies-to>

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 07 Nov 2003 09:19:38 -0500

<applies-to>

-andy

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Nov 2003 11:32:54 -0500

I've been trying to ignore this, but I just can't.

	Paul

Henning Schulzrinne wrote:
> userid does not appear in other rules.

Overlapping rules can come about very naturally via wildcarding:

  <applies-to>
    <domain>*.ny.example.com</domain>
    <except>
      <uri>sip:[email-masked]</domain>
    </except>
  </applies-to>

  <applies-to>
    <domain>sales.*.example.com</domain>
  </applies-to>

You can try to legislate that each ruleset covers a unique subset of all 
users, but that may be restrictive.

Jonathan Rosenberg wrote:
 >
 > 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.

This really provides the poster child for the problem of overlapping lists:

  <applies-to>
    <list>sip:[email-masked]</domain>
    <except>
      <uri>sip:[email-masked]</domain>
    </except>
  </applies-to>

  <applies-to>
    <list>sip:[email-masked]</domain>
  </applies-to>

What happens if alice is on both the golf-list and the vp-list? Does it 
matter what order the two <applies-to> clauses are mentioned?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Nov 2003 11:32:54 -0500

Paul

  <applies-to>

  <applies-to>

  <applies-to>

  <applies-to>

---

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

We'll be ok as long as permissions are strictly additive across rules, 
i.e., if somebody matches two rules (groups, etc.), they'll get the 
union of the permissions. The geopriv-auth draft provides the arithmetic 
to do this.

I would hope that we can avoid matching on things like 
foo.*.example.com. That basically makes a database implementation 
impossible. (While most databases support 'like' and regexp, these only 
apply to the value being queried; the field value cannot be the pattern.)

Paul Kyzivat wrote:

>>> always additive, but merely defines the set of users that get added 
>>> by specifying a base plus a set of users to remove from that base. To 
>>> be concrete, I would agree that the set of users listed in any except

---

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