Subject: RE: [Simple] Changes in xcap-auth

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

> -----Original Message-----
> 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>
>      <domain>example.com</domain>
>    </except>
> </applies-to>
> 
> is in direct opposition to what Geopriv does, which is the 
> subject of a thread:
> https://www1.ietf.org/mail-archive/working-groups/geopriv/curr
ent/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
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Oct 2003 10:03:53 -0500

> similar make it very difficult to fulfil our requirements since you can

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.

> determine the final permission. this is a result of the permit-only design

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.

> a) is it really required and

I'm not sure what you mean by groups?

> features (which prevents unintentional disclosure of privacy related

It seems simple and geopriv are aligned on these goals.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Oct 2003 10:03:53 -0500

-Jonathan R.