Subject: [Simple] Changes in xcap-auth

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Oct 2003 10:17:43 -0500

Folks,

As you may have noticed, I submitted a revision of the xcap-auth spec. 
There were many changes since the last rev. Mainly, I cut lots of 
stuff out in order to vastly simplify:

* added an "except" clause to applies-to, so that you can make 
exceptions for specific users, domains, or lists. This allows, for 
example:

<applies-to>
   <any/>
   <except>
     <domain>example.com</domain>
   </except>
</applies-to>

* accept-if permission exists still, but boolean expressions are removed.

* Removed rule permissions (which specified state changes which would 
cause a notification to be sent)

* Removed transformational permissions. I still think this capability 
is important, but per list discussion, we will tackle it by having a 
separate entity publish false presence information, and then use 
xcap-auth to select those tuples for distribution to certain watchers.

* removed requested-namespace, requested-element, requested-tuple, 
duration accept-if conditions

* show-tuple content permission now selects a tuple(s) by the RPID 
class attribute

* removed show-values content permission

* removed the compound permission AUID - can do it later

* The show-element content permission selects elements based on their 
qualified name (i.e., rpid:placetype) in an XML document - no xpath 
expressions.

* clarified that, for show-element and show-namespace, if a permission 
is not there, those elements in published tuples are discarded BEFORE 
the composition process.

There are a few to-dos that I wasnt able to get around to. Besides 
that, I think this is much closer to done. There are still some open 
issues, which I will post notes on. There is also a big question 
around how/if the geopriv policy format aligns with this. The other 
main question is scope - is there anything else we can remove, or 
anything that is ESSENTIAL now which we should add?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Oct 2003 11:59:36 -0500

Wellllllll

You will note that:
<applies-to>
   <any/>
   <except>

is in direct opposition to what Geopriv does, which is the 
subject of a thread:
https://www1.ietf.org/mail-archive/working-groups/geopriv/current/msg00080.h
tml

In short, geopriv-policy <applies-to> is specifically designed to 
have a single URI, so that you don't need to linear search and evaluate 
a set of rules to find out which one(s) apply to the request. 
<any>, <domain> and <except> would be precisely what geopriv-policy
is trying to avoid.

I'd prefer the xcap approach.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, October 30, 2003 11:38 AM
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] Changes in xcap-auth
> 
> 
> 
> > which I will post notes on. There is also a big question 
> around how/if 
> > the geopriv policy format aligns with this. The other main 
> question is 
> 
> To provide some background to those not following the GEOPRIV 
> discussions:
> 
> For whatever reason, the I-D editor doesn't seem to have posted the 
> document yet, even though it was submitted in time. In any 
> event, it's at
> 
> http://www.cs.columbia.edu/sip/draft/authz/draft-ietf-geopriv-
> policy-00.html
> 
> Henning
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 30 Oct 2003 11:59:36 -0500

Wellllllll

You will note that:
<applies-to>
   <any/>
   <except>

Brian

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 31 Oct 2003 10:25:42 +0100

hi brian, 

you raised several issues here:

to simplify conflict resolution and to prevent leaking of information we
have tried to make the policies simpler. hence you only have permit-only.
furthermore, due to the nature of geopriv we need to support additive
permissions. policies which implement everything-except for xy or something
similar make it very difficult to fulfil our requirements since you can
easily create conflicts. 

with the policies defined today you have to search through all of them to
determine the final permission. this is a result of the permit-only design
criteria. 

with regard to the default rules we are still discussing how to support them
without introducing too many problems. 

supporting groups is another issue. there are certainly ways to add more
functionality here but
a) is it really required and
b) is it simple enough

as an example: if you simply use the authenticated entity and you strip-off
the user-name part to compare whether this user belongs to a certain group
then you need to understand the structure of the identity. the identity
depends on the authentication protocol and these identities might have a
different structure (e.g. sip uri, nai, x.500, kerberos principal
names,etc.). i can think of other approaches which are simpler but they
might have other problems which we haven't thought of yet. 

in the past we have already considered some approaches which are much more
powerful and flexible. our goal was to create something simple without fancy
features (which prevents unintentional disclosure of privacy related
information). 

ciao
hannes

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, October 30, 2003 6:00 PM
> To: 'Henning Schulzrinne'; Jonathan Rosenberg
> Cc: Simple WG
> Subject: RE: [Simple] Changes in xcap-auth
> 
> 
> Wellllllll
> 
> You will note that:
> <applies-to>
>    <any/>
>    <except>
tml

Brian

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 31 Oct 2003 16:30:18 +0100

hi jonathan, 

thanks for your comments.

> Tschofenig Hannes wrote:
> xcap-auth also only uses additive permissions. The applies-to section 
> is the ONLY place which specifies exceptions. These exceptions only 
> specify to whom a particular permission applies. Thus, there are no 
> conflicts. From the introduction:
> 
> >  granted to those watchers. The concept of a permission is 
> central to
> >    this specification. A permission is an atomic statement 
> of consent. A
> >    permission can indicate a condition under which a subscription is
> >    accepted or rejected, a condition under which a 
> notification is or is
> >    not sent, or a piece of information which is revealed in 
> a presence
> >    document. The overall authorization for a watcher is 
> represented by
> >    the union of the permissions granted to that watcher.
> 
i guess we should have used a different term here in our draft. it might
create confusions. 

immagine the following case: you have two rule sets (A and B). 

rule set A specifies: 
everyone from <group>dynamicsoft.com<group> is allowed to access location
information of henning with granularity X and is allowed to distribute it
further to other people. 

rule set B specifies: 
access to location info for henning is allowed with ... except for
[email-masked]. 

the problem here: policies are allowed to be distributed in geopriv and can
always have the case where  you cannot access rule set B (e.g., external
reference does not work). hence the additional rule set (B in this case)
should only add permissions and should revoke some of them. 

> I do not think an xcap implementation would need to search 
> through all 
>   statements to determine which ones apply. We are *not* supporting 
> general regular expressions. Statements apply to domain, URI (either 
> listed explicitly or reference from another list), or anyone - thats 
> it. There are no other granularity of permissions. THe implication is 
> that an implementation can easily compute two tables, one indexed by 
> URI, and one by domain, which point to the relevant permissions for 
> that uri or domain.

as described in our document you have to search through the entire table
(conceptually) since you might have several matches and the final permission
is computed based on the set of firing rules. 
however, i agree with you that an actual implementation might have several
choices to use internal data structures. by leaning on a relational database
model you could certainly benefit from optimization techniques known there
to make the access more efficient. 

if you look at regular packet filtering mechanisms then you do not compute
the permissions of the entire rule set. instead you often terminate once you
have the first match (i.e., rules are typically ordered). we do not want
such an ordering.  

> I'm not sure what you mean by groups?

group: an identifier which refers to a group of people instead of only an
individual. 

> It seems simple and geopriv are aligned on these goals.

that's great. over the past few months we tried to align the two
authorization policies.

ciao
hannes

> -Jonathan R.

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 31 Oct 2003 16:30:18 +0100

hi jonathan, 

rule set A specifies: 

rule set B specifies: 

ciao
hannes