Subject: RE: Interim Meeting Agenda

From: Cuellar Jorge <[email-masked]>
Date: Sun, 02 Jun 2002 20:01:53 +0200

This is a preliminary version of the identified issues in
the draft:

<ftp://ftp.ietf.org/internet-drafts/draft-cuellar-geopriv-reqs-02.txt>.

to be discussed in the geopriv interim meeting. Please
submit comments to the issues, or more issues to the
mailing list as soon as possible.

Please refer to the text in the draft that relates
to the issue. If possible, supply also the suggested text
that you would like to see.

An updated version of this list will be posted after the
meeting.

Terminology
===========

Issue. 1.  In early paragraphs a big point is made about
       the user setting privacy policies, but then a
       distinction appears between the "rule maker" and the
       user and it is the rule-maker who has control. Review
       the text to make this more clear.

Issue is clear: will be corrected in next version.

Issue. 2.  LIF (in Req 4) is a typo, you mean "FLI"

Yes! (Issue closed)

Issue. 3.  Terminology: Computational Location Server
       ("CLServ")
       A Device or entity that computes or processes raw
       data to compute or derive location data, or processes
       location data to transform or refine the data into
       new location data.
       <Why is this CLServ needed?>

Issue. 4.  Section 3.5 ("further explanations") is
       unnecessarily long! Most of text will be removed
       afterwards. What remains?

Issue. 5.  Location Storage ("LStor")
       (different from Location Server: Think of pure storage devices as
       disks. They matter for privacy purposes! This is a
       Device or entity that stores raw or location data.)
       Is this an entity for geopriv considerations or
       should it be seen as an internal part of a location
       seeker or server?

Issue. 6.  Attributes: What is the relation (& difference)
       between Location Sighter (LoSi) and Initial Access
       Provider ("IAP")?
       Table in Section 3.1. "Roles and attributes" is
       perhaps still unclear

Issue. 7.  Figure 1 in Section "Data Flows": Replace Figure
       1 by a diagram describing the data flow which focuses
       solely on the process. Not all steps necessarily
       occur in every scenario. It seems appropriate to omit
       data transport because this uniformly raises the same
       set of concerns.

Issue. 8.  What is the difference between LI (Location
       Information) and LI (Filtered Location Information)?
       Is this necessary or convenient?

Issue. 9.  How do the attributes (of data flows) trusted
       (the data flow is governed by a contract that
       protects location privacy) and non-trusted influence
       the geopriv protocol?

Issue. 10.  Scenario 2: It is not clear why billing data
       includes location data, in the sense of the geopriv
       protocol.

General Requirements on the Protocols
=====================================

Issue. 11.  Are we not dealing with a protocol here but
       objects and the policy surrounding those objects?
       In a certain sense this is true: our main concern is
       a Location Object. But the rules that govern the use
       of that object, may be seen as a "protocol", what we
       call a "embedded protocol". Besides that protocol, we
       could also set some requirements on the transporting
       protocol or on the union of embedded and transport
       protocol. But anyway it must be made clear how the 2
       protocols together will manage the object.
       Is "embedded protocol" something like SASL? Or like
       SOAP? Or just a Location Object with some rules how
       the transport protocol should manage it?
       Does the Location Object include "commands" or
       "requests" for further processing"? (For instance:
       give me another data type or give me a pseudonym and
       credentials?)

The draft says:
   The geopriv protocol MUST be an embedded protocol: it
   defines a Location Object, together with the security
   mechanisms used to secure it.  The security mechanisms
   are of two types: on one hand the Location Object as
   such is secured, using cryptographic checksums or
   encryption as part of the Location Object itself, and on
   the other hand security mechanisms may be provided by
   the embedding transport protocol that uses the Location
   Object.  If possible, security mechanisms on the
   Location Object itself are to be preferred.

   We refer to the embedded protocol also as the geopriv
   protocol and to the combination of both the embedded
   protocol and the transport protocol as the combined
   protocol.

Issue. 12.  There is some confusion between MUST implement
       and MUST use.

There is a significant difference between MUST implement
and MUST use.  Note that the requirements discussed here
are requirements on privacy protocols for location services
("MUST implement").  Thus the requirements refer only to
the capabilities of these protocols.  For example,
requiring that the protocol supports integrity is not the
same thing as requiring that all protocol traffic be
authenticated.  In some cases, the explicit requirement
could be that the user always obtains a notice when a
certain situation arises (say, his location data was not
authenticated).  This is clearly not just a capability of
the protocol.

Location Object, besides Location Data
======================================

Issue. 13.  What are the contents (fields/attributes) of
       the Location Object? (This is a "MUST implement", not
       all location objects have to contain all fields)

Location Data: yes
Location Data Type: yes
Target Identity: yes
Timing information: ? (? TTL, ? sighting time)
Security-headers and -trailers (encryption information,
    hashes, signatures, etc): yes
Policies?
Policy format?
Remote Requests? (How the object should be further
       processed?)
Negotiation parameters for:
       cryptographic suites, etc.
       data types supported or available for the location
       seeker

Location Data
=============

Issue. 14.  Location Data Formats?

The embedded protocol MUST define one Location Object (both
       in syntax and semantics) including one data type
       (format) for location data that must be supported by
       all geopriv implementations.

Issue. 15.  Is it necessary for the geopriv object(s) to be
       able to carry multiple locations for the target?

Issue. 16.  "Full integrity issue" The protocol MAY NOT
       allow users to provide false information? Or
       the protocol SHOULD support transformations that
       introduce errors (For instance obfuscation:
       intentionally make the location values less accurate,
       adding randomness to the measurement)?

Current proposal: Both: no. If the user (more precisely:
       rule-maker) has the ability to enter a location, it
       may be false. Some Location Servers may provide an
       obfuscation service, but this is not a requirement.

Policies
========

Issue. 17.  Policy (def = ..in particular, the policy
       describes how location information may be used by an
       entity and which transformed location information may
       be released to which entities under which
       conditions.) Do we want to define a simple policy
       language? (For instance a table:
       requestor ID (can be a ordered list of regular
       expressions), credential (can be a ordered list of
       regular expressions), timing conditions, place
       conditions, type and accuracy of information the
       requestor may obtain (can be a list).)

Issue. 18.  Do really Location Sighters (LoSi, = Location
       Data Source) and Ultimate Location Recipient (ULR)
       need in general no rule-maker defined policies?
       Is the LoSi in some scenarios a "dumb" piece of
       Hardware, not generally publicly addressable or
       accessible.
       Therefore only rule-maker defined policies apply to
       Location Server (LS)

The draft says:

 The Location Data Source may be unaware of the full
policies defined by the Rule-Maker, but in that case it
will have to obey another set of "generic" policies,
consented to by the Rule-Maker, to transfer Location Data
(raw or not) to another entity.

 An Ultimate Location Recipient does not need to be aware
of the full policies defined by the Rule-Maker, but it will
obey a set of policies regarding the use and retention of
the location information.

Issue. 19.  Req 22 is out of scope for the objects
       themselves.

"Req. 22.  The "generic" policies (as opposed to the
policies created by the Rule-Maker) used by the Location
Data Source, by the Ultimate Location Recipients and by the
Location Server of some special scenarios to be discussed
yet, MUST be made explicit."

Identity Management
===================

Issue. 20.  Who will provide Identity management for
       pseudonyms or other privacy protecting identities?
       Will it be the geopriv protocol (i.e. "the embedded
       protocol")? The transport protocol? An interface to
       another (non existent) protocol?

Issue. 21.  Will the protocol support Role identifiers
       (like "administrator", "member-of-club-A", etc.) Also
       with context dependent meaning?

Issue. 22.  Req 21 is out of scope for the objects
       themselves.

"Req. 21.  When a Location Server accepts a policy from the
Rule-Maker, the target MUST prove to the combined protocol
that he owns the claimed group or role identifier that
should be passed to the Location Recipient.
   (For instance, if a Target wants the role identifier
   "medical doctor" to be passed to a Location Recipient,
   the Target must prove the claims to be a medical
   doctor.)"

Issue. 23.  Need a requirement that individuals or
       components may decline revealing their identity, but
       if they do so this must be a designated type of
       identity, allowing the policy to prohibit anonymous
       location-getting or serving. This is similar to the
       rules of caller-id. You can set your phone to
       disallow anonymous calls. You should be able to
       "disallow location-requests unless the recipient
       reveals their identity".

Issue. 24.  Requirement 14 says: The combined protocol MUST
       be able to hide the real identity of the Location
       Recipient to the Location Server. <Give an example
       where hiding the identity of the Location Recipient
       is what should be required: The target is not
       concerned about the Server identifying him and
       knowing his location, but identifying his business
       partners, and therefore habits, etc.>
         a) An example is required.
         b) Would this be the case of the location
      recipient is a police officer? If this is the case,
      should the requirements allow for an override of the

      Rule-Maker? Would this, in some degree, invalidate
      Req. 2 that policies are user-defined?

Security Requirements
=====================

Issue. 25.  "Req. 19. The embedded protocol MUST specify a
       minimum mandatory to implement Location Object
       security including mandatory to implement crypto
       transforms."
       This is seen by many as an unnecessary burden to the
       transport protocol, in particular to SIP.

Issue. 26.  Requirement 18 has text that is hard to
       understand, "The embedded protocol MUST be able to
       secure the  Location Object for the following message
       flows (mutual  end-point authentication, data object
       integrity, data  object confidentiality, replay
       protection, in the absence  of a time parameter): LI,
       Pol, LIF, LRequest, and PolInfo."

---

From: Andrew Daviel <[email-masked]>
Date: Tue, 04 Jun 2002 01:14:14 -0700 (PDT)

At the beginning of this process, I had a couple of
Internet drafts, mentioned in the charter.

One described a method for including position information in an
HTTP transaction. This would typically involve sending position
information from a mobile device. The issues which are being discussed in
this group regarding privacy and security apply to this and
the draft is in abeyance (expired) pending a final privacy draft.

The other described a method for adding machine-readable location
data to legacy HTML documents. The intention was to provide
this location on static documents only. The privacy and security
implications of this are identical with those of someone placing their
address or phone number on the Web and someone else searching for it.
I believe that this is outside the charter of this group, and I
would like to get a statement to this effect so that I can progress
the draft.

It is, however, possible for this scheme to be (mis)used to
provide location information about a mobile device on a dynamic Web page.
I would propose that a revised draft explicitly discourage this usage
and that if necessary it be addressed in a later draft following
conclusion of the current work. I.e. I would
like to split the provision of dynamic location information about
people from the provision of static location information about
buildings etc.

HTTP draft
http://geotags.com/geo/draft-daviel-http-geo-header-03.html

HTML draft (revised since submission as RFC)
http://geotags.com/geo/draft-daviel-html-geo-tag-05.html

Andrew Daviel
Vancouver Webpages