Subject: Questions and comments regarding geopriv-reqs-02

From: "James M. Polk" <[email-masked]>
Date: Fri, 31 Jan 2003 18:31:48 -0600

Authors and list

I have a couple questions and a few comments about the current 
geopriv-reqs-02 ID:

1. Under what circumstances is LI optional within a valid LO (there are 
*no* LI fields) - section 3.1.2?

2. Why is the focus only on non-publicly available Location Information 
(Section 3.1.1)?

This should be available to all forms of geodetic and civil location 
transfers - including transporting what could be found in a Yellow Pages 
listing.

3. Stated in the Abstract:

   "This document focuses on the authorization, integrity and privacy
    requirements for such location-dependent services.  Specifically, it
    describes the requirements for the geopriv Location Object (used to
    securely transfer location data and other privacy-enabling
    information) and for the protocols that use this Location Object."

But this doesn't state anything to the effect of  '... this document with 
define Location Information...' or '... this document will define how 
location information will be specified in a uniform manner...'.  Why has 
this topic area been omitted?

4. From the Intro section

   "A key goal of the protocols described in this
    document is to facilitate the protection of privacy pursuant to
    privacy policies set by the "user" (or, more precisely in the
    terminology of this document defined in Section 3 below, the "Rule
    Maker")."

This doesn't account for the possibility of any domain based policies (and 
mechanisms) that might override a user's policies.

5. From the Intro:

   "The ability to derive or compute a Device's location, and access to
    the derived or computed location, are key elements of the location-
    based services privacy equation.  Central to a Target's privacy are
    (a) the identity of entities that have access to raw location data,
    derive or compute location, and/or have access to derived or
    computed location information, and (b) whether those entities can be
    trusted to know and follow the privacy policy of the user."

"The ability to derive or compute a Device's location..." is outside the 
scope of the IETF, but it's stated more than once here. I believe a server 
could "gather" the Location Information with or without IP involved, then 
transmit it in IP (at which time this could be done with a Geopriv Protocol).

6. In the Intro section:

   "The main principles guiding the requirements described in this
    document are:"

which lists 5 parts to Geopriv's Requirements - without listing anything 
about Location Information...

As it is, this document could be renamed as "Geopriv Privacy Requirements"

7. From Conventions section:

   "Note that the requirements discussed here are requirements on the
    generic Location Object and on the using protocols for location
    services.  Thus the requirements discussed in this document mostly
    refer to the capabilities that are mandatory-to-implement."

So this document should cover all that is mandatory to implement, right?

8. From section 3.1.1. Location Information (LI) and Sighting:

   "The focus of the geopriv working group is on information about a
    Target's location that is NOT based on generally or publicly
    available sources, but instead on private information provided or
    created by a Target, a Target's Device, or a Target's network or
    service provider:

       Location Information (LI):
          A relatively specific way of describing where a Device is
          located and that is (a) derived or computed from information
          generally not available to the general public (such as
          information mainly available to a network or service
          provider), (b) determined by a Device that may be not
          generally publicly addressable or accessible, or (c) input or
          otherwise provided by a Target."

Again states the purpose of the Geopriv WG, including the deriving of a 
Target's location. Should state providing, transferring, and/or generating 
Location by some means outside the scope of the IETF. Seems to leave out 
the possibility of a configuration protocol sending the Location 
Information to the Target at boot time (or some other time).

Is one of the requirements of LI to state in which way the LI was 
determined? It seems to have been written this way.

Doesn't seem like we should care how the LI was determined, just that it is 
a format Geopriv can use. And if we don't care (due to it being out of 
scope for us to manage or authenticate), we should refer to it other than 
the transport of it. This transportation could be in raw form, as such a 
Geopriv aware device is needed to generate the LI in a Geopriv format 
(which should be referenced).

9. From section 3.1.1. Location Information (LI) and Sighting:

   "Within any given location-based transaction, the INITIAL
    determination of location (and thus the initial creation of Location
    Information) is termed a Sighting:

       Sighting:
          The initial determination of location based on non-public
          information (as discussed in the definition of Location
          Information), and the initial creation of Location
          Information."

The creation of Location Information is outside the scope of Geopriv, yet 
it is mentioned here explicitly.

Sighting is referring to something similar to a military sighter usage 
(from the artillery term) in which someone calculates or uses instruments 
to determine where something else is, generally what is to be shot at. 
While this might have some similarity in meaning to the mobile or cellular 
examples proved, it doesn't apply to any manual entries directly, and 
doesn't seem appropriate for situations where another IP-based Protocol(s) 
delivers the location information (say from a wire-map database described 
in the DHCP LO Option ID, or via some RPC).

A more appropriate term for Location Sighter would seem to be Location 
Generator - as something that generates or creates, in some IP protocol 
syntax, location reference information field or fields (for example - 
converts raw GPS coordinates into a Lat/Long/Alt coordinates that this WG 
appears to prefer).

10. From section 3.1.1. Location Information (LI) and Sighting:

   "In this case, Identifier-1 may be Pseudonym, and Location-1 may have
    less accuracy or granularity than the original value."

This is the first use of the terms "accuracy" and "Granularity", yet in 
Atlanta, the WG seemed to agree that "accuracy" isn't the correct term we 
mean to convey, "Resolution" is (and "precision" along with it).

Resolution isn't mentioned anywhere within this document.

Further, in 9.3. Specifying Desired Accuracy in a Request:

   "If the LO is used to request location information (leaving some
    fields empty), it is not clear how to specify the requested
    accuracy.  Are the data types "country/state/city" and
    "country/state" different data types or the same data type with
    different "accuracy" or "granularity"?"

This section gives the most concrete definition of Accuracy, yet it is in 
fact loosely defining the term 'resolution'. Accuracy defines something 
that is within x number of measurement units from a specific point on a 
referencable map.

Resolution is defined as being within a specific border or set of borders 
on a referencable map.

Within a "country/state/city" seems to fit the definition of Resolution, 
and not accuracy.

Granularity isn't defined within this document.

11. From 3.1.2. The Location Object"

   "A main goal of the geopriv working group is to define a Location
    Object (LO), to be used to convey both Location Information and
    basic privacy-protecting instructions:

       Location Object (LO): This data contains the Location Information
          of the Target, and other fields including an identity or
          pseudonym of the Target, time information, core privacy
          policies, authenticators, etc.  Most of the fields are
          optional, including the Location Information itself."

This last line is troubling, and not explained. Why would LI be optional?

This section is a further reminder of how little is defined in the LI 
section (3.1.1) about LI and what fields are mandatory (apparently none), 
and which are optional, or even which are available to chose from (other 
than a time field - but is that time field the time when the Target was 
last queried for its location, or when the storing Server received the 
location, or when the Server responded to the Location Request?). Section 
9.5 mentions that this time field doesn't have a default format.

Somewhere, some device knows exactly where a Target is. What isn't stated 
explicitly in this ID is that from that precise and complete LI field 
group, policy can and will make the Target's location reply less precise - 
perhaps (and likely) based on who asked for the information. There should 
be cases where maximum resolution is provided (emergencies or just by 
policy configuration for certain requesters). This isn't mentioned as being 
available.

There is also no mention of the ability for the Location Seeker (another 
hard term to use) to request an optional field be returned to it. For 
instance, if distance and vector are optional LI fields, is the Target the 
sole decision maker that it will include this information in the Location 
Reply? What if the Location Seeker doesn't want this information? This has 
a direct impact on the size of the Geopriv message (which is later stated 
in the ID to be a concern).

12. From 3.1.3. Location Object vs. Using Protocol:

   "The "using protocol" is the protocol that uses (creates, reads or
    modifies) the Location Object.  A protocol that just transports the
    LO as a string of bits, without looking at them (like an IP storage
    protocol could do), is not a using protocol, but only a transport
    protocol."

This shouldn't be the definition of a using vs. transport protocol. 
"...without looking at them..." is an unusual phrase in defining a 
protocol's usage. Shouldn't this be defined as "transporting unmodified" 
(the LI/LO) is a transportation protocol.

If this definition remains as is, doesn't that mean that SIP, for example, 
could use LI fields unmodified in reference to any target device the UA 
knows without any related Policy or Security information accompanying those 
LI fields?

13. Further from this section: 3.1.3. Location Object vs. Using Protocol

   "...Nevertheless, the entity or protocol that caused the
    transport protocol to move the LO is responsible of the correct
    distribution, protection, usage, retention, and storage of the LO."

Should read "...is responsible for the..."

And, what is meant by the term "...correct..." in this context. Is this not 
based uniformly on the Policy and Security information contained within the 
LO itself. If so, it should be stated here.

14. Further from this section: 3.1.3. Location Object vs. Using Protocol

"...are of two types:  First, the Location Object definition MUST
    include (optional) fields or mechanisms used to secure the LO as
    such.  The LO MAY be secured, for example, using cryptographic..."

What is meant by "...MUST include (optional) fields..."?

Fields are either optional, or mandatory, and so far in this document, no 
fields are mandatory; therefore nothing is a MUST.

15. Further from this section: 3.1.3. Location Object vs. Using Protocol

   "The security mechanisms of the Location Object itself are to be
    preferred."

This last sentence seems out of place. Shouldn't the security mechanism 
clearly stated within the Security Information fields of the LO be the 
minimum level achieved when a Using Protocol includes the LI of a Target?

16. From 3.1.4. Trusted vs. Non-trusted Data Flows:

   "The following terms distinguish
    between the two basic types of data flows:

       Trusted Data Flow:
          A data flow that is governed by a pre-existing contractual
          relationship that addresses location privacy.

       Non-trusted Data Flow:
          The data flow is not governed by a pre-existing contractual
          relationship that addresses location privacy."

This doesn't seem to cover the case of non-contracted, but Security 
Association configured "trusted" data flows. For example, not all employees 
of the same company will necessarily have a contract in place when 
exchanging LI. Me and my wife might not either. Yet if the devices are 
configured to transfer LI between themselves in a secure manner (perhaps 
matching or exceeding Geopriv's minimums), that should be considered 
"trusted". PGP is an example of trusted data flows, yet there is no 
contract between parties that should not be expected between some Geopriv 
parties.

17. From 3.2.1. Primary Geopriv Entities:

Here is another location (aside from the Terminology section 3.0 & 3.1) 
within the ID for terms and definitions. This should be in one place within 
the ID.

18. From 3.2.1. Primary Geopriv Entities:

"Device" seem redundant and not necessary. Is it a Target? It seems as if 
"A Target" qualifies and fulfills the role of "A Device". The term/phrase 
"The Target" means a specific "Target" whose location is sought. Both are 
nouns (1st and 3rd person) and can easily be used either way - therefore 
reducing the number of terms used.

19. From 3.2.1. Primary Geopriv Entities:

      "Rule Maker:
          The individual or entity that has the authorization to set the
          applicable privacy policies and rules."

This definition explicitly states that there is "one" controller of rules 
or policies. A user should have control over their target(s), yet there 
could easily be a situation where a domain (perhaps a company's internal 
policy) might also have overriding control over part of the LI (perhaps 
overriding the maximum resolution a Target gives in a Location Request).

20. More from 3.2.1. Primary Geopriv Entities:

    "Location Seeker (LSeek):
          An individual or entity who seeks to receive location data
          about a Target.

    A Location Seeker may act in one or more of the following more
    specialized roles: as the Location Sighter, a Location Server, or as
    an Ultimate Location Recipient:

       Location Sighter (LoSi), or Location Data-Source
          The original source of the sighting of a Target in a given
          transaction.

       Location Server (LServ), or Intermediate Location Recipient: "

Seems like the acronyms are hard at best to remember.

Seems like the Seeker can be a Ultimate Location Recipient. Why does this 
need 2 terms? It imitates a Client/Server type relationship - and gives 
multiple names for the Client and Server. How about a single name for each 
- while defining each can have multiple roles? This is especially true when 
reading that there is another term (Intermediate Location Recipient) possible.

21. More from 3.2.1. Primary Geopriv Entities:

"Ultimate Location Recipient (ULR):
          An individual or entity who receives location data about a
          Target and does not transmit the location information or
          information based on the Target's location (such as driving
          directions to or from the Target) to any party OTHER than the
          Target or the Rule Maker."

Is the ULR (another hard acronym) still a ULR if the LI comes under the 
control of a Using Protocol? If so, this seems like a "Geopriv Location 
Seeker" endpoint (could be defined as one of its many roles); if not, 
Geopriv shouldn't define the ULR for another Protocol that optionally 
manipulates part of or all of the LO (including Policy and Security 
Information Fields and requirements).

22. From 3.2.2. Secondary Geopriv Entities

"Data Transporter:
          An entity or network that receives and forwards data without
          processing or altering it."

Why does this term need to be defined? This involves the previously defined 
"transport protocol" (from section 3.1.3) and has nothing to do with 
Geopriv or its operations, does it?

23. More from 3.2.2. Secondary Geopriv Entities

"Initial Access Provider (IAP):
          The entity that provides the initial network access or other
          data communications services essential for the operation of
          communications functions of the Device or computer equipment
          in which the Device operates. Often, the IAP -- which will be
          a wireless carrier, an Internet Service Provider, or an
          internal corporate network -- will be identical to the LoSi.
          In other cases the IAP has a "dumb" LoSi, one that transmits
          geopriv data but does not implement or use any part of the
          geopriv Location Object.  Other cases may involve no IAP at
          all or the IAP is only a Data Transporter. "

By any other name, this is the Internet and is an ISP, which is a defined 
term within the IETF - as such, is not needed here.

How can a Network be a "Location Sighter"? Cell Towers might be used to 
gather enough information to a collection server to generate LI worthy of 
insertion into a LO for a Target. A satellite system (GPS) could also be 
used for this operation. Neither is IP based, therefore shouldn't be 
defined here, but can be mentioned.

24. From 3.2.3. Geopriv Data Storage Functions

   "The existence and data storage practices of Location Storage is
    crucial to privacy considerations, because this may influence what
    Location Information could eventually be revealed (through later
    distribution, technical breach, or legal processes)."

This paragraph should necessitate a requirement for storage policy being 
included within the Policy Information of the LO for a Target.

25. From 3.3. Privacy Policies and Rules

   "..."my location can only be disclosed to
    the owner of such credentials and in such accuracy"..."

This is a misuse of the word "accuracy" and its meaning. Resolution and 
(more likely only) precision are the coupled meanings that should be here 
in the quote.

26. From 3.4. Identifiers, Authentication and Authorization

    "...Unlinkability ensures that a user may make multiple
    uses of resources or services without others being able to link
    these uses together.  Unlinkability requires that entities are
    unable to determine whether the same user caused certain specific
    operations in the system."

If "unlinkability" ensures the privacy of a Target, in essence, then how is 
it to be used to bind a Location Seeker's unlinkable ID to authenticate a 
Location Request to, and be successful?

If you don't know that it is me requesting your location, because of this 
unlinkability, then how would you bind a rule or policy to my pseudonym and 
grant me the ability you would have given me (had you known it was me 
asking)? This is further called into question during the "id-B" example in 
the next paragraph.

27. More from 3.4. Identifiers, Authentication and Authorization

"Authorization
          The act of determining if a particular right, such as access
          to some resource, can be granted to the presenter of a
          particular credential."

This doesn't seem to allow for the concept of varying authorization, and 
make the LI less precise based on who asked for it. This is a key piece of 
most discussions within the WG form it's beginning.

28. From 4. Scenarios and Explanatory Discussion

There an example of GPS, of Cell Towers, and Mobile Communities and 
Location-Based Services. There is no mention of a wired scenario (such as 
Broadband Cable or DSL access, or Ethernet connectivity). This further 
makes this ID appear to be a mobile/Cellular centric ID. Geopriv should not 
be limited to wireless mind sets.

Additionally, any GPS communications is logical and shouldn't be mentioned 
as a Geopriv scenario (there's no IP involved). Cell Towers aren't IP 
based, therefore they too aren't under Geopriv's charter.

Once some Server that has gathered enough information about these cellular 
devices, that Server might use Geopriv to communicate to other Location 
Servers (this scenario could fall under Geopriv, or SOAP).

29. From SCENARIO 3:  Mobile Communities and Location-Based Services

   "...including Data Types and Accuracy."

This is the first mention of "Data Types". What are they? This is loosely 
referenced, but not defined in Requirement 2.6.

30. More From SCENARIO 3:  Mobile Communities and Location-Based Services

    "1: Registration:
          The Rule Maker registers himself and the Target with the
          Location Server. This registration process is outside of the
          scope of our discussion..."

Why is Registration of Geopriv Targets, Geopriv Servers and Geopriv Rule 
Makers *not* part of Geopriv?

Further, it would seem that the Target would be doing the Registration to a 
Location Service, and within that Registration would be a pointer to an 
existing Rule Maker (the Target and Rule Maker should be the owners of the 
policy for that Target) and an existing Rule Maker Policy Profile for that 
Target. The text here has this process turned around.

If the Target is new to a Location Services Provider, then they should be 
prompted to create a Profile (perhaps a resident file within the Target 
waiting for upload - and also part of Geopriv). There shouldn't be any 
location communications until the LSP has verified that it will grant this 
Target access to its network, and the network will follow the Policy 
Information and Security Information rules (kinda like a contract).

31. From 5.1. Location Object

   "Req. 1.  (Location Object generalities)

       1.1) Geopriv MUST define one Location Object (LO) -- both in
       syntax and semantics -- that must be supported by all geopriv
       entities.

       1.2) Some fields of the Location Object MAY be optional.  This
       means that an instance of a Location Object MAY contain the
       fields or not."

Should be rewritten as follows (with new numbering that's not included here):

    1.1) Geopriv MUST define a 'mandatory to implement' set of Location 
Object fields to be understood by all Geopriv entities.

    1.1a) Any Geopriv entity that transmits a maximum precision LO, provide 
a mandatory to implement minimum set of Location Information fields in that 
Location Reply (this should be similar to what is in the DHCP LO Option ID.

    1.1b) A Location Sighter (term needs to change to Generator) MUST 
include a mandatory minimum set of LI fields in its communication to the 
Location Server.

    1.2) Some fields within the Location Object MAY be present, or MAY not.

    1.2a) All Geopriv entities MUST not fail a transaction if one or more 
fields are not present, or not understood, if the Geopriv message is 
acceptable under the Policy and Security rules for that Target.

32. From Requirement 2.5 Location Field.

   "Each Location Field may contain one or more Location
    Representations, which can be also in different formats."

This text seems to indicate the necessity of another ID defining all the 
potential Location Information Fields (to ensure interoperability). Why was 
this left so open?

33. From Requirement 2.7 Motion and direction vectors

This text should be under Req 2.5 - or this separate ID defining the LO, or 
at least the LI and its mandatory and optional fields

34. From Requirement 3.2

      "3.2) The Location Object SHOULD define two Location Data Types:
       one for latitude / longitude / altitude coordinates and one for
       civil locations (City, Street, Number) supported by all geopriv
       receivers (entities that receive LOs)."

Civil addressing isn't understood throughout the world (as in there isn't 
one way of expressing civil addresses). This should be an defined optional 
LI Field which should be included if the Location Seeker asks for it.

35. From Requirement 3.3

      "3.3) The latitude / longitude / altitude Data Type SHOULD also
       support a delta format in addition to an absolute one, used for
       the purpose of reducing the size of the packages or the security
       and confidentiality needs."

In text format, as Geopriv is, this won't save any space in the Geopriv 
message - therefore this doesn't make much sense to be a requirement.

36. From Requirement 3.4

      "3.4) The Location Object definition SHOULD agree on further
       Location Data Types supported by some geopriv entities and
       defined by other organizations."

What is this requirement referring to? There are no examples, and nothing 
comes to mind that could explain this requirement.

37. From Requirement 5.2. The Using Protocol

      "Req. 4.  The using protocol has to obey the privacy and security
       instructions coded in the Location Object and in the
       corresponding Policy Rules regarding the transmission and storage
       of the LO."

This is written as a MUST, where other text in other parts of the ID state 
this is optional or preferred only;

              From 3.1.3:

   "First, the Location Object definition MUST
    include (optional) fields or mechanisms used to secure the LO as
    such."

            And then:

   "Second, the using
    protocol may also provide security mechanisms to securely transport
    the Location Object."

           And then:

   "The security mechanisms of the Location Object itself are to be
    preferred."

38. From Requirement 15.3)

   "The protocol SHOULD allow a bypass if authentication
    fails in an emergency call.

    The issue addressed in the last point is that an emergency call in
    some very unfavorable situations my not be completed if the minimal
    authentication fails. "

This requirement should be bound to a maximum precision of the LI fields 
within that LO transmitted during these emergency situations - but that 
text isn't present in this ID.

39. Section 6.3 refers to the emergency situation requirement 14.3, but 
it's actually Requirement 15.3

40. From Emergency Case

   "-  "If the emergency server does not authenticate itself,
       nevertheless send the location", or
    -  "If the emergency server does not authenticate itself, let the
    call fail". "

Although this seems like a good configuration plan, but doesn't solve the 
innocent bystander (a friend/colleague of the Target's owner) who might not 
want this configuration when they place the emergency call.

41. From 9.4. Truth Flag

   "Geopriv should not provide an attribute in object saying "I'm not
    telling you the whole truth." "

This should be a requirement in this document - as it would give away too 
much information to include it when the target is reducing the precision of 
their location purposely.

42. From 9.5. Timing Information Format

   "The format of timing information is out of the scope of this
    document."

This will breed incompatibilities if there is no default specified, and 
maybe even violate rules/policies that are based on the local or global 
timing of the location request.

I'd like to cover these topics/questions/concerns.

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"