Subject: [Simple] Presence Authorization Discussion E: Subscription policy vs. document processing

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 04:36:21 -0400

This is really the only major open issue that is not resolved by the 
data model, and its one of the most important ones to resolve. So, 
please comment on this one.

Currently, our presence authorization policy documents specify how to 
filter presence documents for presentation to a watcher, and they also 
specify whether or not a subscription should be accepted or rejected 
(via the <action>). They also specify polite-blocking as an action. As a 
result of all of these being actions, there is an explicit privacy 
ordering - block -> confirm -> polite block -> allow.

Henning had suggested on the list that perhaps we should split the 
process of acceptance/rejection of the subscription from the processing 
of the document itself.

If anything, the data model would currently argue in favor of that 
position. The processing of figure 4 defines the privacy filtering step 
as serving the fucntion of removing sensitive information from the 
presence document. This sequence of operations gets applied when a 
document needs to be generated for a watcher. It doesnt address the 
actual acceptance/rejection of the subscription itself.

In fact, its more complicated than that. In light of the data model, 
"polite blocking" is really a combination of accepting of the 
subscription, along with a composition policy which produces a document 
for the watcher that lies about my presence status.

So, the question is, do we keep these concepts combined into a single 
action, or do we split them apart? In either case, how does this play in 
the model?

 From a *modeling* perspective, I think that processing of the 
subscription is most definitely a separate thing. That processing puts 
the subscription in only one of three allowed states (accepted, pending, 
denied). It is only once accepted that the actual privacy filtering 
operation makes sense. I'd further argue that the process of polite 
blocking is really only meaningful when the subscription itself has been 
accepted (in the sense that the subscription got a 200 ok and a NOTIFY 
gets sent). It's clearly privacy-related, but its not "privacy 
filtering" in the sense that it is not a process of removing information 
at all, its really creation of a fake input document into the processing 
of figure 4.

So, here is my proposal:

1. the data model identify an additional processing step, which happens 
when a subscription arrives. It defines how that subscription is 
procssed (accept, reject, confirm), and it determines the composition 
policy of figure 4. Note that, because composition hasn't happened yet, 
conditions that are based on the presence state itself are meaningless 
and would be ignored. I think this is a feature; it means that the state 
of the subscription itself doesnt really change with my presence state, 
it will be based only on more static information, such as the identity 
of the watcher, time of day, etc.

2. The processing in step 1 above is defined by the <sub-handling> 
element, as it is today in the authorization document

3. we separate the processing of subscription handling from privacy 
filtering in the model, but both use the same input document - the 
authorization policy. Thus, the <sub-handling> element is used to guide 
the subscription processing, and the rest is used to guide privacy 
filtering. This has the benefit of allowing us a single document for a 
user to manage via xcap, but allowing it to really represent two 
separate poliices.

4. The value of "polite-block" basically selects a composition policy 
which creates a fake document for a user, and "accept" uses the default 
policy. More generally, we might imagine that composition policies 
themselves have privacy implications - some will reveal more, and some 
less. To resolve that, we can give each policy a number based on the 
amount of information it provides, and select which policy as part of 
the <sub-handling> element. Beacuse the <sub-handling> element is 
combined using the combination rules of common-policy, it has the right 
privacy properties.

This proposal would mostly effect the model; the presence authorization 
document itself remains largely unchanged.

Comments?

-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: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 11:48:32 -0400

I agree with the proposal. There are also other reasons, having to do 
with other means of information access (e.g., through a web page) that 
might well share the same privacy policy, that lead one to conclude that 
this separation makes sense.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 12:13:08 -0400

I mostly agree with this partitioning. However I do have one concern. 
See below.

	Paul

> at all, its really creation of a fake input document into the processing 

Yup.

> combined using the combination rules of common-policy, it has the right 

This relates back to my comment in another thread about whether we 
really need the composition policy to differ by subscriber. This seems 
to suggest that the answer is yes, but the issues of that remain.

The data model (figure 4) has the same composition policy being used 
*twice* - once to combine all the inputs, and later to patch up any mess 
made by the filtering. This always seemed a bit odd to me.

Maybe the answer is that these should be different policies. The policy 
used to combine all the inputs could be common to all subscribers, while 
the post-filter policy might differ by subscriber. One of the functions 
of this post-filter composition policy could be to do polite blocking.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 16:23:46 -0400

inline.

Paul Kyzivat wrote:

>> (via the <action>). They also specify polite-blocking as an action. As 
>> a result of all of these being actions, there is an explicit privacy 
>> process of acceptance/rejection of the subscription from the 
>> processing of the document itself.
>>
>> position. The processing of figure 4 defines the privacy filtering 
>> step as serving the fucntion of removing sensitive information from 
>> the presence document. This sequence of operations gets applied when a 
>> subscription, along with a composition policy which produces a 
>> document for the watcher that lies about my presence status.
>>
>> action, or do we split them apart? In either case, how does this play 
>> in the model?
>>
>> the subscription in only one of three allowed states (accepted, 
>> pending, denied). It is only once accepted that the actual privacy 
>> filtering operation makes sense. I'd further argue that the process of 
>> polite blocking is really only meaningful when the subscription itself 
>> has been accepted (in the sense that the subscription got a 200 ok and 
>> a NOTIFY gets sent). It's clearly privacy-related, but its not 
>> "privacy filtering" in the sense that it is not a process of removing 
>> information at all, its really creation of a fake input document into 
>> the processing of figure 4.
> 
> 
> Yup.
> 
>> So, here is my proposal:
>>
>> 1. the data model identify an additional processing step, which 
>> happens when a subscription arrives. It defines how that subscription 
>> is procssed (accept, reject, confirm), and it determines the 
>> composition policy of figure 4. Note that, because composition hasn't 
>> happened yet, conditions that are based on the presence state itself 
>> are meaningless and would be ignored. I think this is a feature; it 
>> means that the state of the subscription itself doesnt really change 
>> with my presence state, it will be based only on more static 
>> information, such as the identity of the watcher, time of day, etc.
>>
>> authorization policy. Thus, the <sub-handling> element is used to 
>> guide the subscription processing, and the rest is used to guide 
>> privacy filtering. This has the benefit of allowing us a single 
>> document for a user to manage via xcap, but allowing it to really 
>> represent two separate poliices.
>>
>> which creates a fake document for a user, and "accept" uses the 
>> default policy. More generally, we might imagine that composition 
>> policies themselves have privacy implications - some will reveal more, 
>> and some less. To resolve that, we can give each policy a number based 
>> on the amount of information it provides, and select which policy as 
>> part of the <sub-handling> element. Beacuse the <sub-handling> element 
>> is combined using the combination rules of common-policy, it has the 
>> right privacy properties.
> 
> 

Right. Lets debate that in the other thread.

> of this post-filter composition policy could be to do polite blocking.

I'm not sure I see how they really differ. Indeed, if we had determined 
that the scope of functions for composition policy were commutative with 
filtering, and idempotent, one might conclude that there is no need at 
all to do it prior to filtering.

In any case, I see the scope of composiiton policy being guiding the 
decisions on how services and devices are merged, split, and conflicts 
are resolved. I don't see how the policies on how this is done would 
really differ based on whether they happen to be executed prior or after 
privacy and watcher filtering. What logic would one specify differently 
in one place as opposed to another?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 18:51:47 -0400

Jonathan Rosenberg wrote:
>>> policies themselves have privacy implications - some will reveal 
>>> more, and some less. To resolve that, we can give each policy a 
>>> number based on the amount of information it provides, and select 
>>> which policy as part of the <sub-handling> element. Beacuse the 
>>> <sub-handling> element is combined using the combination rules of 
>>> common-policy, it has the right privacy properties.
>>

OK.

>> *twice* - once to combine all the inputs, and later to patch up any 
>> mess made by the filtering. This always seemed a bit odd to me.
>>
>> Maybe the answer is that these should be different policies. The 
>> policy used to combine all the inputs could be common to all 
>> subscribers, while the post-filter policy might differ by subscriber. 
>> One of the functions of this post-filter composition policy could be 
>> to do polite blocking.
> 

If these are comutative then there could indeed be different views on 
how best to optimize an implementation. (Could even by like a SQL 
optimizer deciding dynamically what order of execution is optimal.)

Even then there could still be a notion of subscriber-dependent and 
subscriber-independent composition. Depending on how you choose to 
implement, this might be advantageous and might not.

But that does suggest something to me that I hadn't considered before. 
The distinction between subscriber-dependent and subscriber-independent 
composition needn't be at the level of an entire policy description. If 
individual rules in the composition policy were identifiable that way, 
and if the individual rules are comutative, then a server could order 
them to share the effort of applying the subscriber-independent policy 
elements.

That would solve the potential efficiency issue, though not the issue of 
conceptual complexity.

> in one place as opposed to another?

I agree that it doesn't depend on the order. But it does depend on 
whether the composition rules need to be subscriber-dependent.

Its hard to discuss without some tangible examples of composition rules. 
It has been postponed so far, and I think that is no accident. I think 
this is going to be a really hard one to get right.

There may still be some question as to whether the composition and 
filtering are comutative. If composition can create new kinds of 
elements that weren't in the inputs, then if it is applied after 
filtering, it may create something that the filter would have removed.

That suggests to me that the "fixup" stage after filtering is not the 
same as composition. It should be something restrictive that restores a 
document to validity without adding anything that a filter removes. It 
probably wouldn't have to be subscriber-dependent, and might not even 
need to be policy driven.

	Paul