Subject: RE: [Simple] Presence Authorization Discussion B: Composition/AuthSequencing

From: [email-masked]
Date: Thu, 28 Oct 2004 15:17:41 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext [email-masked]
> Sent: 14.October.2004 02:18
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Simple] Presence Authorization Discussion B:
> Composition/AuthSequencing
> 
> 
> 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.
> 

Referring to Figure 4 in the date model, can't we assume that the composition policy applied before the privacy filtering DOES NOT merge all <person> elements into one, but the post-processing composition does. So, the privacy filtering and watcher filtering may in fact do that for you by eliminating <person> elements. But if even after applying those privacy and watcher filters, we still have 2 or more <person> elements, then the post processing composition can do the merging.

The post processing composition is definitely watcher specific. If we can identify what should be watcher specific composition policy what should be not, then we can assume that the first composition is independent of watchers.

How about that?

/Hisham

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