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

From: Jonathan Rosenberg ^lt;>
Date: Sat Nov 08 2003 - 01:11:52 EST


Henning Schulzrinne wrote:

>> I share Ito-san's confusion here. Assuming the same kind of
>> restrictions you have asked for - no external references, no
>> wildcards, no domain-scopes, I dont see the difference between:
>> <applies-to>
>> <domain></domain>
>> <except>
>> <uri></uri>
>> </except>
>> </applies-to>
>> and:
>> <applies-to>
>> <domain></domain>
>> </applies-to>
>> <exception-list>
>> <uri></uri>
>> </exception-list>
>> THe differences seem merely syntactic, but maybe I am missing
>> something here.
> GEOPRIV has, so far, insisted on allowing inclusions and others have
> insisted on wildcards. By separating the two tables, you can have
> inclusions and wildcards in the 'additive' table, and limit the
> restrictions to the exceptions table.

OK, I can agree to that, but again I dont see the need for a
physically separated listing. ALl you need to do is specify that the
set of elements in the exception list cannot be wildcarded.

> The WGs need to make an explicit choice between three options:
> (1a and 1b) Impose restrictions on table composition (no multi-stage
> policies, no dynamic composition and failure on non-reachability during
> static composition). In that case, exceptions can be made to work,
> either for a single table (case 1a; if the restrictions apply to that
> table) or as two tables (case 1b; if only the exceptions table is thus
> restricted).
> Dynamic composition = composing permissions while evaluating rules
> (e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference'
> parameter in draft-peterson-geopriv-pidf-lo-02.txt)
> Static composition = inclusion by reference when loading permissions
> into the LS or PA
> My understanding is that XCAP currently allows neither mode of
> composition, so the problem is not as pronounced there.
> I think it would be really confusing and error-prone if, say, the
> PIDF-LO 'ruleset-reference' could not include blacklists, while files
> uploaded from the RM into the LS could.
> (2) Allow dynamic composition, but no exceptions.

Again - the exceptions mechanism I am proposing does NOT have the
problem of causing leakage of information in the case that the rule
cannot be fetched, either in the static or dynamic cases.

>> There are some serious differences here with the email spam case.
>> Firstly, the systems we are talking about require authentication,
>> which is absent in email. Secondly, and perhaps most importantly, I am
>> not interested in rules like "allow anyone in the world but
>>", as I agree this is silly. We are talking about rules
>> like "allow only people from EXCEPT". That
>> is, I expect these systems to require a user to explicitly grant a
>> permission, but an extremely common case, I think, will be to grant it
>> by indicating a domain with a set of exceptions.
> Authentication is not terribly important here, but rather the ease of
> creating new identities within a domain.

They are related. Because of authentication, creation of a new
identity requires establishment of credentials for that identity.
Since this needs to be handled by the domain administrator, it seems
that it is much easier to manage these identities.

> Note, in particular, that the authenticated name in a SIMPLE context may
> or may not correspond 1-1 to the From identifier. There is nothing that
> prevents (or should prevent) allowing something like the foo+anything
> mechanism, with a single login (Digest) identity.
> Thus, a user who wants to use blacklists reliably has to have a fairly
> detailed understanding of the identity creation and authentication
> policies in the domain.
> I'm not arguing that they will never work, just that they will often
> fail in surprising ways.

To me, this feels like throwing away the baby with the bathwater.

Just because there will be domains with name allocation policies that
make it easy to get new names, does not mean that a system should
never support black lists. I believe that the need for authentication
in these systems will go hand in hand with identity management which
generally will make it hard to readily obtain new names (and in
particular, new names with new credentials). Of course, there can be
cases where this is not true. I'd rather deal with that using caveats
in the spec.

-Jonathan R.

Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft                     FAX:   (973) 952-5050                      PHONE: (973) 952-5000
Geopriv mailing list
Received on Sat Nov 8 01:13:22 2003

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