draft-schulzrinne-geopriv-presence-lo-00 Henning Schulzrinne Columbia University 21 April 2019 IETF 57 - GEOPRIV

Meta comments Explore a particular philosophy, not provide all details Try to fit with related work in SIMPLE and elsewhere Design considerations to follow = also open issues that need some resolution 21 April 2019 IETF 57 - GEOPRIV

Design considerations Allow two modes of delivery: single LO with complete rule set (A-L) external rule set (incl. MIME) Reason: delivery and storage flexibility does not increase processing complexity "bundling" (MIME or single LO) reduces failure probability and delay but makes separate security treatment harder 21 April 2019 IETF 57 - GEOPRIV

Design considerations Applicable to access restrictions for general information about people (e.g., presentities), not just geoloc boundary is often fuzzy e.g., "activity" in RPIDS can be subject to privacy and retention concerns design for generality, allow restriction to domain Treat rules as first-class elements rules are subject to retention and distribution rules themselves  allows for full use of rules without crude divisions (personal vs. non-personal) Re-use calsch for timing rules 21 April 2019 IETF 57 - GEOPRIV

Location information support both geospatial and civil locations geospatial includes vectors ("heading") and paths (points in time) uses OpenGIS GML format for geospatial needs profiling (500+ pages) homebrew for civil until external reference is found probably want union with Cuellar et al. format 21 April 2019 IETF 57 - GEOPRIV

Example geo in PIDF 21 April 2019 IETF 57 - GEOPRIV <?xml version="1.0" encoding="UTF-8"?> <presence ... xmlns:gml='http://www.opengis.net/gml' xmlns:loc='urn:ietf:params:xml:ns:geopriv-loc' entity='pres:alice@example.com'...> <tuple id="123"> <status> <basic>open</basic> <loc:location> <gml:Point> <gml:pos>40.85790 73.98857</gml:pos> </gml:Point> </loc:location> </tuple> </presence> 21 April 2019 IETF 57 - GEOPRIV

Example civil <loc:location> <c:c>US</c:c> <c:a1 label='state'>NJ</c:a1> <c:a2 label='county'>Bergen</c:a2> <c:a3 label='city'>Leonia</c:a3> <c:a6 label='street'>Westview</c:a6> <c:sts>Ave</c:sts> <c:hno>313</c:hno> <c:zip>10027</c:zip> </loc:location> 21 April 2019 IETF 57 - GEOPRIV

Disclosure rules <p:disclosure rule="http://example.com/disclosure.xml"> <p:rule uri="sip:bob@example.com"> <p:match> <p:area>home</p:area> <p:rrule freq="daily" until="20031224T000000Z" count="10"/> </p:match> <p:action> <p:include>a1</p:include> <p:include>a2</p:include> <p:exclude></exclude> <p:resolution latitude="9" longitude="10" altitude="3"/> <p:notify uri="mailto:alice@example.com"/> </p:action> </p:rule> <p:rule subject="C=US ST=Washington L=Seattle O=Amazon.com, Inc OU=Software CN=www.amazon.com"/> <p:rule hash-uri="6e8c81b2f0de5e5957871354761b56c5"/> <p:rule until="2004-05-31T13:20:00.000-05:00" duration="3600"/> </p:disclosure> 21 April 2019 IETF 57 - GEOPRIV

Disclosure: open issue There is no "final" recipient – after all, if there was, there would be no need for disclosure rules If recipient only gets A-C, likely that disclosure + retention will be effectively zero since I can't limit it beyond that Thus, need to be able to constrain "final" recipient of information at finer granularity 21 April 2019 IETF 57 - GEOPRIV

Additional open issues Closely related to authorization: OASIS SIMPLE authorization Identification of elements: suggest trivial subset of XPath (foo/bar/...) could use it to make things conditional "only include if value is within range" (e.g., within a certain area) probably too tedious to be useful 21 April 2019 IETF 57 - GEOPRIV