Subject: [Geopriv] A description of the relationship of permissions and rules.

From: [email-masked]
Date: Mon, 8 Sep 2003 14:19:52 -0700

During the recent GeoPriv meeting Henning and Hannes presented
a model for understanding the application of the rules to location objects;
as part of that discussion, I agreed to write up a view of that
model seen through a very simple form of set theory (think elementary
Venn diagrams).  Below is a first attempt to capture that view.

In this conceptualization, the starting point is that the privacy
work of geopriv can be seen as populating a set of permissions
associated with a particular location object.  That set of
permissions starts out empty.  It is populated when the location
object contains statements which add permissions.  From a logical
perspective, each location object contains 4 statements:

1) A statement granting permission to retain the object for some time.

2) A statement granting permission to distribute the object.

3) A statement granting a granularity of accuracy for the object.

4) A statement containing a URI at which further rules may be found.

One of the keys to this model is that any statement or rule must be
additive of permissions.  An object may omit a particular statement,
but doing so means that no permission is granted or that the protocol-defined
minimum is granted (for 3, as an example, the defined minimum for civil
location might be timezone, where the absence of the statement granting
permission to distribute means the object must not be distributed).  An object
may, of course, choose to contain a statement that means "no permission to
distribute" or "no permission to retain"; the ability to leave out the bytes
carrying the assertion is an optimization, as the statement is 
logically present.

If there is a statement containing a URI at which further rules may
be found, those rules may add permissions to the statements asserted with
the location object, but they may never take permissions away.  In
our Venn diagram set theory, in other words, when the conditions in
those rules are met (the right identity is presented or the right
time constraints are met, etc.), a new a set of permissions is granted,
and that set is unioned with the set carried in the object.
Note that this means if the statement containing the URI at which further
rules may be found cannot be dereferenced, then it is still safe to behave
according to the statements contained in the object, as these are the
baseline permissions.  In cases where the dereferencing of this URI is
required for correct operation, these baselines are set to grant no 
permissions,
so that the location object is not distributed or retained when the
dereferencing has not occurred.

Of those in the original formulation, then, a, b, c, and g are treated as
assertions.  All of the other "rules" are actually mechanisms for describing
specific conditions which modify the assertions of permitted 
retention, distribution,
and granularity by unioning new permissions to those in the original object.

I believe this model has some advantages, particularly in that it makes the
default behavior relatively easy to explain ("anything not permitted is denied,
and what has been permitted may not be later be denied").  There are some
potential gotchas, though, in that there is a risk of the model forcing the
number of assertions beyond the bounds of practical implementation.  To take
one of Jim Polk's examples:  If an employee wishes to grant permission
beyond the baseline to all of her co-workers, a single assertion can work
by associating a specific identity to that pool.  If she wants to grant
permission to all of her co-workers except one individual, for whom she
has taken out a restraining order, to achieve her goal she might need
to assert individual permissions for each of her remaining co-workers.  This
gets to the point of absurdity pretty quickly.  The group at the interim
meeting agreed to think more about the use cases in which "except"-type
exclusions are required, and it also agreed that it might be the camels
nose for regex-type processing ("allow anyone who is presenting an identity
containing @example.com"), which we strongly felt to be beyond the scope
of work we can do quickly.

The good news is that if we believe in the soundness of the fundamental model,
we can publish documents describing the statements for retention, distribution,
granularity, and naming of URIs without having completed the work on the rules,
as we will be sure that the presence of the un-dereferenced URI will 
not constitute
a privacy violation.

As said above, though, this is a first cut and others may wish to chime in.
				regards,
					Ted Hardie

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 08 Sep 2003 23:19:57 -0400

[email-masked] wrote:

One point of clarification is that in this model, statements can be made 
by the rulemaker, conveyed to the location server, to act on a location 
object "passing by" or can be conveyed in something attached to the 
location object (where 'attached' might mean attached by cid or part of 
the same XML wrapper), for the benefit of the location recipient.

(I think that was kind of the working assumption that we reached at the 
meeting, but may not be universally shared.)

> 3) A statement granting a granularity of accuracy for the object.

Granularity can be for an individual component, e.g., separate for civil 
and geospatial. This may become more important in the future. For 
example, if I convey a vector, I might have one resolution for speed and 
another for current position (as long as the update frequency doesn't 
betray speed...).

> and what has been permitted may not be later be denied").  There are some

This also avoids 'entrapment', where I show you a rule, you follow it, 
and then I manage to change one of the referenced documents, which 
contradicts that rule and triggers a class-action lawsuit :-)

> of work we can do quickly.

We discussed also that for identities, restraining orders are hard to 
enforce in the Internet as long as the villain can acquire another 
identity easily. Mr. Ex-Boyfriend can then morph from [email-masked] 
to [email-masked].

However, for other variables, exclusion is easy to do, by adding negated 
fields. For example, for place restriction, matching on a rule like

"not in (country=US, state=NJ, county=Bergen)"

will address many of the common use cases. Thus, the problem for 
excluding a person is not so much one of mechanics, but rather whether 
such exclusion is meaningful. For time and space, it seems to be, for 
identity, only in limited circumstances. (For example, if only Acme 
employees have credentials that my LS accepts and the Acme HR department 
is careful about not letting Bob Jerk get a new one, exclusion based on 
identity can work.)

> as we will be sure that the presence of the un-dereferenced URI will not 
> constitute
> a privacy violation.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 03:36:09 -0400

Ted,

cc'ing SIMPLE since this is relevant to it.

I was not at the interim, so I do not know the extent to which xcap 
was discussed.

However, the model you propose below is EXACTLY, and I mean exactly, 
the model that is currently documented in 
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt. 
  Quoting from my document:

> Structuring Presence Authorization
> 
>    This specification defines three application usages (each with their
>    own XML schema) that, put together, present a comprehensive solution
>    for allowing clients to specify authorization policies that a PA can
>    use when processing a subscription. The first of these application
>    usages has the AUID of permission-statements. This usage allows a
>    client to make statements about which permissions are granted to
>    which watchers. Each statement contains a definition of the watchers
>    to whom it applies, and then contains a list of permissions which are
>    granted to those watchers. The concept of a permission is central to
>    this specification. A permission is an atomic statement of consent or
>    denial. A permission can indicate a condition under which a
>    subscription is accepted or rejected, a condition under which a
>    notification is or is not sent, or a piece of information which is or
>    is not revealed in a presence document. The overall authorization for
>    a watcher is represented by the union of the permissions granted to
>    that watcher.

I believe this is exactly what you are talking about. For presence, I 
have classified these permissions as:

whether it is accepted or not (a binary permission)
what the watcher can see
when the watcher gets a notification
transformations that get applied to the watcher

To specify, for example, that Ted can subscribe to me and see my 
contact URI, basic presence, and rpid information:

     <statement id="as8f">
        <applies-to>
          <uri>sip:[email-masked]</uri>
        </applies-to>

        <permissions>
          <accept/>
          <show-namespace>urn:ietf:params:xml:ns:pidf</show-namespace>
 
<show-namespace>urn:ietf:params:xml:ns:sip-rpids</show-namespace>
          <any-event/>
        </permissions>
     </statement>

I explicitly chose this model because it had the crispest and easiest 
to process composition model. That was important since, for presence, 
the information sent to a watcher is going to be the combination of 
rules specified by the watcher and by the presentity (the source of 
the data in our terminology). This combination rule is most easily 
done when, as you say, its a basic set operation. If watcher asks for 
information X and the presentity has granted Y, the watcher will 
receive the intersection of X and Y.

more inline:

[email-masked] wrote:

> carrying the assertion is an optimization, as the statement is logically 
> present.
> 

I had not considered this aspect; definitely a benefit of the model.

> specific conditions which modify the assertions of permitted retention, 
> distribution,

We had this exact same discussion in SIMPLE. Our conclusion was the 
same - I would add except clauses to applies-to, so you could do 
things like:

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

The basic processing is to compute the union of the identities defined 
by the inclusive applies-top operators (we defined them as <domain>, 
<uri>, and <list>) and then remove those specific by <except>.

> as we will be sure that the presence of the un-dereferenced URI will not 

I encountered one big snag in this model which I havent quite worked 
out. THe snag is what we are calling "transformational permissions". 
These are cases where I want to say "if my activity is 'busy', change 
it to 'idle'". Simply put - lying. I believe that lying will play a 
far more important role than omission of information, both in presence 
and geolocation. I don't know if this was discussed at the interim or not.

Lying doesnt really fit into the model. Its not a permission in that 
it doesnt grant access to a piece of information fundamentally in the 
data. Rather, it asks for a change in that data. I could think of no 
other solution than to include explicitly defined ordering values that 
tell the server how to compose the information.

-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: Fri, 19 Sep 2003 15:26:10 -0700

Hi Jonathon,
	Response inline; sorry for the delay.

>I was not at the interim, so I do not know the extent to which xcap 

It was discussed.  Putting together the formulation in terms of Venn diagram
level set theory was an action item of mine because some of the presentations
used in interim used a RDBMs view and terminology which were not as
familiar to some of the attendees.

>I believe this is exactly what you are talking about. For presence, 
>I have classified these permissions as:
>
>I explicitly chose this model because it had the crispest and 
>easiest to process composition model. That was important since, for 
>presence, the information sent to a watcher is going to be the 
>combination of rules specified by the watcher and by the presentity 
>(the source of the data in our terminology). This combination rule 
>is most easily done when, as you say, its a basic set operation. If 
>watcher asks for information X and the presentity has granted Y, the 
>watcher will receive the intersection of X and Y.
>
>more inline:
>
>
>
>The basic processing is to compute the union of the identities 
>defined by the inclusive applies-top operators (we defined them as 
><domain>, <uri>, and <list>) and then remove those specific by 
><except>.

We discussed the except processing extensively, and I agree that it 
would be useful
if it can avoid heavyweight processing.  The group at the interim was 
very clear that
regex-style processing was a serious problem.  So something like:

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

would be a no-no, even if it were a handy way to separate presentities for
an example.com that prepends t_ to temporary worker account names.
I am still not sure of the balance here, and more discussion is 
probably needed.
In the short term, I hope we can develop base semantics which do not require
it and do not prevent it.

>>as we will be sure that the presence of the un-dereferenced URI 
>>will not constitute
>>a privacy violation.
>
>These are cases where I want to say "if my activity is 'busy', 
>change it to 'idle'". Simply put - lying. I believe that lying will 
>play a far more important role than omission of information, both in 
>presence and geolocation. I don't know if this was discussed at the 
>interim or not.

It was, and we agreed that the current push to get the standard 
before the implementation
and deployment of no-privacy systems is very widespread meant this 
was a feature that
needed to be put on hold.  That needs confirmation with the mailing 
list, of course, but I
personally believe that the discussion was compelling.

>it doesnt grant access to a piece of information fundamentally in 
>the data. Rather, it asks for a change in that data. I could think 
>of no other solution than to include explicitly defined ordering 
>values that tell the server how to compose the information.

Yes; this is a different model (referred to in the interim meeting as 
the "mistress model",
for the shorthand case where you wanted to present a false 
geolocation to your spouse
when you were with your mistress (and vice versa, no doubt)).

One key thing here is that the rules sent with the data object are 
unaffected by the
presence of this facility; you are obviously never going to send 
along the information
that this data was made up.  One restriction is, as above, if there is any
case under which failing to apply the rules at a URI causes a problem, you must
start out with a base case of no permissions granted (or the failure 
to dereference the
URI means the mistress sees you're with your wife).

				regards,
					Ted Hardie