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

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

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 email both policy and geo data 4-Aug-19 IETF GEOPRIV interim meeting

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

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

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

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

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

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

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

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