Subject: RE: [Simple] Presence Authorization Discussion B: Composition/Aut h Sequencing

From: Goeman Stefan <[email-masked]>
Date: Thu, 14 Oct 2004 11:22:07 +0200

Hello Paul,

I understand what you mean, and you are right.
But, I would like to argue that there are two topics in authorization.
1) First, determining if a watcher is allowed to subscribe, and determine
what to do (allow, block, polite block, ...).
2) Secondly, if he is allowed, you can do all this element-by-element
authorization things you mention below.

What I mean is that it is probably useful to have a feature like a black
list, a white list and a gray list (you don't need all three, a black list
and gray list will do or a white list and gray list).
Maybe this is just an implementation issue. I think we can do with the
current presence authorization rules. It should be possible for the PS
(Policy Server) to construct these lists from the authorization policy.

P.S.: Maybe the idea of black/white/gray lists have been discussed before. I
don't know. I only recently subscribed to the mailing list.

Greetings,
Stefan.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: woensdag 13 oktober 2004 18:14
> To: [email-masked]
> Cc: Goeman Stefan; [email-masked]
> Subject: Re: [Simple] Presence Authorization Discussion B: 
> Composition/Auth Sequencing
> 
> 
> Markus,
> 
> I don't follow you - I think the point you make is backward.
> 
> First I want to clarify that we are talking about authorization on an 
> element-by-element basis within the document, as has been proposed.
> 
> I also want to assume that that the composer has broad 
> lattitude it what 
> it does, and in particular that it is free to construct elements that 
> didn't exist in any of the inputs. (E.g. it might construct an 
> <activity> of on-the-phone from other inputs that didn't include any 
> <activity> element.)
> 
> With those assumptions, an authorization policy that precedes and is 
> independent of composition policy can be ineffective. It may not 
> authorize inclusion of an <activity> element, but may authorize the 
> elements that the composer will use to infer it.
> 
> To get the intended result in this case, authorization must follow 
> composition.
> 
> 	Paul
> 
> [email-masked] wrote:
> > Hi Stefan and all,
> > 
> > I agree that it is actually hard to separate composition 
> and authorization from each other if both of them are 
> watcher-dependent. (And I think there is some value that even 
> composition can be watcher-dependent, such as the ability to 
> show different person information to different watchers.) But 
> if you assume that the same rulemaker makes rules for both 
> functions, the rulemaker can at least in theory keep things 
> consistent even if composition happens first and 
> authorization after that. But if the composition policy is 
> not understood by the auth policy rulemaker AND composition 
> happens first, he can't make even auth rules that have a 
> deterministic outcome. At the moment, before the details of 
> composition policy are defined, we are at this kind of situation.
> > 
> > Markus 
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]]On Behalf
> >>Of ext Goeman Stefan
> >>Sent: 13 October, 2004 13:08
> >>To: [email-masked]'
> >>Subject: RE: [Simple] Presence Authorization Discussion B:
> >>Composition/Auth Sequencing
> >>
> >>
> >>Hello,
> >>
> >>I would agree on the order of first composition and then 
> >>authorization in
> >>the case that composition would be watcher independent.
> >>
> >>But in light of the discussion of watcher dependent 
> >>composition I would
> >>favor the other way around (first authorization and the 
> composition).
> >>Because, does it make sense to do a watcher dependent 
> >>composition and spent
> >>time and processing power on it, to find out later that you 
> >>will block this
> >>watcher.
> >>
> >>Greetings,
> >>Stefan.
> >>
> >>
> >>>-----Original Message-----
> >>>From: [email-masked] 
> >>>[mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> >>>Sent: maandag 11 oktober 2004 9:43
> >>>To: Simple WG
> >>>Subject: [Simple] Presence Authorization Discussion B: 
> >>>Composition/Auth Sequencing
> >>>
> >>>
> >>>We had a lot of list discussion at some point about whether 
> >>>composition 
> >>>came first or whether authorization came first, and about 
> >>>where the line 
> >>>between one ended and the next began.
> >>>
> >>>I think this is much clearer now in light of the data model, 
> >>>which very 
> >>>explicitly separates the roles of composition (correlation, 
> >>
> >>conflict 
> >>
> >>>resolution, merging and splitting) and privacy filtering based on 
> >>>authorization rules. The former happens first. Indeed, I 
> >>>think the data 
> >>>model gives us a good grounding to start a discussion later 
> >>
> >>on about 
> >>
> >>>what we might want composition policy documents to look like. 
> >>>But lets 
> >>>hold that off until we finish our basic work.
> >>>
> >>>Thanks,
> >>>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
> >>>
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/simple
> >>
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Oct 2004 09:55:32 -0400

> (Policy Server) to construct these lists from the authorization policy.

There clearly is a distinction between whether a subscription is to be 
accepted, and what is to be disclosed once it is accepted. These need to 
be processed separately because they are handled at different points in 
time. (Obviously the decision to accept the subscription or not happens 
first, and typically only once per subscription. The decision about what 
to disclose must be repeated every time there is new presence state 
available.)

Exactly how the policy is implemented is not something the IETF should 
decide. The data model provides an abstract model of how it *might* be 
implemented, but isn't normative. As an implementor, you are perfectly 
free to partition the policy processing in a way that you find more 
optimal, as long as you preserve the result.

Here we need to be clear about the semantics of the policy so that 
different implementations are consistent. And it would be good to define 
things in such a way that an efficient and compliant implementation is 
possible.

	Paul