Subject: [Simple] Presence Authorization Discussion B: Composition/Auth Sequencing

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

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

---

From: [email-masked]
Date: Thu, 14 Oct 2004 02:17:49 +0300

Hi Paul,

See inline.

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 13 October, 2004 19:14
> To: Isomaki Markus (Nokia-TP/Espoo)
> Cc: [email-masked]; [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.)
> 

I think both of these assumptions are ok.

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

Yes, I understand the case you explain above, and I accept your conclusion.

> To get the intended result in this case, authorization must follow 
> composition.
> 

Right. But aren't there potential issues with this approach too if the composition policy is unknown to the auth rulemaker? For instance if multiple tuples are composed into one, and I have rules granting access to tuples that are no longer present. Well, I guess you might argue this is a feature and not a bug. So perhaps the only thing to point out is that if you want to give e.g. different person elements to different watchers, the composition should not loose that variety. This means that the composition that occurs before authorization can't have strict requirements like that only a single person element is allowed as an end result.

> 	Paul

Markus

> 
> [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
> >>>
> >>>
> >>>explicitly separates the roles of composition (correlation, 
> >>
> >>conflict 
> >>
> >>>model gives us a good grounding to start a discussion later 
> >>
> >>on about 
> >>
> >>>Chief Technology Officer                    Parsippany, NJ 
> >>
> >>07054-2711
> >>
> >>>dynamicsoft