Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments

From: [email-masked]
Date: Thu, 10 Jul 2003 12:17:48 +0300

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2003 10:38 AM
> To: Leppanen Eva-Maria (NET/Tampere)
> Cc: [email-masked]
> Subject: Re: [Simple] I-D
> ACTION:draft-ietf-simple-xcap-auth-usage-00.txt -> comments
> 
> 
> Thanks for the comments. Responses inline.
> 
> [email-masked] wrote:
> 
> > Hi,
> > 
> > I found the draft very versatile. Please find below some comments
> > and questions:
> > 
> > * "Acceptance permissions" include elements where the acceptance
> > can be based on the filter information. However the security
> > considerations of the "Presence Filter Requirements" I-D recommends
> > as follows: "The filter criteria should not be rejected based on
> > the authorization policy since this would enable the watcher by
> > experimentation with the use of filter criteria to determine the
> > authorization policy the presentity has set for him and thus
> > discover what the presentity wants to hide from him".
> 
> I think the requirement in the filter requirements doc is not worded 
> properly. I think the proper wording is that "It should be possible 
> for the server to hide the fact that their filter was not acceptable. 
> In such a case, the subscription would be accepted, but they 
> would not 
> neccesarily get all of the information that was requested.". This 
> means that it is the CHOICE of the presentity about whether the 
> watcher is informed of the rejection, or if their filter is silently 
> ignored.
> 
> So, if a presentity wanted to reject the subscription based on the 
> filter, they would use the acceptance permissions to do that. If they 
> wanted, instead, to simply limit what the watcher sees, they 
> would use 
> the content permissions and other permissions as needed.

I'll expand this a little

You have an acceptance permission statement that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
   <permission-statements>
     <statement id="as8f">
       <applies-to>
         <uri>sip:[email-masked]</uri>
       </applies-to>

       <permissions>
         <accept-if>
          <and>
            <not>
               <requested-element>pidf:contact</requested-namespace>
            </not>
          </and>
         </accept-if>
       </permissions>

     </statement>
   </permission-statements>

Now, the filter that arrives asks explicitly for pidf <contact> element for be put in the NOTIFY. This evaluates to false using the acceptance permission statement above and results in the subscription being rejected.

What we want is for this subscription to be accepted and the filter to be accepted, but not necessarily honoured. So, in the auth usage draft, there needs to be mentioned that if an acceptance permission statement evaluates to true, a permission may still be granted (polite blocking), but the presentity must add a corresponding  content permission that removes <contact> element from the PIDF document (using the <not> element as Eva suggested below).

The other and probably better alternative (which I think is that Jonathan is suggesting, will you document?) is to document that if a presentity wants polite blocking, then it sets acceptance permissions to <accept/> and uses the content-permissions to block sending of un authorised info. So the example above becomes:

<?xml version="1.0" encoding="UTF-8"?>
   <permission-statements>
     <statement id="as8f">
       <applies-to>
         <uri>sip:[email-masked]</uri>
       </applies-to>

       <permissions>
         <accept/>
         <not>
            <show-element>pidf:contact</show-element>
         </not>
       </permissions>

     </statement>
   </permission-statements>

Regards,
Hisham

> 
> > 
> > * "Identifying elements" chapter says: "...that element is used as
> > an input to the computation of other elements..." -> what if a
> > certain element's value is derived from two published elements (the
> > other is authorized but the other not)? Does the "raw piece of
> > presence data" mean (in practise) that the identified element is
> > the same as (raw) published element, but it is changed by the
> > composer? This could be specified more clearly - it's somehow too
> > vague for a specification of authorization.
> 
> Yes, I agree its vague. To make it less vague, you need to have a 
> model that defines how the PA computes views of presence, so you can 
> describe the impact of these policies. I think what I had in mind is 
> that you have some raw presence data, denoted by R. Then, there is 
> some transformation T which is applied to R, which determines the 
> presence document to be shown to a watcher.
> 
> So, if the permission only allows elements X, Y and Z to be 
> known to a 
> watcher, the raw presence document R would be stripped of everything 
> except X, Y and Z, and then the transformation R is applied.
> 
> 
> > 
> > * The tuple IDs are used for identifying the whole tuples in the
> > "content permissions". Is there some reason why only the tuple ID
> > can be used, and not to allow any XML element (e.g., nested
> > element-name/element-path elements to "show-tuple")? 
> 
> Thats the purpose of the "show-element" permission.
> 
> * The "not"
> > condition might be usable for denying a specific XML element,
> > namespace, value etc (in the content permissions). Using the
> > current premissions it is only possible to make a list of all
> > allowed items, but not to say that "allow everything else except
> > this information".
> 
> Thats a good idea. I'll add something to do this.
> 
> 
> > 
> > * One element in transformational permissions is "set-document"
> > which allows e.g. defining a document including "lies". I was
> > wondering whether the purpose was to use this also for allowing the
> > presentity to define multiple level of details of the semantically
> > same presence information? 
> 
> Not sure I follow what you mean by this.
> 
> > Somehow I see the solution too fixed for
> > that purpose. The presentity might want to define e.g. different
> > notes to different watchers or different deltails of location
> > information. 
> 
> You could define different notes to different watchers using the 
> set-element permission. Differing details of location information - I 
> think we'll need to nail down a lot more about how location 
> information is represented before we tackle that. geopriv is finally 
> making some progress, so it will be soon I think...
> 
> 
> > This kind of information changes more often and is
> > more dynamic compared to the other authorization related
> > information. The proposal is to handle the different levels of
> > values within publishing, but the authorization solution should
> > support linking different levels of values to different watchers or
> > groups of watchers.
> 
> Not sure I follow that...
> 
> > 
> > * A comment about defining "union" for combining multiple
> > "statement" elements: this is a good approach for many purposes,
> > but depending on how the presence information (and tuples) are
> > structured, there might be a need to define e.g. that the showed
> > value to "[email-masked]" should be "closed" but it should be "open"
> > to "[email-masked]". The "first" match principle/ or the most
> > specific address principle would be more suitable in this case. It
> > seems that both of them would be needed.
> 
> Interestingly, your example is about transformational attributes. 
> Those, as I think I comment in the spec, are not really 
> "permissions", 
> and don't compose as well as the others. There, I am inclined 
> to agree 
> that a different combination operation is needed. Defining the match 
> with maximal specificty isnt always easy, though. What happens if a 
> watcher is on a list, and one statement is said to apply to 
> users on a 
> list, and another statement applies to that user specifically? Both 
> have the same level of specificity.
> 
> That said, with the exception of transformational policies, I think 
> union works well under the assumption that applies-to REALLY says who 
> it applies to. So, if you say that some permission is granted to 
> everyone in the example.com domain, that means everyone. If you want 
> to create an exception, you would need to do it by creating an 
> exception within the applies-to statement.
> 
> So, how about something like an <except> element, so that you 
> could do 
> this:
> 
> <applies-to>
>    <domain>example.com</domain>
>    <except>sip:[email-masked]</except>
> </applies-to>
> 
> 
> > 
> > * What is the relation of the "set-document" to the default and/or
> > hard state publishing? Is the purpose that there will be an own
> > usage for hard state publishing?
> 
> Good question. I thought about this a bit. Originally, I had thought 
> they were the same. But, now, I dont think they are. Hard-state state 
> publishing sets one presence document of many that are input to 
> composition. set-document says that composition is not done at all, 
> and that a specific document is to be sent.
> 
> One solution would be to add a new permission called "add-document" 
> which contains a presence document that is to be placed as input to 
> the composition policy. That would seem to work for hard 
> state publishing.
> 
> -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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jul 2003 11:16:26 -0400

inline.

[email-masked] wrote:

> Now, the filter that arrives asks explicitly for pidf <contact>
> element for be put in the NOTIFY. This evaluates to false using the
> acceptance permission statement above and results in the
> subscription being rejected.

Right.

> 
> What we want is for this subscription to be accepted and the filter
> to be accepted, but not necessarily honoured. So, in the auth usage
> draft, there needs to be mentioned that if an acceptance permission
> statement evaluates to true, a permission may still be granted
> (polite blocking), but the presentity must add a corresponding
> content permission that removes <contact> element from the PIDF
> document (using the <not> element as Eva suggested below).

Right.

> 
> The other and probably better alternative (which I think is that
> Jonathan is suggesting, will you document?) is to document that if
> a presentity wants polite blocking, then it sets acceptance
> permissions to <accept/> and uses the content-permissions to block
> sending of un authorised info. 

Right. Isn't that what you just suggested in the paragraph above?

I do think its useful to document this, and to make specific metnion 
of how polite blocking is done. Probably what the document needs is 
both explanatory text and some good examples that show things like 
this. I will do for the next rev.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jul 2003 11:16:26 -0400

inline.

Right.

Right.

-Jonathan R.