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

From: Alex Audu ^lt;alex.audu@alcatel.com>
Date: Fri Nov 07 2003 - 16:08:44 EST

All this is not too clear to me yet, but an exception can be viewed
simply as a form negative addition. Therefore it theoretically shouldn't
violate the "additive permissions theory".

The idea of a black list works fine in an enterprise type environment.
I think I see value in it.

Regards,
Alex.

Henning Schulzrinne wrote:

> 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 17:36:27 2003

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