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

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

Hello,

I think the black list aproach still has advantages in some situations
where I'm afraid the white list model may cause another privacy issue.

In a situation like CUG services where the service providers give
admittance to some privileged people, they may see benefits of
accessing to/being accessed by unknown people except some malicious
people. If there are no way to specify the policy like "anybody but
those identified people," they need to list every member, who
otherwise might not be identified/revealed by those people until some
time later.

I think the services should decide which model they support. Some
services may disallow statements giving a permission to 'any' or a
permission including an except clause.

I would expect the specification itself should support both models.

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
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri Nov 7 02:38:31 2003

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