Subject: RE: Q&C regarding geopriv-reqs-02

From: Cuellar Jorge <[email-masked]>
Date: Fri, 21 Feb 2003 20:21:18 +0100

Hi James,

here are my responses.

Cheers,

Jorge

-------------------

1. Jorge will add some text

2> The LO contains more than LI, PI, SI, it contains
2> identifiers for the target and recipient, credentials,
2> etc. (See Req. 2).

> what you mention I believe is what I would consider part
> of the construction of the Geopriv envelope (including a
> Geopriv version #) which has as it's main payload the LO

This is a different terminology.

This "envelope which contains target, recipient, credential, version
nr, etc and as main payload LI, SI, PI" is what we call LO.

2> !We should make this clear in the text earlier than in
2> Req 2.

> OK - I'm not trying to design this already, just want to
> point out the elements we know will have to be included in
> the protocol within this doc

2> You can easily build up a message with those fields intended
2> to mean "recipient x has obtained LI for target y in such
2> accuracy".  That is basically what you need to construct a
2> notify message.

------------------

2. + 3. fixed

------------------

4.  Jorge will provide some text

> OK

------------------

5. Do you suggest adding some text here?

> I need to review this again before answering - I don't
> have everything in one place here

------------------

6. fixed (?!!!)

5> Privacy yes, but the amount of privacy could change
5> (be more or less) based on the amount of LI
5> given. This is the foundation for the Resolution
5> Fields; in other words, if device X gives location
5> precision that is down to the millimeter, that Geopriv
5> message should be considered for higher privacy
5> controls than if device X merely gave the location
5> precision of 1/6th that of the Earth (for where it
5> is). Then there might not be very much (or no) privacy
5> controls.

4> In both cases there is privacy control.  And it is
4> exactly the same privacy control check, base on exactly
4> the same policy rule. In one case the privacy compliance
4> check may say ok in the other it may say not ok.

3> Oh... so this is a binary choice and not multi-leveled? I
3> thought we would have a situation where there was
3> something like a template for users to generally adhere to
3> (by their choice), of basic categories of how to fashion a
3> response to a Location Request. Something like:

3> 1. fail the request
3> 2. pass the request, give which hemisphere you are in
3> 3. pass the request, give the time zone you're in
3> 4. pass the request, give the country/province you're in
3> 5. pass the request, give the province/state you're in
3> 6. pass the request, give the city you're in
3> 7. pass the request, give the city quadrant you're in
3> 8. pass the request, give the street you're on
3> 9. pass the request, give the street address you're at
3> 10. pass the request, give the floor of the building you're on
3> 11. pass the request, give the office/cube # you're in

2> I see what you're saying.  This to me looks like an
2> implementation choice and not logically any different than
2> what I am saying.

> I know it's more of an implementation choice in
> appearance, but we can make all implementations easier in
> our design. The above is on way of implementing the rules
> behind the rule maker interface - and should be a very
> popular way of doing it.

2> But I would say that the LS is checking
2> the authorization against one rule and choosing the
2> precision or resolution to be used.

> So, if what you're referring to "...checking against one
> rule..." is my separation from step 1 and step 2, then I
> can understand your explanation.  But it might present a
> problem:

> Are we going to limit all successful location queries to
> only those people we have shares our passwords with?

No! first, you can use other credentials than passwords or
codeword; second you can say "all other people get <this
resolution>"

> Or do we go down the 2 step (or more) process of allowing
> a location query to be successful by most requests, but
> just limit the template resolution of the reply to be
> based next (step) on who's asking for our location, with a
> much less precise LI for my Target those I don't want to
> know where I am other than my time zone of hemisphere (for
> example)?

> I know we want to prevent a location version of
> telemarketers, but we can be more open than only allowing
> 10 or 100 Location Seekers access to my location (which it
> sounds more like the implementation you are possibly
> proposing).

Sure, this can be done without the template too.

2> I call the 11 steps of
2> your implementation design *one* privacy control.

> Yes, one of *privacy* control - but if you severely limit the potential
for
> a successful query, you won't need to worry too much about privacy
control,
> you'll know all 10 people you've given your password to.

3> This list is a generic template, and a user moves people
3> (Location Requesters) in and out of each category. A more
3> complex situation or end device might have time of day
3> adjustment of what type of reply they get to an authorized
3> query.

2> I see.

3> Obviously this is a 'civil' template example, but it is
3> the easiest to visualize.

2> Yes.

3> In this template example of categories, it isn't just a
3> case of a location reply being authorized or not, it's who
3> was authorized, what time they were authorized - and based
3> on a rules engine on the Location Server for that Target,
3> a the appropriate reply is generated.

3> This might make for a whole bunch of a long list of
3> rules. I like to look at this from a time of date routing
3> perspective from IP Telephony. I'll wait for your (and
3> other feedback) on this template category proposal I've
3> suggested above before going further.

------------------

7. James will provide some text

------------------

8. James will provide some text (on 2 different
              topics/places?)

------------------

9. fixed

------------------

10. Jorge will use the text and defs sent by James

------------------

11. fixed (?) (was: Why would LI be optional?)

3> This is rooting in our general disagreement in how the LO
3> is used. If the PI and SI is all relative to the LI, then
3> the absence of LI should negate the use of the LO.

2> Not necessarily. The PI are the policy rules, and they are
2> logically attached to the target.  For instance I could say:
2> " to all other people, send only the time zone I am" is a
2> policy (PI) without a LI.

> I this quoted above, if taken alone, is a UPDATE message
> to an LS that has a preexisting relationship (or
> configuration) with that Target.

> If the quote above is within the initial configuration or
> rules to follow (by the LS) for that Target, then this is
> more of a Registration/log-on transaction.

It is the message by which a RM tells the LS which rules to
use. This can be part of the LO.

> The latter example might have the LO included in the
> message, but the former is quite possibly a change request
> between the rule maker and the LS with regard to a
> specific Target, and I an LO has already been sent
> previously.

2> And there are many other examples.

3> All other messages should be of another form and not use and
3> LO to transmit or request information (like UPDATE and
3> NOTIFY messages would intuitively accomplish)

4> "LO" is the generic geopriv object, that should be used
4> also for notifications (if they are geopriv messages).
4> This is another possible use of LO without LI.

3> Why would a Notify message described above need the PI and
3> SI of a target?

2> No but it would use other fields of Req 2.

> Right... then there could be another packet format that's
> tailored for the purposes of something like a Notify or
> Update or Log-on or Register. I don't believe it should be
> more complicated that these examples

True

3> I'm having a hard time not believing you consider an LO to
3> be a generic term for any and all Geopriv messages... I
3> must be misunderstanding something still

2> No, this is right: the LO is the one and only one Object in
2> geopriv.  At least until now.

> I have to say I'm not in agreement, but I might be the
> only one who doesn't agree at this point - and will bow to
> group consensus if there is one

------------------

12. James will provide some text

------------------

13. James will provide some text

------------------

14. Jorge will provide some clarifying text

------------------

15. fixed, or do you wish some clarification text?

------------------

16.  fixed (?)

4> Actually, in some cases, like for instance when the data
4> is publicly know, there is no need to have a security
4> relation to exchange LO.

3> but once the SA is up and running, then all private into
3> can be exchanged without regard to any other
3> constraints. This is what I was looking for.

> I need to review this topic again to be sure

------------------

17. fixed

------------------

18. fixed (?)

3> I'll bow to your definition if
3> you put text in the ID stating a Target can be a person
3> (or something non-IP based, or even non-electronic)

2> I read the text as saying that (?)

> I don't remember the text saying the equivalent of Target
> = person (as one of its possibilities

Quote:
Target:
   The entity whose location is desired by the Location Seeker.
   In many cases the Target will be the human "user" of a Device
   or an object such as a vehicle or shipping container to which
   the Device is attached.  In some instances the Target will be
   the Device itself.

------------------

19. Jorge will provide some text

------------------

20. James will make probably further suggestions

4> Because an ULR needs different policy information than
4> another recipient, which may pass this information
4> further.

3> Why can't the ULR just disregard what doesn't pertain to
3> it in this instance (which will always be a superset of
3> what it receives)?

2> Yes, this is one mechanism.

> Then if this is true, we can expand the definition of the
> Location Seeker and do away with ULR, no?

No, a LS may be also a Loc seeker.

------------------

21.-24. fixed

------------------

25. Jorge will try to use the words correctly in
2>               the new version of the draft and James will
2>               check it.

------------------

26. fixed (?)

2> Yes, this is strange.  Of course, you will authenticate end
2> identify sometime to somebody, but there is technology
2> around to create credentials that, like money, show that you
2> have some authorization status without telling who you are.
2> Of course, you have to identify yourself to the bank and to
2> the employer, but they do not know what you are doing with
2> your money.  The paradigm is similar here.  Much of the
2> business of privacy is how to do access control without
2> identification.  See for instance www.ra-pid.org, look for
2> identity management and PETs in infrastructures (section on
2> authorization privacy).

3> Now how do we accomplish this without you or I reveling
3> ourselves in the packets, yet knowing each is who we say
3> we are in people time?

2> For instance, using electronic tokens, like e-cash. But
2> there are other methods.

> But how do you set up a rule allowing me (who doesn't
> reveal my identity) to access your location?

yes my rule says the person who is able to present this
token may obtain my location  to this level of precision.

> And then, how do you determine which level of precision you choose to
> provide in your response to me?

Because my rule says it

2> Do you see there explicitly some incongruence in the reqs
2> related to Authorization and Identity Management? (Req
2> 12. and 13.)

------------------

27. fixed (?)

7> "Authorization

5> But how do you determine who is who if pseudonyms are
5> used?

4> For instance (although this is not the best solution, it
4> is easy to explain) you can give your friends a codeword
4> to access your location.

3> But my friends will know it's from me because I gave it to
3> them out of band (from Geopriv).

2> Sure!

> yes, but this is quite limiting in who you will even
> accept a location query from

This is why this is not the best solution.

3> I want to put the type of person (wife, son, boss,
3> co-worker, friend, etc as URIs) into and out of categories
3> in a user friendly template that has established
3> rules/policies, then adjust from there the specifics. Let
3> these people authenticate to some service I trust, and
3> their URI in the request will determine the type of
3> response they receive.

2> Sure!  I can tell the trusted server: give Alice a token
2> stating that she is a friend of mine, and give Bob one
2> saying that he is a co-worker.  Then they use those e-tokens
2> at the LS to obtain the LI without disclosing who they are
2> to the LS.  This is another possible solution.

> I must be tired or something else - because I believe you
> just contradicted yourself.

Probably you think that the "trusted server" that provides
credentials is the LS. It is not. It is a trusted "identity
provider".  I tell the IP: give Alice a credential saying
she is "friend of Jorge" (or another attribute).  Alice uses
the credential at the LS.  I have told the LS that anybody
who presents a "friend of Jorge" credential signed by the IP
may get my location in a certain resolution. (This is my
policy rule). The LS has no problem in applying the rule and
my friend Alice obtains the location.  Nevertheless the LS
does not know who was the location recipient.

There are still variations of this, in which the IP is not
knowing which attribute of the Alice he is signing, only that
it is what Jorge requested to be ("blind signatures").  See
the references mentioned in the draft.

------------------

28.  James will provide some text

------------------

29. fixed

------------------

30. I don't see what to change in the draft

> I don't read in one of your examples how the Geopriv
> protocol will formulate a "push" packet on its own. Upon
> turning on a notebook, it could have a program that sends
> something like an Update packet to its home LS.  But how
> will the LS know which AP it's in? The AP servers don't
> inspect the Geopriv packets and incorporate something like
> a SIP VIA header showing a path back.

The AP plays no role in *that* example

> The reqs ID doesn't cover this instance at all IMO. Nor
> does it cover the case in which you and in your car and
> you drive outside of your AP's home domain. It should then
> loose contact with you (and your device). there was no
> power-up sequence to cause a Update or Register packet to
> be sent (each of which aren't yet defined or mentioned yet
> BTW).

I don't see any requirement that would be missing, do you? I
think this discussion should go into the scenarios draft,
not in the reqs draft.

3> How will AP 2 know the Target one left its home domain?

2> This is solved in mobile ip using the NAI

> But Geopriv has to have a "push" mechanism to perform this
> - and if you agree, then it needs to be mentioned within
> this ID so it can be created in future work.

This push mechanism would be in the using protocol, not in a
"geopriv protocol".  All geopriv wants to do now is define
the geopriv object (alias "Location Object") that will be
used by using protocols.

2> will recognize the IP address (CoA and Home Address), will
2> ask the home LS where to get the rules from this HoA (only
2> the home nw will generally know who the user is, but this is
2> enough), and the LS of the visited domain will send the
2> information based on this dynamic CoA.

> I think you're assuming the remote network become aware of
> this new roaming Geopriv device through Mobile IP, and I
> believe this should be a Geopriv transaction (or
> action). And I don't believe this is addressed yet

It is not addressed yet, this is way out of scope of our
reqs draft

2> Oh, ok.  So your problem seems only to be the paging.  You
2> are right: if you are not connected to the nw, and there is
2> no paging mechanism for your idle target, you will not be
2> recognized.

> This is what I'm referring to - how do we solve this? I
> think this should be a requirement now for the WG, and I
> don't think the charter prevents us from addressing
> it. This could be the subject on a completely separate
> solution ID (one I'm not going to write, mind you!). I
> believe by putting this into our reqs ID now, we expect
> someone to step up and solve it sometime down the road (it
> doesn't have to be today). Leaving this topic dangling or
> unaddressed, means it remains lingering until someone puts
> it in another requirements ID.

This is way out of scope of our reqs draft and I think even
out of the geopriv charter.  I do not see how you want to
tackle the problem in geopriv. If you are not connected and
you are not sending signals whatsoever, what could one
expect? If you want to send some sort of lightweight
signals, with an almost idle notebook, that sounds to me
like seamoby.  For me that has little to do with geopriv,
and surely nothing with our reqs draft.

------------------

31. fixed (?)

4> Suppose the generator contacts the LS and ask him which
4> LI granularity he wants, and thereafter only sends this
4> required information.

3> this is suggesting a PDP/PEP relationship - which is new

2> Yes.  One of the problems in geopriv is that it has to work
2> in all kinds of scenarios that you haven't thought before!

> I still don't like decisions like this being made by
> devices/entities/servers that have no knowledge of the PI
> and SI of a Target (which is its home LS). We're begging
> for gaps in our delivery if we allow this to continue

I do not see the problem in our example. If the generator
knows the privacy rules, he is also a LS.

If he does not know the rules, and does not ask the LS which
granularity and frequency he wants, he will be sending full
resolution, which is not better.

2> I do not know what is a geopriv transaction.

> A "Request/Response" (pass or fail),
> A Notify/Response
> An Update/Response
> A Register/Response
> A Sighting (sent to the LS)/Acknowledgement back
> A Rules look-up/Acknowledgement back
> These are all what I consider Geopriv transactions (i.e.
> point to point "push and acknowledgement" or "pull and
> answer")

I meant: I do not think that there is a geopriv transaction
concept at all. As I said above, All geopriv wants to do now
is define the geopriv object (alias "Location Object") that
will be used by using protocols, at least today.  If there
is a transaction it is a transaction of the using protocol.

Even if there would be a geopriv transaction I do not see
how this discussion is relevant for the text of the reqs
draft. 

------------------

32. From Requirement 2.5 Location Field.

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

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

4> Suggestion for our draft?

3> none if another ID should be written...

3> But I think what you call "Location Representations" here
3> is what you call "Data Types" elsewhere

2> I do not think.

> Then "Location Representations" needs to be defined somewhere

From draft-morris-geopriv-location-object-issues-00.txt:

The relationship between LO, Locations and Location Representations
may be seen schematically as follows: The Location Object MAY contain
zero, one, or several Locations (= Location Fields) L1, L2, etc:

LO =
+------+------+------+------+------+------+--------+------+
|  ID  | Cred |  ..  |  L1  |  ..  |  Li  |  ..    |  Ln  |
+------+------+------+------+------+------+--------+------+
                     \_______________  ___________________/
                                     \/
                             Location Information

The intended semantics of the Location Information is then that one
of the Li is

  Location Information = L1 or L2 or ... Ln

in the sense that the Location Information "holds" (for whatever
purpose the using protocol uses the location) exactly if one location
Li "holds".

Further, a Location (field) Li is MAY contain different "Location
Representations"

Li (i=1,.., n)  =
+--------+--------+--------+--------+--------+
|  LRi1  |  LRi2  |   LRi3 |  ..    |   LRim |
+--------+--------+--------+--------+--------+

The intended semantics of a Location Li is

  Li = LRi1 and LRi2 and ... LRim

in the sense that location Li "holds" (for whatever purpose the using
protocol uses the location) exactly if all location representations
LRij "hold".

------------------

33. should we move 2.7 to 2.5.1?? Would you accept
2>               that as a solution?

------------------

34. fixed (?)

2> but I would use a very different terminology.  I
2> would say: a Location Request contains the Data Types and
2> Precision it wants to receive.

> Date Types shouldn't include all the possible optional LI
> Fields, having each possible sequence of them called a
> unique number or name. I believe the LI fields can/will be
> individually named and can therefore be individually
> called out.

I think this would be a good choice.

------------------

35. James will discuss this with Henning and try
2>  to come with a better solution to the one in
2>  the draft. (Topic: delta format reduces the
2>  packet size?)

> This is like relative position. We all want it. But the
> Target or device shouldn't have to calculate it, IMO. If
> it can, then all the better.

Of course it is not the purpose that the target or device
MUST calculate the delta.  But that some MAY, if they can
and prefer to do so.  Or a generator, if he chooses to.

------------------

36. fixed

------------------

37. Jorge will try to change the wording in 3.1.3
2>               as not to suggest that this weakens Req 4

------------------

38. James will provide this open ended pointer (that
7>               the IESG will accept)

------------------

39. fixed

------------------

40. James come up with some text

------------------

41. fixed!

------------------

42. fixed