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

From: [email-masked]
Date: Tue, 8 Jul 2003 13:45:16 +0300

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".

* "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.

* 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")? 
* 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".

* 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? 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. 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.

* 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.

* 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?

BR, Eva Leppanen

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: 25 June, 2003 17:55
Cc: [email-masked]
Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Extensible Markup Language (XML) Configuration Access 
                          Protocol (XCAP)Usages for Setting Presence 
                          Authorization
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-xcap-auth-usage-00.txt
	Pages		: 41
	Date		: 2003-6-24
	
This document describes three usages of the Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) that allow a
client to provide authorization decisions regarding watchers of their
presence. The first of these usages, called permission-statements,
contains statements about what permissions are to be granted to
watchers of presence. The second of these usages, called
compound-permissions, allows a client to define new permissions as
combinations of other defined permissions. The third usage, called
supported-permissions, allows a client to determine what permissions
are understood by the provider.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-xcap-auth-usage-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-xcap-auth-usage-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

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

> 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,
> > 
> > * "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
> 
>

---

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

> Sent: Thursday, July 10, 2003 6:16 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: Leppanen Eva-Maria (NET/Tampere); [email-masked]
> 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?

Yes, my mistake. Apologies for the confusion. In the former case, I meant to say that if the acceptance permission evaluates to false, a permission may still be granted (polite blocking), but ... 
I guess we will agree that this is a bad idea.

/Hisham

> 
> 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: [email-masked]
Date: Fri, 11 Jul 2003 10:17:12 +0300

/Hisham