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

From: Jonathan Rosenberg ^lt;jdrosen@dynamicsoft.com>
Date: Mon Nov 03 2003 - 20:05:31 EST

Henning Schulzrinne wrote:

> [Starting clean...]
>
> There are two somewhat separate issues:
>
> (1) Splitting into domain and user components, i.e., we could have
> permissions that apply to all users in a domain and some that apply to
> only specific users. That, by itself, does not break the additive model,
> if specific users have at least the permissions of the specific users
> within the domain.
>
> While I don't believe that, in practice, domain-specific permissions are
> all that useful for organizations of non-trivial size, the model of
> "everybody within domain gets baseline permissions, special people get
> more" seems plausible.

In particular, this seems to be a common cases for many small to
medium enterprises, where "domain" is the domain of the enterprise.

> (2) I share Hannes concern about making exceptions on any field,
> including the user or domain match. I don't see the real-world
> motivation for this and it complicates the conceptual model. (In the
> geopriv interim we discussed at length as to why blacklists are
> generally a bad idea, even with authentication, unless you can guarantee
> that the bad guys you want to keep out can't change their verified
> identity to a new one.)

I think this is a legitimate complaint for the case "accept anyone
EXCEPT for Joe". However, for the case "accept anyone from example.com
EXCEPT Joe", I dont think this concern is applicable. There, it is not
so easy for the user to change their identity to a new one. The
classic use case would be a company where I initially allow anyone in
my enterprise, but then this one bothersome employee keeps pestering
me for information every time I log in, and I want to put him on my
black list so he doesnt see my status anymore. This seems like a
legitimate case.

Also, another case where except clauses make sense is where I want
different information provided to different people. For example,
everyone in my company sees my cell phone status and my PC status,
except for that annoying Joe again, who only sees my PC.

My main point, however, is that none of my arguments above are
specific to presence as opposed to geopriv. If blacklists are bad for
geopriv, they are also bad for presence, and vice a versa.

>
> At one point, I thought the basic design principle was that we weren't
> done until we couldn't *remove* any features - with policies, it's
> always tempting to pile on more and more "could be useful somewhere"
> items, so I think proponents of particular items should be held to a
> fairly high standard of proof as to why a particular feature is
> absolutely, positively necessary for a first version. In the geopriv
> draft, we spend some time talking about future extensions and how they
> are privacy-safe under certain baseline assumptions. We can't anticipate
> all the things that we might need and the things that turn out to be
> less than useful in practice, so I'd much rather start clean and small
> and then expand based on implementation experience. We just don't have a
> whole lot (if any) experience with policy languages or rule sets in the
> IETF.

I am with you on removing features, and as you can see have taken the
axe to xcap-auth in a pretty serious way. I am also totally in
agreement with the value of something being privacy-safe. I think the
concerns about except-clauses in the applies-to section only apply
when the except-clauses reference external lists. I see several
options there:

(1) don't allow except clauses to reference external lists at all

(2) allow them to reference lists present only on the same server

(3) AND/OR if the list cannot be obtained, then the permissions in the
associated statement are granted to NO ONE.

I believe that (1), (2,3) or (3) would make the except clause privacy
safe.

-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 3 23:22:23 2003

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