Subject: Requirements draft: issues

From: Ricardo Cuellar <[email-masked]>
Date: Sun, 14 Jul 2002 08:56:27 +0200

All,

This is the current list of issues identified in the draft
<draft-ietf-geopriv-reqs-00.txt>.

The goal of this list is to identify the changes required to furhter
advance this document. Please submit comments to the presented issues,
or send more issues to the mailing list.  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.

Regards,

Jorge

---------  Out of town: -------------
    Fax & Voicebox: +49 (0) 12125-130-30-549 
    [email-masked]

################################################

Status of issues:
<Cl>: Closed, changes are reflected in the current verion of the draft
<Se>: Settled, but text in the draft is missing
<Op>: still open

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

I <Cl> 1.  Use of the word "user" at beginning of the draft

I <Cl> 2.  LIF (in Req. 22) is a typo, meant was "LI", but this is
       redundant ("FLI" has been dropped).

I <Cl> 3.  Terminology: Computational Location Server ("CLServ")
       CLServ is not really needed, but mentioning is OK.

I <Se> 4.  Section 3.5 should be re-written, but content is relevant.
       It is necessary to talk about identities (Section 3.5.2),
       this issue is not only something for a using protocol (IM, SIP)
       to handle.

       There are 2 types of identities: well-known and anonymous.
       There are cases in which well-known identities are used for
       many purposes, those identities may be global IDs taken from
       the using protocol (say, SIP), and, on the other extreme, there
       are cases when the target does not need any identifying
       information from the requester.

       Suppose SIP uses ID; geopriv could recognize it as a SIP ID (or
       a URI or a text field or whatever). This is not simply an
       instance of an opaque ID, merely handled by geopriv; geopriv
       may use the ID.

       IDs must be allowed in the geopriv object. That is, geopriv
       MUST implement, but not always use, identities, but geopriv
       does not necessarily specify the namespace.

I <Se> 5.  Location Storage ("LStor")
       A policy  should cover retention, for instance: "You may not
       store my location for more than 2 days" or "this
       location information must be deleted after <date-time>"

I <Se> 6.  Attributes: Location Sighter (LoSi) vs. Initial Access
       Provider ("IAP"): IAP is a special case of a LoSi.

I <Cl> 6a. Table in Section 3.1. "Roles and attributes" is
       still unclear

I <Cl> 7.  Figure 1 data flows -- discuss later. Delay until scenarios draft
       discussion.

I <Cl> 8.  What is the difference between LI (Location
       Information) and FLI (Filtered Location Information)?
       Is this necessary or convenient?

       Explanation: "Filtering" is the translation from one "data
       type" to another, say from coordinates to e.g., time zone, or
       the intended dismi?? of ACCURACY of location: while one
       location recipient may know the location precisely, another may
       know the location +/- 100 km, etc.

       The difference between LI and FLI is not necessary: Although
       geopriv must allow the target to insert vagueness or
       inaccuracy, it should not allow location seeker to know the
       degree of precision specified by the Target.

       Thus FLI is dropped.

I <Cl> 8b.  (The "accurcy flag" issue).  It is not useful to provide
       an accuracy attribute in object, i.e., a flag saying "I'm not
       telling you the whole truth."

I <Cl> 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?

       They don't.

I <Cl> 10.  Scenario 2: "Accounting", instead of "billing" data.

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

I <Se> 11.  Are we not dealing with a protocol here but objects and
       the policy surrounding those objects?  We are specifying not
       only objects but also how they are to be used.

       The geopriv protocol defines a Location Object (LO), 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.

       Does the LO include "commands" or "requests"? YES.

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

I <Cl> 12.  MUST implement vs. MUST use.

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

I <Se> 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: YES (But exaclty which one?: 
          Need probably more than 1 timestamp: 
          (1) When was the LI accurate? (sighting time)
          (2) Until when should the LI be considered current? TTL (Time-to-live)
          (3) Until when are you permitted to retain the LI? (delete-after)
       Version number: YES
       Security-headers and -trailers (encryption information,
           hashes, signatures, etc): yes
       Policies: YES: Exactly which/how?: Use, disclose, retain
       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
=============

I <Cl> 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. The location data is not opaque.

I <Op> 15.  Is it necessary for the geopriv object(s) to be able to
       carry multiple locations for the target? (The "multiple
       locations" issue). The protocol should allow multiple Locations
       within one Location Object, meaning that the intended location
       is one of the Locations included in the LO.

I <Op> 16.  Should inaccuracy be introduced in the LS/proxy, or
       elsewhere? (The "full integrity" issue). The protocol SHOULD
       NOT try to prevent users of providing false information.  The
       protocol SHOULD NOT support transformations that introduce
       errors.
 
       Geopriv should not facilitate the misrepresentation of location
       information (but it should also not try to prohibit it).

Policies
========

I <Op> 17.  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).

I <Se> 18.  Location Sighters (LoSi, = Location
       Data Source) and Ultimate Location Recipient (ULR)
       need in general no rule-maker distribute policies.
       Therefore only rule-maker distribute policies apply to
       Location Server (LS)

       The LoSi 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.  Thus the ULR does need to receive a statement of
       the terms on which it is receiving the LI, e.g., ``You must
       destroy this information within 24 hours'' and a
       do-not-distribute bit.

I <Cl> 19.  Req. 5 is in scope of geopriv.

      Req. 5.  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 MUST be made
            explicit.

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

I <Se> 20.  Who will provide Identity management for
       pseudonyms or other privacy protecting identities?

       Geopriv should provide some means of identity management (to
       create, distribute, agree on, and authenticate pseudonyms,
       etc.).

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

       No.

I <Se> 22.  Is Req. 19 out of scope for geopriv?

       Req. 19.  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.  <But probably group
       or role identifiers will be discouraged in geopriv.>

I <Op> 23.  Need a requirement that if individuals or components
       decline revealing their identity, but then 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".

I <Cl> 24.  Example and further explanation in Req. 18 have
       been added (Req. 18: The combined protocol MUST be able to hide
       the real identity of the Location Recipient to the Location
       Server.)

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

I <Op> 25.  "Req. 23.  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.

I <Se> 26.  Req. 22 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,
       LRequest, and PolInfo."

______________________________________________________________________________
500 WEB.Cent Belohnung! Nur noch bis 24. Juli 2002 im WEB.DE Club.
Worauf warten Sie noch? https://digitaledienste.web.de/Club/?mc=021109