[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Simple] Presence Authorization Discussion B: Composition/Aut h Sequencing
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:pkyzivat at cisco.com]
> Sent: woensdag 13 oktober 2004 18:14
> To: Markus.Isomaki at nokia.com
> Cc: Goeman Stefan; 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.)
>
> 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
>
> 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