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

From: Jonathan Rosenberg ^lt;jdrosen@dynamicsoft.com>
Date: Mon Nov 10 2003 - 16:52:15 EST

Henning Schulzrinne wrote:

> Jonathan Rosenberg wrote:
>
>> I agree that groups are a separate issue.
>>
>> However, in xcap, it currently does allow for things like "applies to
>> everyone on golf-list, but Joe". It does that by having each group
>> defined by an xcap resource (i.e., an http URI) that can be used to
>> fetch the group list. Then, membership in the group is determined by
>> authenticating as one of the identities in that group.
>>
>> If you can't fetch the list, the permission isnt granted, and thus its
>> privacy safe.
>
>
> Clearly, fetching group lists adds significant complexity: expiration
> (presumably you don't want to fetch it every time) and the inability,
> without significant overhead, to implement a permission system using any
> reasonably efficient query mechanism.

I think the required functionality should drive the protocol choices
and implementation, not the other way around.

That said, it is certainly possible to have efficient implementations
of policies that involve an external fetch of a group. This is not a
radically new concept. You can do a really good job at it when the
lists are in the same administrative domain as the location server, as
then you can in fact do various kinds of cached optimizations.

>
>>
>> If, for some reason, a user specifies a rule based on a list in
>> another domain, with members in other domains, the server can't
>> authenticate those users, and thus permissions are not granted, and
>> thus its privacy safe.
>>
>> You *would* have problems if you could have an exception defined by an
>> external list, but I agree we shouldnt do that.
>>
>> So, given this design and assumptions, I dont see a problem with
>> groups per se. There is a scope question, but I dont see a technical
>> problem.
>
>
> It just makes efficient implementation difficult to impossible.

As I mentioned above, this is not a radically new capability. Policies
based on external lists are not a new concept.

That said, I would be willing to buy that this is out of scope for the
initial revision of the specs.

> I would also like to get consensus to rule out random wildcard matching
> and, less importantly, domain exceptions. Thus,
>
> applies-to: foo.*.example.com
>
> and
>
> applies-to: example.com
> except cs.example.com
>
> seem far less useful and add significant complexity.

Agreed these are out of scope.

-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 Mon Nov 10 16:55:22 2003

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