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

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:

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

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

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

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

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

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

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

---

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

Ted,

     <statement id="as8f">
        <applies-to>

        <permissions>
          <accept/>

more inline:

<applies-to>

-Jonathan R.

---

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:
>
>
>
>>but doing so means that no permission is granted or that the protocol-defined
>>permission to distribute means the object must not be distributed). 
>>An object
>>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.
>>
>>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.
>>
>>default behavior relatively easy to explain ("anything not 
>>permitted is denied,
>>number of assertions beyond the bounds of practical implementation.  To take
>>to assert individual permissions for each of her remaining co-workers.  This
>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.

>
>>
>>The good news is that if we believe in the soundness of the 
>>fundamental model,
>>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.
>
>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

---

From: [email-masked]
Date: Fri, 19 Sep 2003 15:26:10 -0700

Hi Jonathon,

<applies-to>

				regards,
					Ted Hardie