Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)

[Alissa Cooper <[e-mail]>]

Hi Carl,

Thanks for this. I think the paragraph in the charter about whether GeoJSON objects are LOs was focusing on the target identity aspect. That is, the definitions of LO given in RFC 3693 and RFC 6280 both assume that a location object describes the location of a target device. I definitely appreciate that there are other implications of saying something is or is not a LO, so perhaps the charter needs some re-phrasing.

The current thinking coming out of IETF 93 seemed to be that the GeoJSON spec will define GeoJSON objects such that they represent geographic features only and do not specify associations between geographic features and particular devices. Of course, it will be fairly trivial for developers to associate those objects with target identities of some sort — the whole point of specifying a json format is to make it easier to use geo information in applications. And if the format is built to be extensible, which generally would be a good thing, that raises the question about the point at which we need to deal with the associated privacy and security issues at the spec level should the format be extended to associate a location with a target. To put it another way, the base spec could be written (1) to preclude extensibility of this sort, (2) to allow extensibility of this sort with the expectation that when extensions are defined, the associated privacy and security implications will be addressed, or (3) to allow extensibility of this sort and explain how future extensions need to address privacy and security. Personally I think (1) is unlikely given the versatility of json. The text Stephen and I were debating was aimed at (2). You seem to be suggesting (3). Does that seem like an accurate assessment?

Alissa

> On Sep 3, 2015, at 8:51 AM, Carl Reed <[e-mail]> wrote:
> 
> Sorry to jump in. I have now read the entire thread, reviewed the charter, and reviewed a number of RFCs on this topic (starting with 4119). Been a while! Before starting, I wish to state that I am not opposed to this WG activity - GeoJSON is an important spec and one now being used in OGC standards work as informational. I just have some concerns.
> 
> In my mind, there is perhaps a more fundamental question: What is a Location Object? Back with the LO activity first started, the focus was on extending PIDF to include location content. From that perspective, privacy and location are closely coupled. However, over time the use of the location object became uncoupled from PIDF and as a result a number of other RFCs now speak to how to use a LO with SIP, RADIUS, and so on. Essentially, a LO can also be viewed as a stand alone package of location content with additional attributes such as uncertainty. When I worked on these RFC, I never viewed LO as being tightly coupled with privacy but always viewed the LO as a data package that could be used with any number of other standards/specs or even as a standard alone payload. This is exactly what has happened. Don't get me wrong - the privacy implications associated with location are critical - and scary. Predictive analytics experiments have shown that future individual movement activity can be predicted with close to 95% accuracy by analyzing past movement behavior (a joint Harvard/MIT study).
> 
> Therefore, I would suggest that a GeoJSON encoded payload is a location object. Consider that the PIDF-LO geodetic model is encoded using GML. The abstract model for geometry used in GML is ISO 19107: Spatial Schema (which is now in revision). The GeoJSON geometry model is also based on ISO 19107. The main difference between the two (other than the LO requirement for additional geometry types) is that GeoJSON encodes coordinates as longitude/latitude. GML encodes coordinates as latitude-longitude. There are also differences in how other coordinate reference systems are handled. While these differences are properly documented, I would strongly encourage the planned activity to consider:
> 
> 1. Documenting the relationship (similarities and differences) between GeoJSON and a LO. This would allow developers to choose the appropriate implementation approach.
> 2. Have a section on threat analysis and security
> 3. Speak to how privacy issues could be addressed (back to item 1 also).
> 
> Perhaps I am being overly sensitive but location and privacy (along with provenance and uncertainty) are coming to the fore as major standards issues. The OGC is working these standards related issues more and more. Much of this is being driven by requirements to use location content associated "citizens as scientists" activities, volunteered geographic information, IoT, Smart Cities, and on and on.
> 
> I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. As such, I suspect many of my concerns could be easily addressed by referencing appropriate content from existing IETF RFCs. For example, the content of 7459 Uncertainty and Confidence is quite appropriate for a GeoJSON encoding. Also, 7459 was reviewed and commented on by OGC Members :-)
> 
> Sorry for the long posting.
> 
> Regards
> 
> Carl Reed
> Geospatial Standards geek
> 
> -----Original Message----- From: Alissa Cooper
> Sent: Thursday, September 03, 2015 9:02 AM
> To: Stephen Farrell
> Cc: [e-mail] ; [e-mail] ; Erik Wilde ; IESG
> Subject: Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)
> 
> Ok, one more try and we’re there I think:
> 
> OLD
> As the WG considers extensibility it will be careful not to
> preclude extensions that would allow GeoJSON objects to become location objects
> unless the group determines such extensibility would be harmful.
> 
> NEW
> Extensions that would allow GeoJSON objects to become location objects are not expected to be defined in the WG. Should that be needed, re-chartering will be required.
> 
>> On Sep 3, 2015, at 7:58 AM, Stephen Farrell <[e-mail]> wrote:
>> 
>> 
>> Better again. You could maybe add that's not expected to happen
>> during the lifetime of this wg but that'd be fine.
>> 
>> S
>> 
>> On 03/09/15 15:57, Alissa Cooper wrote:
>>> NEW Should extensions that would allow GeoJSON objects to become
>>> location objects be needed, re-chartering will be required.
> 
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv