[Geopriv] RE: [Simple] Changes in xcap-auth

hi jonathan,

thanks for your comments.

>
>
> Tschofenig Hannes wrote:
>
> > hi brian,
> >
> > you raised several issues here:
> >
> > to simplify conflict resolution and to prevent leaking of
> information we
> > have tried to make the policies simpler. hence you only
> have permit-only.
> > furthermore, due to the nature of geopriv we need to
> support additive
> > permissions. policies which implement everything-except for
> xy or something
> > similar make it very difficult to fulfil our requirements
> since you can
> > easily create conflicts.
>
> xcap-auth also only uses additive permissions. The applies-to section
> is the ONLY place which specifies exceptions. These exceptions only
> specify to whom a particular permission applies. Thus, there are no
> conflicts. From the introduction:
>
> > granted to those watchers. The concept of a permission is
> central to
> > this specification. A permission is an atomic statement
> of consent. A
> > permission can indicate a condition under which a subscription is
> > accepted or rejected, a condition under which a
> notification is or is
> > not sent, or a piece of information which is revealed in
> a presence
> > document. The overall authorization for a watcher is
> represented by
> > the union of the permissions granted to that watcher.
>
i guess we should have used a different term here in our draft. it might
create confusions.

immagine the following case: you have two rule sets (A and B).

rule set A specifies:
everyone from <group>dynamicsoft.com<group> is allowed to access location
information of henning with granularity X and is allowed to distribute it
further to other people.

rule set B specifies:
access to location info for henning is allowed with ... except for
jdrosen@dynamicsoft.com.

the problem here: policies are allowed to be distributed in geopriv and can
always have the case where you cannot access rule set B (e.g., external
reference does not work). hence the additional rule set (B in this case)
should only add permissions and should revoke some of them.

>
>
>
> >
> > with the policies defined today you have to search through
> all of them to
> > determine the final permission. this is a result of the
> permit-only design
> > criteria.
>
> I do not think an xcap implementation would need to search
> through all
> statements to determine which ones apply. We are *not* supporting
> general regular expressions. Statements apply to domain, URI (either
> listed explicitly or reference from another list), or anyone - thats
> it. There are no other granularity of permissions. THe implication is
> that an implementation can easily compute two tables, one indexed by
> URI, and one by domain, which point to the relevant permissions for
> that uri or domain.

as described in our document you have to search through the entire table
(conceptually) since you might have several matches and the final permission
is computed based on the set of firing rules.
however, i agree with you that an actual implementation might have several
choices to use internal data structures. by leaning on a relational database
model you could certainly benefit from optimization techniques known there
to make the access more efficient.

if you look at regular packet filtering mechanisms then you do not compute
the permissions of the entire rule set. instead you often terminate once you
have the first match (i.e., rules are typically ordered). we do not want
such an ordering.

>
> >
> > with regard to the default rules we are still discussing
> how to support them
> > without introducing too many problems.
> >
> > supporting groups is another issue. there are certainly
> ways to add more
> > functionality here but
> > a) is it really required and
> > b) is it simple enough
>
> I'm not sure what you mean by groups?

group: an identifier which refers to a group of people instead of only an
individual.

>
> >
> > as an example: if you simply use the authenticated entity
> and you strip-off
> > the user-name part to compare whether this user belongs to
> a certain group
> > then you need to understand the structure of the identity.
> the identity
> > depends on the authentication protocol and these identities
> might have a
> > different structure (e.g. sip uri, nai, x.500, kerberos principal
> > names,etc.). i can think of other approaches which are
> simpler but they
> > might have other problems which we haven't thought of yet.
> >
> > in the past we have already considered some approaches
> which are much more
> > powerful and flexible. our goal was to create something
> simple without fancy
> > features (which prevents unintentional disclosure of privacy related
> > information).
>
> It seems simple and geopriv are aligned on these goals.

that's great. over the past few months we tried to align the two
authorization policies.

ciao
hannes

>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Chief Technology Officer Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri Oct 31 10:31:21 2003