[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-simple-xcap-auth-usage) 00 01 02 03 04 05 06 07 08 09 10 RFC 5025

SIMPLE                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 25, 2005                                 October 25, 2004


                      Presence Authorization Rules
                  draft-ietf-simple-presence-rules-01

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Authorization is a key function in presence systems.  Authorization
   policies, also known as authorization rules, specify what presence
   information can be given to which watchers, and when.  This
   specification defines an Extensible Markup Language (XML) document
   format for expressing presence authorization rules.  Such a document
   can be manipulated by clients using the XML Configuration Access
   Protocol (XCAP), although other techniques are permitted.






Rosenberg                Expires April 25, 2005                 [Page 1]

Internet-Draft           Presence Authorization             October 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Structure of Permission Statements . . . . . . . . . . . . .   4
     3.1  Conditions . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1  Identity . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.2  Anonymous  . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.3  Sphere . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2  Actions  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1  Subscription Handling  . . . . . . . . . . . . . . . .   6
     3.3  Transformations  . . . . . . . . . . . . . . . . . . . . .   7
       3.3.1  Providing Access to Data Elements  . . . . . . . . . .   7
         3.3.1.1  Person Information . . . . . . . . . . . . . . . .   7
         3.3.1.2  Device Information . . . . . . . . . . . . . . . .   7
         3.3.1.3  Service Information  . . . . . . . . . . . . . . .   8
       3.3.2  Providing Access to Presence Attributes  . . . . . . .   8
         3.3.2.1  Provide Activities . . . . . . . . . . . . . . . .   8
         3.3.2.2  Provide Class  . . . . . . . . . . . . . . . . . .   8
         3.3.2.3  Provide Mood . . . . . . . . . . . . . . . . . . .   9
         3.3.2.4  Provide Place-type . . . . . . . . . . . . . . . .   9
         3.3.2.5  Provide Privacy  . . . . . . . . . . . . . . . . .   9
         3.3.2.6  Provide Relationship . . . . . . . . . . . . . . .   9
         3.3.2.7  Provide Sphere . . . . . . . . . . . . . . . . . .   9
         3.3.2.8  Provide Status-Icon  . . . . . . . . . . . . . . .  10
         3.3.2.9  Provide Timezone . . . . . . . . . . . . . . . . .  10
         3.3.2.10   Provide User Input . . . . . . . . . . . . . . .  10
         3.3.2.11   Provide Unknown Attribute  . . . . . . . . . . .  10
   4.   Example Document . . . . . . . . . . . . . . . . . . . . . .  11
   5.   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.   Schema Extensibility . . . . . . . . . . . . . . . . . . . .  15
   7.   XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1  Application Unique ID  . . . . . . . . . . . . . . . . . .  15
     7.2  Structure of Permission Statements . . . . . . . . . . . .  15
     7.3  Additional Constraints . . . . . . . . . . . . . . . . . .  15
     7.4  Naming Conventions . . . . . . . . . . . . . . . . . . . .  15
     7.5  Authorization Policies . . . . . . . . . . . . . . . . . .  16
     7.6  XML Schema . . . . . . . . . . . . . . . . . . . . . . . .  16
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  16
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  16
     9.1  XCAP Application Usage ID  . . . . . . . . . . . . . . . .  16
     9.2  URN Sub-Namespace Registration . . . . . . . . . . . . . .  17
     9.3  XML Schema Registrations . . . . . . . . . . . . . . . . .  17
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10.1   Normative References . . . . . . . . . . . . . . . . . . .  18
   10.2   Informative References . . . . . . . . . . . . . . . . . .  19
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  19
        Intellectual Property and Copyright Statements . . . . . . .  20



Rosenberg                Expires April 25, 2005                 [Page 2]

Internet-Draft           Presence Authorization             October 2004


1.  Introduction

   The Session Initiation Protocol (SIP) for Instant Messaging and
   Presence (SIMPLE) specifications allow a user, called a watcher, to
   subscribe to another user, called a presentity [15], in order to
   learn their presence information [18].  This subscription is handed
   by a presence agent.  The logical processing of the presence agent is
   described in the presence data model [12].  In that model, the
   subscription authorization decision, the selection of the composition
   policy, and the governance of privacy filtering are all described by
   a presence authorization document.  This specification defines a
   format for such a document.

   Typically, a user will place a multiplicity of authorization
   documents on a server, each one applying in certain situations.  In
   addition to the user, the service provider may have its own
   authorization policies which apply in other situations.  These
   documents are combined together to produce a single authorization
   policy which guides presence server processing.

   [10] specifies a framework for representing authorization policies,
   and is applicable to systems such as geo-location and presence.  In
   that framework, an authorization document is a sequence of rules.
   Each rule contains conditions, actions, and transformations.  The
   conditions specify under what conditions the rule is to be applied to
   presence server processing.  The actions element tells the server
   what actions to take.  In the context of the data model, these
   actions include the subscription authorization decision and the
   selection of the composition policy.  The transformations element
   indicates how the presence data is to be manipulated before being
   presented to that watcher, and serves as the guide for the privacy
   filtering operation.  [10] identifies a small number of specific
   conditions, actions and permissions common to presence and location
   services, and leaves it to other specifications, such as this one, to
   fill in usage specific details.

   These documents can be manipulated by clients using several means.
   One such mechanism is the XML Configuration Access Protocol (XCAP)
   [2].  This specification defines the details necessary for using XCAP
   to manage presence authorization documents.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.




Rosenberg                Expires April 25, 2005                 [Page 3]

Internet-Draft           Presence Authorization             October 2004


3.  Structure of Permission Statements

   A permission statement is an XML document, formatted according to the
   schema defined in [10].  As described in [10], this document is
   composed of three parts - conditions, actions, and transformations.
   Each action or transformation, which is also called a permission, has
   the property of being a positive grant of information to the watcher.
   As a result, there is a well-defined mechanism for combining actions
   and transformations obtained from several sources.  This mechanism is
   privacy safe, since the lack of any action or transformation can only
   result in less information being presented to a watcher.

   This section defines the new conditions, actions and transformations
   defined by this specification.

3.1  Conditions

3.1.1  Identity

   Although the <identity> element is defined in [10], that
   specification indicates that the interpretation of the <id> element
   depends on the specific protocol in use and its authentication
   mechanisms.  This sub-section defines that interpretation for systems
   based on [18].

   For requests that are authenticated using  SIP [9] digest
   authentication [8], the identity used for comparisons to the <id>,
   <domain> and <except> fields is set equal to the user and domain part
   of the SIP Address of Record (AOR) for the user that has
   authenticated themselves.  For example, consider the following "user
   record":


   SIP AOR: sip:alice@example.com
   digest username: ali
   digest password: f779ajvvh8a6s6
   digest realm: example.com

   If the presence server receives a SUBSCRIBE request, challenges it
   with the realm set to "example.com", and the subsequent SUBSCRIBE
   contains an Authorization header field with a username of "ali" and a
   digest response generated with the password "f779ajvvh8a6s6", the
   identity used in matching operations is "alice@example.com".

   For requests that are authenticated using RFC 3325 [19], the username
   and domain part of the URI are matched against the user and host
   parts of the SIP URI in the P-Asserted-Identity header field.




Rosenberg                Expires April 25, 2005                 [Page 4]

Internet-Draft           Presence Authorization             October 2004


   For any other authentication mechanism in SIP which might be
   identified in other specifications, a similar pattern would be
   followed.  The authentication mechanism would provide the recipient
   of the request with the AOR of the sender of the request.  The user
   and domain parts of the AOR then form the identity used in this
   specification.

   In SIP systems, it is possible for a user to have aliases - that is,
   there are multiple SIP AOR "assigned" to a single user.  In terms of
   this specification, there is no relationship between those aliases.
   Each would look like a different user.  This will be the consequence
   for systems were the watcher is in a different domain than the
   presentity.  However, even if the watcher and presentity are in the
   same domain, and the presence server knows that there are aliases for
   the watcher, these aliases are not mapped to each other or used in
   any way.

3.1.2  Anonymous

   The <anonymous> element, which is a boolean type, indicates whether
   or not the subscription request was sent from an anonymous sender.
   The value of TRUE means that the request was anonymous, and FALSE
   means it was not.  The request is considered anonymous if it was
   authenticated using the <anonymous> username defined in RFC 3261, if
   the asserted identity has a URI in the "anonymous.invalid" domain
   [14], or if the request cannot be authenticated by any SIP
   authentication mechanisms.  This implies that a request without any
   authentication, but with an otherwise valid From field, is still
   considered anonymous.

3.1.3  Sphere

   The <sphere> element is defined in [10].  However, each application
   making use of the common policy specification needs to determine how
   the presence server computes the value of the sphere to be used in
   the evaluation of the condition.

   To compute the value of <sphere>, the default composition policy is
   applied for the presentity [12].  The result will be a raw presence
   document with a single <person> element, possibly containing a
   <sphere> element, which is defined in the Rich Presence Information
   Data Format [11].  If the <sphere> is present, that value is used in
   the evaluation of the <sphere> condition.  If the <sphere> element is
   not present in the presence document, the value is set to undefined.

3.2  Actions





Rosenberg                Expires April 25, 2005                 [Page 5]

Internet-Draft           Presence Authorization             October 2004


3.2.1  Subscription Handling

   The <sub-handling> element specifies the subscription authorization
   decision that the server should make, as described in [12].  It also
   specifies whether or not the composition policy should be the default
   value, or whether the "polite blocking" composition policy (the
   details of which are a matter of provider policy) is to be used.  The
   two are specified jointly since proper privacy handling requires a
   correlation between them.  As discussed in [10], since the
   combination algorithm runs independently for each permission, if
   correlations exist between permissions, they must be merged into a
   single variable.  That is what is done here.  The <sub-handling>
   element is an enumerated Integer type.  The defined values are:

   block: This action tells the server to place the subscription in the
      rejected state.  It has the value of zero, and it represents the
      default value.  No value of the sub-handling element can ever be
      lower than this.  Strictly speaking, it is not necessary to every
      include an explicit block action, since the default in the absence
      of any action will be block.  However, it is included for
      completeness.

   confirm: This action tells the server to place the subscription in
      the "pending" state, and await input from the presentity to
      determine how to proceed.  It has a value of one.

   polite-block: This action tells the server to place the subscription
      into the "accepted" state.  Furthermore, it selects the
      composition policy, and sets it to support a polite blocking
      operation.  The specific composition policy to accomplish these
      goals is at the discretion of the service provider.  In all cases,
      the result of the composition policy should produce a raw presence
      document that indicates that the user is unavailable for
      communication.  A reasonable document would exclude device and
      person information elements, and include only a single service
      whose basic status is set to closed [3].  This action has a value
      of two.

   allow: This action tells the server to place the subscription into
      the "accepted" state.  Furthermore, it selects the default
      composition policy as defined by [12].  This action has a value of
      three.

      NOTE WELL: Placing a value of block for this element does not
      guarantee that a subscription is denied! If any matching rule has
      any other value for this element, the subscription will receive
      treatment based on the maximum of those other values.  This is
      based on the combining rules defined in [10].



Rosenberg                Expires April 25, 2005                 [Page 6]

Internet-Draft           Presence Authorization             October 2004


   Future specifications can define additional values for this
   permission, allowing for the selection of other composition policies.

3.3  Transformations

   The transformations defined here are used to drive the behavior of
   the privacy filtering operation described in [12].  Each
   transformation defines the visibility a watcher is granted to a
   particular component of the presence document.  One group of
   transformations grant visibility to person, device and service data
   elements based on identifying information for those elements.
   Another group of transformations provide access to particular data
   elements in the presence document.

3.3.1  Providing Access to Data Elements

   The transformations in this section provide access to person, device
   and service data elements.  Once access has been granted to such an
   element, access to specific presence attributes for that element is
   controlled by the permissions defined in Section 3.3.2.

3.3.1.1  Person Information

   The <provide-person> permission allows a watcher to see the <person>
   information present in the presence document.  It is a boolean
   variable.  A value of TRUE means that permission is granted, and
   false means that it is not.

      OPEN ISSUE: The inclusion of multiple person elements in a
      document to report conflicting information would impact this
      permission.


3.3.1.2  Device Information

   The <provide-devices> permission allows a watcher to see <device>
   information present in the presence document.  It is a set variable.
   Each value in the set is a member of the deviceIdentifier
   substitution group.  Members of this group provide ways to identify a
   device or group of devices.  This specification defines a single
   member of this substitution group, the <device-id> element.  This
   element identifies a device by its device ID.  The <provide-devices>
   element can also take on the special value <all-devices> which is a
   short-hand notation for all device IDs present in the presence
   document.

   Permission is granted to see a particular device if one of the device
   identifiers in the set identifies that device.  For the device



Rosenberg                Expires April 25, 2005                 [Page 7]

Internet-Draft           Presence Authorization             October 2004


   identifiers defined here, this is limited to the device ID.  As such,
   a device is included in the filtered presence document if its device
   ID is listed in the set, or the <all-devices> value was used.

3.3.1.3  Service Information

   The <provide-services> permission allows a watcher to see service
   information present in <tuple> elements in the presence document.
   Like <provide-services>, it is a set variable.  Each member of the
   set is a member of the serviceIdentifier substitution group.  Members
   of this group provide ways to identify a service or group of
   services.  This specification defines two member elements for this
   substitution group.  One, <uri-scheme>, identifies services by URI
   scheme.  A service is a match for this identifier if the scheme of
   the contact URI of that service matches, based on case sensitive
   string comparison, the value of the <uri-scheme> element.  The other
   member of the substitution group is <uri>.  This element identifies a
   service by its contact URI.  A service is a match for this identifier
   if the contact URI of that service matches, based on the equality
   rules for that scheme, the value of the <uri> element.

   Like <provide-devices>, the <provide-services> element can also take
   on the special value <all-services>, which is a short-hand notation
   for all services present in the presence document.

3.3.2  Providing Access to Presence Attributes

   The permissions of Section 3.3.1 provide coarse grained access to
   presence data by allowing or blocking specific services or devices,
   and allowing or blocking person information.

   Once person, device or service information is included in the
   document, the permissions in this section define which presence
   attributes are reported there.

3.3.2.1  Provide Activities

   This permission controls access to the <activities> element defined
   in [11].  The name of the element providing this permission is
   <provide-activity>, and it is a boolean type.  If its value is TRUE,
   then the <activities> element in the person data element is reported
   to the watcher.  If FALSE, this presence attribute is removed if
   present.

3.3.2.2  Provide Class

   This permission controls access to the <class> element defined in
   [11].  The name of the element providing this permission is



Rosenberg                Expires April 25, 2005                 [Page 8]

Internet-Draft           Presence Authorization             October 2004


   <provide-class>, and it is a boolean type.  If its value is TRUE,
   then the <class> element in the person, service or device data
   element is reported to the watcher.  If FALSE, this presence
   attribute is removed if present.

3.3.2.3  Provide Mood

   This permission controls access to the <mood> element defined in
   [11].  The name of the element providing this permission is
   <provide-mood>, and it is a boolean type.  If its value is TRUE, then
   the <mood> element in the person data element is reported to the
   watcher.  If FALSE, this presence attribute is removed if present.

3.3.2.4  Provide Place-type

   This permission controls access to the <place-type> element defined
   in [11].  The name of the element providing this permission is
   <provide-place-type>, and it is a boolean type.  If its value is
   TRUE, then the <place-type> element in the person data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.5  Provide Privacy

   This permission controls access to the <privacy> element defined in
   [11].  The name of the element providing this permission is
   <provide-privacy>, and it is a boolean type.  If its value is TRUE,
   then the <privacy> element in the service data element is reported to
   the watcher.  If FALSE, this presence attribute is removed if
   present.

3.3.2.6  Provide Relationship

   This permission controls access to the <relationship> element defined
   in [11].  The name of the element providing this permission is
   <provide-relationship>, and it is a boolean type.  If its value is
   TRUE, then the <relationship> element in the service data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.7  Provide Sphere

   This permission controls access to the <sphere> element defined in
   [11].  The name of the element providing this permission is
   <provide-sphere>, and it is a boolean type.  If its value is TRUE,
   then the <sphere> element in the person data element is reported to
   the watcher.  If FALSE, this presence attribute is removed if
   present.



Rosenberg                Expires April 25, 2005                 [Page 9]

Internet-Draft           Presence Authorization             October 2004


3.3.2.8  Provide Status-Icon

   This permission controls access to the <status-icon> element defined
   in [11].  The name of the element providing this permission is
   <provide-status-icon>, and it is a boolean type.  If its value is
   TRUE, then any <status-icon> element in the person or service data
   element is reported to the watcher.  If FALSE, this presence
   attribute is removed if present.

3.3.2.9  Provide Timezone

   This permission controls access to the <timezone> element defined in
   [11].  The name of the element providing this permission is
   <provide-timezone>, and it is a boolean type.  If its value is TRUE,
   then the <timezone> element in the person data element is reported to
   the watcher.  If FALSE, this presence attribute is removed if
   present.

3.3.2.10  Provide User Input

   This permission controls access to the <user-input> element defined
   in [11].  The name of the element providing this permission is
   <provide-user-input>, and it is an enumerated integer type.  Its
   value defines what information is provided to watchers:

   false: This value indicates that the <user-input> element is removed
      from the document.  It is assigned the numeric value of 0.

   bare: This value indicates that the <user-input> element is to be
      retained.  However, any "idle-threshold" and "since" attributes
      are to be removed.  This value is assigned the numeric value of 1.

   thresholds: This value indicates that the <user-input> element is to
      be retained.  However, only the "idle-threshold" attribute is to
      be retained.  This value is assigned to the numeric value of 2.

   full: This value indicates that the <user-input> element is to be
      retained, including any attributes.  This value is assigned to the
      numeric value of 3.


3.3.2.11  Provide Unknown Attribute

   It is important that systems be allowed to include proprietary or new
   presence information, and that users be able to set permissions for
   that information, without requiring an upgrade of the presence server
   and authorization system.  For this reason, the
   <provide-unknown-attribute> permission is defined.  This permission



Rosenberg                Expires April 25, 2005                [Page 10]

Internet-Draft           Presence Authorization             October 2004


   indicates that the unknown presence attribute with the given name
   (supplied as mandatory attribute of the <provide-presence-attribute>
   element) should be included in the document.  Its type is boolean.

   The value of the name attribute MUST be a qualified element name
   (meaning that the namespace prefix MUST be included), which will be
   matched to all unknown child elements of the PIDF <tuple>, <device>
   or <person< elements with the same qualified name.  In this context,
   "unknown" means that the presence server is not aware of any schemas
   that define authorization policies for that element.  By definition,
   this will exclude the <provide-unknown-attribute> rule from being
   applied to any of the presence status extensions defined by RPID.

   Another consequence of this definition is that the interpretation of
   the <provide-unknown-attribute> element can change should the
   presence server be upgraded with a new schema that defines
   authorization rules for elements included in a
   <provide-unknown-attribute>.  The <provide-unknown-attribute>
   permissions for those elements will then be ignored, resulting in a
   removal of those elements from presence documents sent to watchers.
   The system remains privacy safe, but behavior might not be as
   expected.  Developers of systems which allow clients to set policies
   are advised to check the capabilities of the server, as defined in
   [17], before uploading a new authorization document, to make sure
   that the behavior will be as expected.

4.  Example Document

   The following presence authorization document specifies permissions
   for the user "user@example.com".





















Rosenberg                Expires April 25, 2005                [Page 11]

Internet-Draft           Presence Authorization             October 2004


   <?xml version="1.0" encoding="UTF-8"?>
   <cr:ruleset xmlns:cr="urn:ietf:params:xml:ns:common-policy"
    xmlns="urn:ietf:params:xml:ns:pres-rules"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <cr:rule id="1">
     <cr:conditions>
      <cr:identity>
       <cr:id>user@example.com</cr:id>
      </cr:identity>
     </cr:conditions>
     <cr:actions>
      <sub-handling>allow</sub-handling>
     </cr:actions>
     <cr:transformations>
      <provide-services>
        <service-uri-scheme>sip</service-uri-scheme>
        <service-uri-scheme>mailto</service-uri-scheme>
      </provide-services>
      <provide-person>true</provide-person>
      <provide-activities>true</provide-activities>
      <provide-user-input>bare</provide-user-input>
       <provide-unknown-attribute name="foo">true</provide-unknown-attribute>
     </cr:transformations>
    </cr:rule>
   </cr:ruleset>




5.  XML Schema


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:pres-rules"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:cr="urn:ietf:params:xml:ns:common-policy"
    xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
    <xs:element name="anonymous" type="xs:boolean"
     substitutionGroup="cr:condition"/>
    <xs:simpleType name="booleanPermission">
     <xs:restriction base="xs:boolean"/>
    </xs:simpleType>
    <xs:element name="serviceIdentifier" abstract="true"/>
    <xs:simpleType name="serviceURISchemeType">
     <xs:restriction base="xs:string"/>
    </xs:simpleType>



Rosenberg                Expires April 25, 2005                [Page 12]

Internet-Draft           Presence Authorization             October 2004


    <xs:simpleType name="serviceURIType">
     <xs:restriction base="xs:anyURI"/>
    </xs:simpleType>
    <xs:element name="service-uri-scheme" type="pr:serviceURISchemeType"
     substitutionGroup="pr:serviceIdentifier"/>
    <xs:element name="service-uri" type="pr:serviceURIType"
     substitutionGroup="pr:serviceIdentifier"/>
    <xs:complexType name="provideServicePermission">
     <xs:choice>
      <xs:element name="all-services"/>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:element ref="pr:serviceIdentifier"/>
      </xs:sequence>
     </xs:choice>
    </xs:complexType>
    <xs:element name="provide-services"
     type="pr:provideServicePermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="deviceIdentifier" abstract="true"/>
    <xs:simpleType name="deviceIDType">
     <xs:restriction base="xs:anyURI"/>
    </xs:simpleType>
    <xs:element name="device-id" type="pr:deviceIDType"
     substitutionGroup="pr:deviceIdentifier"/>
    <xs:complexType name="provideDevicePermission">
     <xs:choice>
      <xs:element name="all-devices"/>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:element ref="pr:deviceIdentifier"/>
      </xs:sequence>
     </xs:choice>
    </xs:complexType>
    <xs:element name="provide-devices"
     type="pr:provideDevicePermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-person"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-activities"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-class"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-mood"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-placetype"



Rosenberg                Expires April 25, 2005                [Page 13]

Internet-Draft           Presence Authorization             October 2004


     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-privacy"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-relationship"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-status-icon"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-sphere"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-timezone"
     type="pr:booleanPermission"
     substitutionGroup="cr:transformation"/>
    <xs:element name="provide-user-input"
     substitutionGroup="cr:transformation">
     <xs:simpleType>
      <xs:restriction base="xs:string">
       <xs:enumeration value="false"/>
       <xs:enumeration value="bare"/>
       <xs:enumeration value="thresholds"/>
       <xs:enumeration value="full"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:element>
    <xs:element name="sub-handling" substitutionGroup="cr:action">
     <xs:simpleType>
      <xs:restriction base="xs:token">
       <xs:enumeration value="block"/>
       <xs:enumeration value="confirm"/>
       <xs:enumeration value="polite-block"/>
       <xs:enumeration value="allow"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:element>
    <xs:complexType name="unknownBooleanPermission">
     <xs:simpleContent>
      <xs:extension base="pr:booleanPermission">
       <xs:attribute name="name" type="xs:string" use="required"/>
      </xs:extension>
     </xs:simpleContent>
    </xs:complexType>
    <xs:element name="provide-unknown-attribute"
     type="pr:unknownBooleanPermission"
     substitutionGroup="cr:transformation"/>



Rosenberg                Expires April 25, 2005                [Page 14]

Internet-Draft           Presence Authorization             October 2004


   </xs:schema>



6.  Schema Extensibility

   It is anticipated that future changes to this specification are
   accomplished through extensions that define new types of permissions.
   These extensions MUST exist within a different namespace.
   Furthermore, the schema defined above and the namespace for elements
   defined within it MUST NOT be altered by future specifications.
   Changes in the basic schema, or in the interpretation of elements
   within that schema, may result in violations of user privacy due to
   mis-interpretation of documents.

   This specification also defines two substitution groups.  One is for
   service identifiers, and one is for device identifiers.  It is
   expected that future extensions will specify new ways of identifying
   services and devices for inclusion in a document.  These new
   permissions MUST be assigned to this substitution group.

7.  XCAP Usage

   The following section defines the details necessary for clients to
   manipulate presence authorization documents from a server using XCAP.

7.1  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the "pres-rules" AUID within the IETF tree, via
   the IANA registration in Section 9.

7.2  Structure of Permission Statements

   The structure of permission statements is defined in Section 3.

7.3  Additional Constraints

   There are no additional constraints defined by this specification.

7.4  Naming Conventions

   When a presence agent receives a subscription for some user foo
   within a domain, it will look for all documents within http://[xcap
   root]/ pres-rules/users/foo, and use all documents found beneath that
   point to guide authorization policy.




Rosenberg                Expires April 25, 2005                [Page 15]

Internet-Draft           Presence Authorization             October 2004


7.5  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which is that only a user can read, write or modify their own
   documents.  A server can allow priveleged users to modify documents
   that they don't own, but the establishment and indication of such
   policies is outside the scope of this document.

7.6  XML Schema

   The XML schema is defined in Section 5.

8.  Security Considerations

   Presence authorization policies contain very sensitive information.
   They indicate which other users are "liked" or "disliked" by a user.
   As such, when these documents are transported over a network, they
   SHOULD be encrypted.

   Modification of these documents by an attacker can disrupt the
   service seen by a user, often in subtle ways.  As a result, when
   these documents are transported, the transport SHOULD provide
   authenticity and message integrity.

   In the case where XCAP is used to transfer the document, clients
   SHOULD use HTTP over TLS, and servers SHOULD define the root services
   URI as an https URI.  The server SHOULD authenticate the client over
   the resulting TLS connection using HTTP digest.

9.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

9.1  XCAP Application Usage ID

   This section registers an XCAP Application Usage ID (AUID) according
   to the IANA procedures defined in [2].

      Name of the AUID: pres-rules

      Description: Presence rules are documents that describe the
      permissions that a presentity [15] has granted to users that seek
      to watch their presence.







Rosenberg                Expires April 25, 2005                [Page 16]

Internet-Draft           Presence Authorization             October 2004


9.2  URN Sub-Namespace Registration

   This section registers a new XML namespace, per the guidelines in
   [13]

      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:pres-rules.

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      XML:


                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>Presence Rules Namespace</title>
                </head>
                <body>
                  <h1>Namespace for Permission Statements</h1>
                  <h2>urn:ietf:params:xml:ns:pres-rules</h2>
                  <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
                </body>
                </html>
                END


9.3  XML Schema Registrations

   This section registers an XML schema per the procedures in [13].

      URI: urn:ietf:params:xml:schema:pres-rules.

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      The XML for this schema can be found as the sole content of
      Section 5.







Rosenberg                Expires April 25, 2005                [Page 17]

Internet-Draft           Presence Authorization             October 2004


10.  References

10.1  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
         draft-ietf-simple-xcap-03 (work in progress), July 2004.

   [3]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and
         J. Peterson, "Presence Information Data Format (PIDF)", RFC
         3863, August 2004.

   [4]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

   [5]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [6]   Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

   [7]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [8]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

   [9]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [10]  Schulzrinne, H., "A Document Format for Expressing Privacy
         Preferences", draft-ietf-geopriv-common-policy-02 (work in
         progress), October 2004.

   [11]  Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg,
         "RPID: Rich Presence: Extensions to the Presence Information
         Data Format  (PIDF)", draft-ietf-simple-rpid-03 (work in
         progress), March 2004.

   [12]  Rosenberg, J., "A Data Model for Presence",
         draft-ietf-simple-presence-data-model-00 (work in progress),
         September 2004.




Rosenberg                Expires April 25, 2005                [Page 18]

Internet-Draft           Presence Authorization             October 2004


   [13]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [14]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", RFC 3323, November 2002.

10.2  Informative References

   [15]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
         Instant Messaging", RFC 2778, February 2000.

   [16]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant
         Messaging / Presence Protocol Requirements", RFC 2779, February
         2000.

   [17]  Rosenberg, J., "An Extensible Markup Language (XML)
         Representation for Expressing Presence  Policy Capabilities",
         draft-rosenberg-simple-pres-policy-caps-01 (work in progress),
         July 2004.

   [18]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

   [19]  Jennings, C., Peterson, J. and M. Watson, "Private Extensions
         to the Session Initiation Protocol (SIP) for Asserted Identity
         within Trusted Networks", RFC 3325, November 2002.


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net












Rosenberg                Expires April 25, 2005                [Page 19]

Internet-Draft           Presence Authorization             October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg                Expires April 25, 2005                [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/