Subject: [Simple] First draft of text on semantic-based authorization policies

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 09 Mar 2004 04:24:35 -0500

Folks,

During the SIMPLE meeting at IETF, we had a discussion about whether to 
move from the current syntactic based permissions (show-namespace, 
show-tuple, show-element) to semantic-based ones. I took an action item 
to write up proposed text within one week on how the semantic-based 
approach might look. Below is a first cut (in xml2rfc) at what such 
permissions might look like.

One thing that became clear to me in doing this is that certain 
transformations are easily expressed semantically, but nearly impossible 
syntactically. The "view" permission was one example. There are a bunch 
of open issues; mostly minor, all noted in the text. Comments on any and 
all of it are welcome. I'd like to get buy in (or lack thereof) of this 
general direction within the next week or two so I can integrate the 
text and submit a revision.

Thanks,
Jonathan R.

---
<section title="Transformations">

<t>
Each of the sections below defines a particular transformation that is
applied to the presence document before distribution.
</t>

<section titie="View">

<t>
The view transformation indicates the way in which the published
presence data is aggregated before being presented to the watcher. The
value of this element is an enumerated token with the following
values:
</t>

<list style="hanging">

<t hangText="presentity:">This token has a value of zero. It indicates
that the presence agent should aggregate the presence information for
the presentity into a single tuple. This tuple will contain a single
contact value that reaches the presentity. Because this causes
aggregation of data into a single tuple, it reveals the least amount
of information about a presentity, and thus has the value of zero.
</t>

<t hangText="service:">This token has a value of one. It indicates
that the presence agent should model the presentity as a sequence of
tuples, each representing a "service" by which the presentity can be
reached. Examples of services and how they are represented is
described in <xref target="I-D.roach-simple-service-features"/>.</t>

<t hangText="device:">This token has a value of two. It indicates that
the presence agent should model the presentity as a sequence of
tuples, each representing a "device" that can be used to contact the
user. Examples of devices are wireless phones, PC-based IM applications, 
PDAs
and standalone hard phones.</t>

</list>

<t>The values of the tokens have been chosen such that "presentity"
represents the greatest level of privacy, followed by "service", and
"device" represents the least. [[OPEN ISSUE: Should we space out the
values to allow for other types to be defined down the road?]]. [[OPEN
ISSUE: This permission will require roach-simple-service-features, or
the text present in it, to proceed. What are the plans for that?]].
</t>

<t>The default value of this permission is "presentity" or zero.</t>

</section>

<section title="Contact URI">

<t>
The "contact-uri" permission indicates whether or not the Contact URI
for tuples is presented to the watcher or not. This element has an
optional "class" attribute, which indicates the class of tuples for
which the permission applies. Absence of this attribute indicates that
the permission applies to all tuples. There can be multiple
"contact-uri" elements, but each of them MUST differ in the presence
and/or value of the "class" attribute.
</t>

<t>The "contact-uri" permission is of boolean type. A value of false
means that the Contact URI for the associated tuples is not to be
distributed to watchers. A value of true means that it is. By default,
the Contact URI for all tuples is distributed to watchers.
</t>

<t>
For the purposes of combining permissions, the contact-uri for each
class is treated as an independent variable. If there is a contact-uri
without a class attribute, this is modeled as N separate contact-uri
elements, one for each of the N tuple classes in the presence
document. Tuples that are not explicitly labeled with a class are
considered to belong to the same class, which we call the implicit
class.
</t>

<t>
For example, consider a presence document with three tuples. The first
one is labeled with a class of "friend", the second one is labeled
with a class of "work", and the third has no label. This document has
tuples in three classes - work, friend and implicit. When a watcher
subsribes to the presence of this presentity, two rules match:
</t>

<figure><artwork>
<![CDATA[
RULE 1
   <contact-uri class="friend">true</contact-uri>
   <contact-uri>false<contact-uri>

RULE 2
   <contact-uri class="work">true</contact-uri>

]]></artwork></figure></t>

<t>
To combine these permissions, the contact-uri in the first rule
without a class attribute is modeled as if it were three
contact-uris:</t>

<figure><artwork>
<![CDATA[
   <contact-uri class="friend">false</contact-uri>
   <contact-uri class="work">false<contact-uri>
   <contact-uri class="implict">false<contact-uri>
]]></artwork></figure></t>

<t>The contact-uri for each class is then treated as an independent
variable, and the standard combining rules are applied. There are two
instances of the contact-uri element for friends - one with a value of
true (from rule 1), and one with a value of false (from the expanded
classless contact-uri). These are combined to yield a value of
true. As a result, the contact in the tuple with class "friend" will
be shown to the watcher. There are two instances of the contact-uri
element for work - one with a value of true (from rule 2), and one
with a value of false (from the expanded classless contact-uri). These
are combined to yield a value of true. As a result, the contact in the
tuple with class "work" will be shown to the watcher. There is a
single instance of the contact-uri element for "implicit", with a
value of false (from the expanded classless contact-uri). As a result,
the contact in the tuple without a class label will not be shown to
the watcher.
</t>

<list style="indent"><t>
OPEN ISSUE: There is no way to define that a contact-uri applies to
all tuples without a class label. We could introduce that by defining
a special value of the class attribute, say "implicit". This would
cause problems if a presence document ever had a class label with the
actual value of "implicit". Another choice is to define another
attribute to the contact-uri element, say "implicit", which indicates
that it applies to implicit classes or not.
</t></list>

</section>

<section title="Activity">

<t>This permission controls access to the "activity" element defined
in <xref target="I-D.ietf-simple-rpid"/>. The name of the element is
"activity", and it is a boolean type. When true, it means that the
RPID activity is to be distributed to watchers, and when false, means
that it is to be withheld.
</t>

<t>
Like the "contact-uri" element, the "activity" element can have an
optional "class" attribute that defines which tuples the permission
applies to. Rules for composition are identical to those for
"contact-uri".
</t>

<t>
The default value for this permission is false.
</t>

</section>

<section title="Tuples by Class">

<t>
This permission controls access to tuples. It indicates which tuples
published into the presence agent will be used as an input to the
composition process. Tuples are selected by the value of their
"class" element. The "tuples-by-class" element has, as its content,
the name of a specific class which is to be used as input in the
composition process. There can be multiple instances of the
"tuples-by-class" element, each one indicating a different
class. [[OPEN ISSUE: Same issue as above on how to indicate tuples
that have no explicit class.]]. The result is that the
"tuples-by-class" element is a "set" data type.
</t>

<t>
The default value of this permission is "implicit", meaning that in
absence of specific instructions otherwise, only tuples without the
class label will be distributed to watchers.
</t>

<list style="indent"><t>
OPEN ISSUE: There are other reasonable chocies for this
default. Another choice is that all tuples, regardless of class, are
distributed.
</t></list>

</section>

<section title="Class">

<t>
This permission controls access to the "class" element within the PIDF
document. This is in contrast to the "tuples-by-class", which indicates
which tuples are passed to the watcher. This permission indicates
whether the RPID "class" element is passed to the watcher.
</t>

<t>
This permission is a boolean type. Its default is false, meaning that
the class element will normally be stripped from PIDF documents unless
the presentity instructs otherwise. The element can contain a "class"
attribute which indicates for which classes this permission
applies. The aggregation rules for this permission are identical to
those for "contact-uri".
</t>

</section>

<section title="Contact Type">

<t>
This permission, "contact-type" controls access to the "contact-type"
element within
the PIDF document. It is of boolean type. When true, the
"contact-type" element is passed to watchers. When false, it is
removed from the document. The default value is false.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

</section>

<section title="Idle">

<t>
This permission, "idle" controls access to the "idle"
element within
the PIDF document. It is an enumerated integer type. Its values are
"hide", with a value of zero, that indicates that the "idle" element
is to be removed from the presence document, "no-time", with a value
of one, that indicates that the "idle" element is to be passed on to
watchers, but without the specific duration for which the user has
been idle, and "full", with a value of two, that indicates that the
"idle" element is to be passed onto watchers, and should include a
specific duration if available.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

</section>

<section title="PlaceType">

<t>
This permission, "placetype" controls access to the "placetype"
element within
the PIDF document. It is of boolean type. When true, the
"placetype" element is passed to watchers. When false, it is
removed from the document. The default value is false.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

<list style="indent"><t>
OPEN ISSUE: Do we want any finer grained permissions than just whether
to include, or not include, placetype in the presence document?
</t></list>

</section>

<section title="Privacy">

<t>
This permission, "privacy" controls access to the "privacy"
element within
the PIDF document. It is of boolean type. When true, the
"privacy" element is passed to watchers. When false, it is
removed from the document. The default value is false.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

</section>

<section title="Relationship">

<t>
This permission, "relationship" controls access to the "relationship"
element within
the PIDF document. It is of boolean type. When true, the
"relationship" element is passed to watchers. When false, it is
removed from the document. The default value is false.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

</section>

<section title="Sphere">

<t>
This permission, "sphere" controls access to the "sphere"
element within
the PIDF document. It is of boolean type. When true, the
"sphere" element is passed to watchers. When false, it is
removed from the document. The default value is false.
</t>

<t>
The element can contain a "class"
attribute which indicates for which tuples, based on their class, this
permission applies. The aggregation rules for this permission are
identical to those for "contact-uri".
</t>

</section>

<section title="Example Document">

<figure><artwork>
<![CDATA[

<?xml version="1.0" encoding="UTF-8"?>
    <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
        xmlns:pres="urn:ietf:params:xml:ns:pres-policy">

      <rule id="f3g44r1">

        <conditions>
          <identity>
            <uri>[email-masked]</uri>
          </identity>
          <validity>
            <from>2003-12-24T17:00:00+01:00</from>
            <to>2003-12-24T19:00:00+01:00</to>
          </validity>
        </conditions>

        <actions>
          <confirmation>true</confirmation>
        </actions>

        <transformations>
          <pres:view>service</pres:view>
          <pres:activity>true</pres:activity>
          <pres:tuples-by-class>business</pres:tuples-by-class>
          <pres:tuples-by-class>work</pres:tuples-by-class>
          <pres:class class="work">true</pres:class>
          <pres:idle>no-time</pres:idle>
        </transformations>

      </rule>

    </ruleset>

]]></artwork></figure>

</section>

<section title="More Open Issues">

<list style="symbols">

<t>OPEN ISSUE: Is the naming of these permissions confusing? Each
permission has the same name as the PIDF/RPID element it controls
access to. Namespaces will make it clear which is which, but we could
use different names if it was confusing.
</t>

<t>OPEN ISSUE: Right now, the permissions apply to all tuples, or to
tuples selected by class. There is no other way to select which tuples
the permission applies to, except for class. We could extend the
attributes to allow for selection based on other thing - for example,
placetype or sphere. The aggregation process begins to get
complicated, however, and I'm not sure how to do it.
</t>

<t>OPEN ISSUE: Do we want a way to specify any syntactic-based
authorization policies, in order to allow the server to handle
permissions for new presence elements without simultaneously
supporting the permission schemas for those elements?
</t>

</list>

</section>

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