1. Policy enforcement and filtering for geospatial information
Henning Schulzrinne
Columbia University
4-Aug-19
IETF GEOPRIV interim meeting

2. Architectures for (geo) information access
Claim: all using protocols fall into one of these categories
Presence or event notification
“circuit-switched” model
subscription: binary decision
Messaging
, SMS
basically, event notification without (explicit) subscription
but often out-of-band subscription (mailing list)
Request-response
RPC, HTTP; also DNS, LDAP
typically, already has session-level access control (if any at all)
Presence is superset of other two
4-Aug-19
IETF GEOPRIV interim meeting

3. Presence/Event notification
Three places for policy enforcement
subscription  binary
only policy, no geo information
subscriber may provide filter  could reject based on filter (“sorry, you only get county-level information”)  greatly improves scaling since no event-level checks needed
notification  content filtering, suppression
third-party notification
e.g., event aggregator
can convert models: gateway subscribes to event source, distributes by
both policy and geo data
4-Aug-19
IETF GEOPRIV interim meeting

4. IETF GEOPRIV interim meeting
Presence model
SUBSCRIBE
subscription
policy
subscriber (watcher)
for each
watcher
event generator
policy
subscriber
filter
rate limiter
change to previous
notification?
NOTIFY
4-Aug-19
IETF GEOPRIV interim meeting

5. IETF GEOPRIV interim meeting
Policy rules
There is no sharp geopriv boundary
Presence contains other sensitive data (activity, icons, …) and others may be added
Example: future extensions to personal medical data
“only my cardiologist may see heart rate, but notify everybody in building if heart rate = 0”
Thus, generic policies are necessary
4-Aug-19
IETF GEOPRIV interim meeting

6. IETF GEOPRIV interim meeting
Processing models
Sequential model:
for each subscriber, apply rules to new data
doesn’t scale well to large groups
Relational database model:
re-use indexing and other query optimizations
well-defined query and matching semantics
e.g., mySQL and PostGres have geo extensions
At time of subscription:
SELECT address FROM policies WHERE person=$subscriber (AND now() between(starttime,endtime) OR starttime is null) AND (a3=$a3 or a3 is null) …
4-Aug-19
IETF GEOPRIV interim meeting

7. IETF GEOPRIV interim meeting
Request-response
Same as presence: request ≈ event trigger
sometimes also session-based  ≈ subscription
4-Aug-19
IETF GEOPRIV interim meeting

8. Concern: fit into protocols
Authentication is done in using protocol
Must fit into those protocols
E.g., can’t magically say “present token” without specifying how token can be presented in these protocols
effectively modifies using protocols  e.g., requires SIP or HTTP modification
4-Aug-19
IETF GEOPRIV interim meeting

9. Concern: explicit consent
“Require consent” are not implementable without lots of additional detail
Require consent means different things in different contexts:
subscription: mark subscription as pending, notify presentity, presentity installs filter that resolves into accept or reject  SIMPLE model
careful not to reveal that presentity is present…
notification:
why not just proxy NOTIFY to rulemaker?
minor efficiency advantage by sending list only
would need to define format for identifying precise requests
same person could have multiple requests with different details
4-Aug-19
IETF GEOPRIV interim meeting

10. Concern: explicit notification
To be useful, requires definition of notification format
Could simply ‘cc’ rulemaker on each notification
If that, why not just subscribe to my own presence status?
Is it important to know the complete list of people that got the current notification and what exactly they received?
Opportunity for spamming innocent third parties that never wanted to be notified
Notification can be very large if it includes copies of actual notifications  sorcerer’s apprentice problem
4-Aug-19
IETF GEOPRIV interim meeting

11. Concern: provide meaningful feedback to subscriber
Polite model: allow subscription, but never send any notifications
avoids offense 
Frank model: evaluate subscriber (or request) filter
if too nosy, tell subscriber what to ask for
avoids surprises and simplifies debugging
reveals my privacy preferences  do I care if Acme Towing knows that I don’t fully trust them?
4-Aug-19
IETF GEOPRIV interim meeting