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
JorgeRicardo@web.de
################################################
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
Received on Sun Jul 14 02:57:10 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST