[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Presence Authorization Discussion B: Composition/Auth Sequencing
Hi Paul,
See inline.
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 13 October, 2004 19:14
> To: Isomaki Markus (Nokia-TP/Espoo)
> Cc: Stefan.Goeman at siemens.com; simple at ietf.org
> 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
>
> Markus.Isomaki at nokia.com 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: simple-bounces at ietf.org
> >>[mailto:simple-bounces at ietf.org]On Behalf
> >>Of ext Goeman Stefan
> >>Sent: 13 October, 2004 13:08
> >>To: 'simple at ietf.org'
> >>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: simple-bounces at ietf.org
> >>>[mailto:simple-bounces at ietf.org] 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
> >>>jdrosen at dynamicsoft.com FAX: (973) 952-5050
> >>>http://www.jdrosen.net PHONE: (973) 952-5000
> >>>http://www.dynamicsoft.com
> >>>
> >>>
> >>>_______________________________________________
> >>>Simple mailing list
> >>>Simple at ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>Simple at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/simple
> >>
> >
> >
> > _______________________________________________
> > Simple mailing list
> > Simple at ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >
>
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple