Privacy rules for presence

1. Privacy rules for presence Henning Schulzrinne May 10, 2004 v2.0

2. Data flow resolve state contradictions watcher list presence information content PUBLISH privacy filtering watcher filter rate limit PUBLISH watcher PUBLISH default composition: remove duplicate tuples remove empty tuples concatenate create view (device, service, …) removes tuples removes elements from tuples

3. Subscription • Separate filtering and subscription • Logically distinct • some geopriv systems don’t have subscription • but dependent (can’t filter without subscription) • Separate requirements • don’t want it to depend on current state • may not be completely known at subscription time • may allow state probing by repeated subscription • needlessly increases network load

4. Subscription rules • Conditions • time of day • identity • Outcome • block, confirm, polite-block?, allow

5. Depend on current presentity state sphere location But probably not activities idle time location type … Two types of rules: tuple selection (class) element selection and transformation Each rule applies to one tuple, not whole presence document Non-empty tuples are then merged using separate local policy initially, can just concatenate non-empty, non-identical tuples Filter rules

6. Multiple states • Rules depend on state of presentity • may be derived from PUBLISHed information • There may be multiple conflicting or ambiguous states • e.g., location=NY and location=NJ or (state,city) = (NY,Rochester) and (state) = (NY) • Two different spheres • If presentity has multiple states, two solutions: • apply each state to all tuples • keep tuples and elements that are included according to all presentity states • privacy safe • avoids complicated rules where one state overrides another • deals safely with incrementally available state • implementation choice: re-run rules if presentity state changes? • may yield additional notifications • avoid problem by declaring any contradictory state as undefined • undefined does not match any rule that requires that condition

7. Filter rules • Conditions: • watcher properties • presentity properties (sphere, location) • tuple properties (class, others?) • Two types of filter rules: • include tuple (by class) • is this a condition instead? • include elements (by element name) • Since per-tuple, simple: • list of semantic elements to provide, as tokens • <provide>activities contact</provide>

8. Example <conditions> <sphere>work</sphere> <identity> <uri>user@example.com</uri> </identity> <class>foobar</class> <uri-scheme>sip</uri-scheme> </conditions> <transformations> <provide>rpid:activities lo:a1</provide> </transformations>