1 / 6

Presence Policy Capabilities

Presence Policy Capabilities. Jonathan Rosenberg Cisco Systems. Problem Statement. Possible variation across providers in sets of authorization policies that are available Subsets of what is defined in presence-rules Provider-proprietary “macros” like “high privacy” and “low privacy”

sandraasmith
Download Presentation

Presence Policy Capabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Presence Policy Capabilities Jonathan Rosenberg Cisco Systems

  2. Problem Statement • Possible variation across providers in sets of authorization policies that are available • Subsets of what is defined in presence-rules • Provider-proprietary “macros” like “high privacy” and “low privacy” • Assumption that clients create authorization documents and upload them to the server • So – how does client know what kind of authorization policies can be placed in its document?

  3. Basic Approach • Common Policy Capabilities • Defines a policy capabilities document mirroring common policy • <conditions>, <actions>, <transformations> and <identity>, <sphere>, <validity> • Presence Policy Capabilities • Declarations for support for each of the conditions and attributes in presence-rules • Declarations of keys available for <provide-services>, <provide-devices>, <provide-persons>

  4. Example <?xml version="1.0" encoding="UTF-8"?> <cc:policy-capabilities xmlns="urn:ietf:params:xml:ns:presence-policy-capabilities" xmlns:pc="urn:ietf:params:xml:ns:presence-policy-capabilities" xmlns:cc="urn:ietf:params:xml:ns:policy-capabilities" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <cc:conditions> <cc:identity/> <cc:sphere/> <cc:validity/> <cc:sphere/> <vpp:temp/> </cc:conditions> <cc:actions> <sub-handling/> </cc:actions> <cc:transformations> <vpp:min-security/> <vpp:max-security/> <component-id/> <provide-person> <class/> </provide-person> </cc:transformations> </cc:policy-capabilities>

  5. Do we need this? • Not needed if • Clients use web applications or any server-side applications to generate authorization policies • Clients are matched to a particular provider and are hard-coded with their capabilities • Client/Server interfaces remain proprietary for control of authorization policies

  6. Remaining Work • Line up with final presence-rules specification • XML fix-ups • Issue: level of granularity of capabilities for <identity> • Can you indicate support just for <one> and not <many>? • Can you indicate support for identities of particular schema?

More Related