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

From: Naoko ITO ^lt;naoko@netlab.nec.co.jp>
Date: Fri Nov 07 2003 - 02:37:43 EST

Hello,

I think a separate excepton list is very useful, corresponding to the
exact concept of 'black list.'
Still, I'd like to have an except clause in a permission statment as
well, which can be used for a differenct purpose, i.e., giving
different permissions to some groups of the watchers.

I don't understand why the except clause in each permission statement
should be dismissed while the separate exception list model can be
supported.

1) introducing a separate exception list but not supporting it,
2) introducing an except clause in each permission but not supporting
  it.

In the case of Option #1, the rule enforcer should drop all the
permission statements in the rule set in order to prevent those
should-be-excepted watchers from accidentally obtaining information, if
there is an exception statement which cannot be understood. i.e., no
permission is granted to anybody at all. In the case of Option #2, the
rule enforcer should drop the permission statements with unknown except
clauses, which still allows some watchers to obtain information. It
seems to me that both options give us the ways to ensure the
privacy-safe even if the rule enforcer does not support the except
mechanism, and rather the latter is more elastic or fault-tolerant. Or
is this just plausible?

As for maintaining the row-model, I don't think the former model
maintains the row-model, while the entire rule set has no meaning if
the actual rule set once has an exception statement. If it means not
supporting the exception at all, the same thing can be done with the
except clause in each permission.

I see no reason to dismiss the latter approach and would suggest to
keep both.

Regards,
-----
Naoko Ito / NEC

----- Original Message -----
From: "Henning Schulzrinne" <hgs@cs.columbia.edu>
To: <hardie@qualcomm.com>
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>; "Tschofenig Hannes"
<hannes.tschofenig@siemens.com>; "'Rosen, Brian'"
<Brian.Rosen@marconi.com>; "Simple WG" <simple@ietf.org>;
<geopriv@ietf.org>
Sent: Friday, November 07, 2003 10:28 AM
Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth

> If there is consensus that we really can't avoid exceptions, I would
> suggest a variation of Ted's approach, namely to have a clear,
separate
> exceptions list:
>
> - First, consult the exceptions list. If there's a match in the
> exceptions list, there is no need to consult the second list. If the
LS
> or PA can't access the exceptions list, the system delivers no
> information and fails hard for that delivery destination. The
exception
> list permits no inclusions, no all-within-domain wildcards and no
> external references. (Permissions within the exceptions list are
still
> additive.)
>
> - If no match, consult the normal additive-privileges list, with no
> exceptions.
>
> This supports the all-20,000-Columbia-employees except Alice and Bob,
> but does not support Columbia-except-the-EE-department.
>
> This has the advantage that the row-model is maintained, rather than
> having lists of exceptions attached to each rule.
>
> GEOPRIV might then decide not to support the exception list type, but
> the regular list type would be compatible.
>
> Blacklists were popular for spam-protection early on, but I think
> everyone has realized by now that they are close to useless. I'd hate
to
> create a complicated, brittle, difficult-to-predict system just to
find
> out a year later that this expensive feature turned out to be mostly
an
> empty promise, in terms of increasing user privacy.
>
> Note that I'm not advocating the solution - I'd rather not add the
> complexity and I'm not sure whether I have caught all the possible
> failure cases.
>
> It would be helpful if others would speak up, as this is an important
> issue to settle, soon.
>
> hardie@qualcomm.com wrote:
> > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote:
> >
> >>not sure I follow. I work for dynamicsoft.com. All URIs in my
domain are user@dynamicsoft.com. I'd like a policy which allows anyone
in dynamicsoft.com, but blocks a few irritating people, say joe and
bob. So, I would have a policy like this:
> >>
> >><applies-to>
> >> <domain>dynamicsoft.com</domain>
> >> <except>
> >> <uri>joe@dynamicsoft.com</uri>
> >> <uri>bob@dynamicsoft.com</uri>
> >> </except>
> >></applies-to>
> >>
> >>Where is the complexity here?
> >
> >
> >
> > The complexity here from the GeoPriv side is really in how additive
permissions are
> > meant to work. In order to ensure that the privacy policy is
always within the
> > user's tolerance, the theory has been to have a very small set of
"grants" that
> > are then always modified by addition. If the URI at which a
specific addition
> > is made is not available (or the object in which it is contained is
not decryptable),
> > then the results may be less than optimal, but there are no
untoward
> > privacy consequences, as there can never be a "grant statement"
that takes
> > something away. We talked about "except" in particular at the
interim meeting
> > and, from my memory, we had good agreement that "except" was
powerful,
> > interesting, but conflicted enough with the core theory and the
needed functionality
> > that it wouldn't be a phase one.
> >
> > Could I suggest that we consider splitting <applies-to> into two,
one of which
> > has except and one does not? We could have <applies-to> and
<restricted-applies-to>.
> > The first would be the basic grant:
> >
> > <applies-to> <domain>example.com</domain></applies-to>
> >
> > where the second would allow:
> >
> > <restricted-applies-to><domain>example.com</domain>
> >
<except><uri>joe@example.com</uri></except></restricted-applies-to>.
> >
> > I think that would enable us to overlap a lot of the xcap language
between SIMPLE and
> > GEOPRIV, but allow GeoPriv to punt implementation of
<restricted-applies-to> until
> > a later time when it has worked out more of the surrounding
infrastructure. It is
> > inelegant, I know, but GeoPriv is now working under pretty heavy
time pressure, and
> > this looks like the most direct way to hack past the problem
without losing
> > the basic overlap.
> > regards,
> > Ted Hardie
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri Nov 7 03:37:23 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST