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

2. 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

3. 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

4. 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

5. 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

6. Example geo in PIDF 21 April 2019 IETF 57 - GEOPRIV
<?xml version="1.0" encoding="UTF-8"?>
<presence ... xmlns:gml='
xmlns:loc='urn:ietf:params:xml:ns:geopriv-loc'
<tuple id="123">
<status>
<basic>open</basic>
<loc:location>
<gml:Point>
<gml:pos> </gml:pos>
</gml:Point>
</loc:location>
</tuple>
</presence>
21 April 2019
IETF 57 - GEOPRIV

7. 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

8. Disclosure rules
<p:disclosure rule="
<p:rule
<p:match>
<p:area>home</p:area>
<p:rrule freq="daily" until=" T000000Z" 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
</p:action>
</p:rule>
<p:rule subject="C=US ST=Washington L=Seattle O=Amazon.com, Inc
OU=Software CN=
<p:rule hash-uri="6e8c81b2f0de5e b56c5"/>
<p:rule until=" T13:20: :00" duration="3600"/>
</p:disclosure>
21 April 2019
IETF 57 - GEOPRIV

9. 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

10. 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