Subject: [Simple] Authorization Rules Discussion A: Sphere Interpretation

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Oct 2004 03:37:07 -0400

The presence authorization document has a condition called <sphere> 
which allows you to condition the rule based on the current value of the 
<sphere> in your presence document.

However, we ran into confusion at some point about what to do if there 
were multiple <sphere> elements in a document. One proposal was that if 
there are more than one, then unless they were all the same, the 
condition would not be true.

Revisiting this in light of the data model, it is easily resolved. 
<sphere> describes my current state of being - whether I am in "work 
mode" or "play mode" or what have you. This is clearly an attribute of 
<person>, and must only appear there. Since there can only be one 
<person> per document, there can never be ambiguity.

It may be that, prior to composition, there are multiple sources of 
documents that define my <sphere>. Thats OK. The composition process 
will resolve these conflicts somehow and produce a single <person> 
element with a <sphere>. The conditioning in the presence authorization 
model is based on that <sphere>.

Now, this does raise another interesting question: the composition 
policy itself may be watcher dependent. As a result, my value of 
<sphere> may well be different for some watchers compared to other 
watchers. Thats ok; the composition policy is applied before the 
authorization policy. When a new subscription arrives for a watcher, the 
composition policy will execute, and then the <sphere> will be set, 
allowing the authorization policies to execute.

Related to that, it needs to be explicitly stated that when processing a 
subscription for resource X, it is the presence document for resource X 
that is used to drive the <sphere> condition. This could be confusing in 
cases where users have aliases and multiple "personas", each of which 
are different resources with different documents.

Thus, all that is required here is some clarification in the rpid and 
data model documents to make sure this is clear.

-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: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Oct 2004 11:30:05 -0400

> allowing the authorization policies to execute.

Do we need this much generality? It seems much simpler if we say that 
composition is itself independent of subscriber. (I have always assumed 
that.)

Doing composition independently for each watcher seems to present some 
implementation issues. In particular, suppose there are a number of 
transient sources of presence data with long expiration intervals. Each 
source document needs to be retained until it expires, even if all the 
data in it has subsequently be overridden by other sources.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Oct 2004 14:16:56 -0400

> <person> per document, there can never be ambiguity.

This goes back to the larger issue I mentioned earlier. I don't believe 
this is a safe assumption given the inability of machines (composers) to 
definitively resolve conflicting information in some circumstances and 
the desire not to have to lose information due to the inability of the 
format to carry the data end-to-end.

> model is based on that <sphere>.

I don't believe this is always possible.

Henning

---

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

inline.

Henning Schulzrinne wrote:

>> were multiple <sphere> elements in a document. One proposal was that 
>> if there are more than one, then unless they were all the same, the 

Per my reply to you on that thread, we had hashed this out on the design 
team calls, and had concluded that it was better to present an 
intelligible view in the base case. I strongly believe we should stick 
with that decision.

The fact that this approach solves a thorny problem in the interpetation 
of <sphere> to me seems to indicate that we are going in the right 
direction, in terms of simplification.

-Jonathan R.

---

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

inline.

Paul Kyzivat wrote:

>> element with a <sphere>. The conditioning in the presence 
>> authorization model is based on that <sphere>.
>>
>> authorization policy. When a new subscription arrives for a watcher, 
>> the composition policy will execute, and then the <sphere> will be 
>> set, allowing the authorization policies to execute.
> 
> 

I don't think we've ever had this discussion explicitly, so it's good 
that this has brought it to the surface.

> data in it has subsequently be overridden by other sources.

One could make the same argument about the raw presence document prior 
to application of privacy filtering; you may need to retain lots of 
information, even though none of the recipients will ever get any of it.

I had assumed that composition was watcher specific because every other 
aspect of policy can be, and it didnt seem like this would be an 
exception. Seems logical that I would want one set of users to see one 
view for my presence, and another set to see something entirely 
different. The canonical example is whether or not I'm in a meeting. 
Isn't it reasonable to report to my co-workers that I am in a meeting, 
while I would report to my friends that I am just busy? If composition 
is the process by which (amongst other things), conflicting status can 
be removed, doesn't it need to be watcher specific?

Even if you remove conflicting data, it seems like the act of merging of 
services might be watcher specific. Might not I want my co-workers to 
see my cell phone and work phone as separate devices, but my friends to 
see just one?

-Jonathan R.

---

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

Jonathan Rosenberg wrote:
>> composition is itself independent of subscriber. (I have always 
>> assumed that.)
> 

Yes. I'll bet I was not the only one to interpret it that way.

>> transient sources of presence data with long expiration intervals. 
>> Each source document needs to be retained until it expires, even if 
>> all the data in it has subsequently be overridden by other sources.
> 

I'm not *too* concerned that this is a significant difference. We can 
probably come up with use cases that are pathological for either approach.

The stronger argument, if there is one, is that there be a clear 
separation of concerns, with the aggregated presence document being the 
handoff between the fan-in of presence sources and the fan-out to 
presence consumers.

> exception.

I agree there is some merit to this view.

OTOH, it could be harder to write policy this way. If you have M aspects 
governing how you want to merge sources, and N aspects governing how you 
divulge presence to subscribers, then if you do both together you have 
M*N decisions to make. The other way you only have M+N.

 > Seems logical that I would want one set of users to see one
> while I would report to my friends that I am just busy?

Yes.

But you could get there in may ways. Suppose you have two sources of 
information that you are merging, one saying you are busy and the other 
saying you are in a meeting. You could:

- have the Busy choice take precedence for friends, and the in-a-meeting
   source take precedence for co-workers.

- you could first merge the two and decide you were in-a-meeting. Then,
   for friends you could "filter" that to the less specific state of
   Busy, while you give the actual value to co-workers.

Of course the "filtering" above doesn't fit into the approach proposed 
for granting access. But it could be another technique, or a 
per-subscriber composition that is different than the one used for 
combining different sources.

 > If composition

That's not entirely clear to me. I guess the question is whether in the 
presence of conflict there is a best approximation to truth, or whether 
"truth" is the same for all watchers even if what you are willing to 
tell them is not.

(If I am "on vacation in Hawaii", and "in a meeting in NY", are both 
alternate truths depending on who is asking?

Of course watcher specific composition is a superset of watcher 
independent composition, so if the only criterion is which is richer 
than you win.

> see my cell phone and work phone as separate devices, but my friends to 

Maybe. But this could be modeled by having the merge create *three* 
tuples, with cell and work phones separate, and a third with them 
merged. Then the filtering would disclose different parts to the 
subscribers.

Again, I agree that your model is more powerful. If it were to just be 
an abstract model then I would not be concerned at all. Then the 
possibilities could be explored by different implementations, and there 
might be different tradeoffs between power and simplicity.

But if these are to be standardized, then we may be sentencing users to 
a level of complexity that they don't want to deal with. An 
implementation might try to simplify this by only providing mechanisms 
to construct a simplified model. But if it is expected to edit existing 
policy descriptions then this breaks down.

I am not convinced one way or the other on this. I am interested to hear 
what others think.

	Paul