Subject: [Geopriv] Some thoughts on rule-makers, targets, and rules

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Aug 2008 11:01:29 -0700

At the last IETF, there was considerable hallway discussion about a
set of drafts that discussed a topic using the shorthand "obo"
(on behalf of) for a class of uses.  We felt a lot of heat in the warm
Irish sun on this, and to keep our meeting room from boiling over,
Robert delayed the full-on discussion of it.  During the meeting I
offered to try to describe the problem in other terms, as I believe
the folks discussing the issue were talking past each other in some
pretty fundamental ways.  To try to resolve this, I'd like to take us
back a bit, to this famous set of boxes and arrows, rendered in the
finest fixed-width Courier:

                              +----------+
                              |  Rule    |
                              | Holder   |
                              |          |
                              +----+-----+
                                   |
                               rule|interface
                                   V
   +----------+               +----------+               +----------+
   |Location  |  publication  | Location |  notification |Location  |
   |Generator +-------------->| Server   +-------------->|Recipient |
   |          |  interface    |          |  interface    |          |
   +----------+               +----------+               +----------+

One of the things missing in this diagram is a labelled
"Target", a term that is pretty fundamental in RFC 3963.
The Location Generator has location for a specific Target,
which it publishes through the publication interface to
the location server; the Rule Holder uses the rule interface
to apply rules to one or more Location Objects about that Target
and the Location Recipients receive the Location Objects
if permitted by the Rule Holder and with the permissions the
Rule Holder applied.

You'll also notice that the boxes and flows refer to a Rule Holder,
where the Rule Maker's interaction with the Rule Holder is
off-stage.  The Rule Maker is pretty important, though.  To quote
from the principles set out 3693's overview:

 2) A critical role is played by user-controlled Privacy Rules, which
      describe the restrictions imposed or permissions given by the
      "user" (or, as defined below, the "Rule Maker").  The Privacy
      Rules specify the necessary conditions that allow a Location
      Server to forward Location Information to a Location Recipient,
      and the conditions and purposes for which the Location Information
      can be used.

Note, though, that the Rule Maker is not *necessarily* the
user, nor is the ability to make rules completely unfettered.
Forgive the long quote, but this is pretty key to the
discussion:

 Rule Maker (RM):
         The individual or entity that has the authorization to set the
         applicable Privacy Rules for a potential Geopriv Target.  In
         many cases this will be the owner of the Device, and in other
         cases this may be the user who is in possession of the Device.
         For example, parents may control what happens to the location
         information derived from a child's cell phone.  A company, in
         contrast, may own and provide a cell phone to an employee but
         permit the employee to set the privacy rules.

         There are four scenarios in which some form of constraint or
         override might be placed on the Privacy Rules of the Rule
         Maker:

         1. In the case of emergency services (such as E911 within the
            United States), local or national laws may require that
            accurate location information be transmitted in certain
            defined emergency call situations.  The Geopriv Working
            Group MUST facilitate this situation.

         2. In the case of legal interception, the RM may not be aware
            of an override directive imposed by a legal authority.  It
            is not the expectation of the Working Group that a
            particular accommodation will be made to facilitate this
            situation.

         3. In the context of an employment relationship or other
            contractual relationship, the owner of a particular location
            (such as a corporate campus) may impose constraints on the
            use of Privacy Rules by a Rule Maker.  It is not the
            expectation of the Working Group that a particular
            accommodation will be made to facilitate this situation.

         4. It is conceivable that a governmental authority may seek to
            impose constraints on the use of Privacy Rules by a Rule
            Maker in non-emergency situations.  It is not the
            expectation of the Working Group that a particular
            accommodation will be made to facilitate this situation.

In some of the discussions in Dublin, the Rule Maker
as an entity seems to have collapsed completely into
the Target.  As the above makes clear, there are cases
where the Rule Maker and Target are distinct. 

There also, however, are pretty specific exceptions made here
for emergency services which are not otherwise made.
In Dublin, some folks seemed to be describing the emergency
services model for providing location about a Target
as a general model.  The model *may* be general, obviously,
but given the exception language above, it is worth examining
whether the relationships would continue to fit into the
GEOPRIV framework without the emergency services
exception.  Perhaps I am not totally clear on the discussion
(since I was not at the Interim meeting where this all
started"), but some folks appear to be interpreting others as
saying that the systems put in place for emergency services should be
generalized so that location can be provided about a Target
without the Target having any ability to act as a Rule Maker
(or to limit the Rule Making to a single bit "yes to everything"
or "no to everything not mandated by law").

To put this another way, this discussion is *really* about
who gets to act as a Rule Maker for specific Targets and the
level of consent needed to transfer the role of Rule Maker
from the Target to some other entity.  In particular, there
seems to be one set of folks who believe that the role of
Rule Maker defaults to the Target, and another set of folks
who believe that the role of Rule Maker defaults to the
location generator (or, possibly "location provider") with
limited input from the Target.

To be upfront about my own prejudices here, I believe that
using the emergency services model as justification for
a general model is pretty silly, especially when references
are to 3GPP (which clearly uses non-geopriv technology and
is also willing to have separate systems for emergency
systems in general--witness the ECSCF).  On the other hand,
if I am willing to sell the role of Rule Maker to my
cellular provider in order to get a lower bill, I believe
I should be able to do so; everyone just needs to be very
clear that this is what is happening and agree that there
be a way for me to choose to be my own Rule Maker instead. 
What I do not think makes sense is for the Rule Maker's role
to default to the location generator; it should default to
the Target, with the recognition that it may move from there
either when the Target permits this or when the Target is not
competent to make rules.  In my personal opinion, "competent
to make the rules" is a statement about the Target, not the
device, and justifying transferring the Rule Maker's role by
reference to a device transition makes no sense.  The
Rule Maker/Rule Holder interface is different in one place
than another, but the issues remain the same.

These biases may affect my understanding of the situation here,
but they are strong enough that I needed to mention them. 
More generally, though, I believe we will get a lot further
in this discussion if go back to talking about the relationships
in terms of Rule Makers and Targets.  In too many cases here,
the "obo" phrase seems to be eliding the basic case here, where
we are talking *about* the Target when the Target is not
for some reason taking the role of Rule Maker.

By the way, I originally intended to pass this by Jon, but given
his happy tidings, I decided to go out on the limb on my own;
any slings and arrows should come my way.

					regards,
						Ted

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 18 Aug 2008 11:08:49 +0300

Hi Ted, 

Thanks for your mail and for highlighting some of the GEOPRIV
architectural aspects.

After our discussion I was wondering as well where the disconnect
between various folks in the group is. 

I would like to focus on two examples: 

* LIS-to-LIS Communication

In this case the assumption that the Target talks to a LIS and that LIS
immediately has all the necessary information in order to return
location information back to the Target isn't always realistic when
considering today's network deployments. Funny enough it wasn't even
possible to deploy a location server in the IETF#71/IETF#72 network
without having similar functionality, see
http://geopriv.googlepages.com/, where the LIS had to fetch data from
NETDISCO using a proprietary protocol. Instead of using a proprietary
protocol (with every different access network) I was hoping to simplify
the implementation and adaptation work by re-using existing work, in
this case the HELD Identity document in combination with the
measurements draft. [Whether the functionality needs to be split into 2
separate drafts is yet another story...]

Two IETF documents exist that describe the LIS-to-LIS case:
http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-0
0

The description can also be found in the UK emergency services document
as well. The same cases are applicable to other countries, such as
Germany. 

In this scenario, the Rule Maker can still be the Target and in general
it is fully equivalent to the description you provided referring to the
GEOPRIV documents. The only different is that the LIS is actually not a
single box but rather a distributed system as well. There, additional
"policies" have to be applied that not everyone is allowed to fetch
location information. These policies are indeed not set by the user
itself since the user is typically not aware of the network operator's
internal network topology and deployment strategy. With my request to
obtain location information towards a LIS I would also expect that these
details are hidden and I get a response back. 

I believe this is important and has to be captured in our documents as
well. 

* Indirect Publication

When it came to the security properties of resolving a location
reference we encountered two models: 
 -- authorization by possession
 -- authorization based on access control lists

The group agreed that both models are important to consider. 
The Target is able to combine the two mechanisms, for example using the
approach described in this document
http://www.shingou.info/svn/draft-garcia-simple-indirect-presence-publis
h/draft-garcia-simple-indirect-publish-00.txt

There, the LbyR is provided by the LIS and is then published, for
example, to a presence server the Target has a relationship with. This
presence server then holds the authorization policies and allows
authorization based on ACLs. The Target in this example, I believe, is
not required to upload it's privacy policies to the LIS in every access
network or only a limited set of them. Blasting privacy policies out to
everyone isn't such a great idea either. 

I want to stress that I am not suggesting to switch to a model where
privacy policies are created by operators, enterprise administrators and
regulators on behalf of the end user for usage of generic location based
applications. I hope that the examples above make this clear. 

Ciao
Hannes 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Ted Hardie
>Sent: 15 August, 2008 21:01
>To: [email-masked]
>Subject: [Geopriv] Some thoughts on rule-makers, targets, and rules
>
>At the last IETF, there was considerable hallway discussion 
>about a set of drafts that discussed a topic using the shorthand "obo"
>(on behalf of) for a class of uses.  We felt a lot of heat in 
>the warm Irish sun on this, and to keep our meeting room from 
>boiling over, Robert delayed the full-on discussion of it.  
>During the meeting I offered to try to describe the problem in 
>other terms, as I believe the folks discussing the issue were 
>talking past each other in some pretty fundamental ways.  To 
>try to resolve this, I'd like to take us back a bit, to this 
>famous set of boxes and arrows, rendered in the finest 
>fixed-width Courier:
>
>
>                              +----------+
>                              |  Rule    |
>                              | Holder   |
>                              |          |
>                              +----+-----+
>                                   |
>                               rule|interface
>                                   V
>which it publishes through the publication interface to the 
>location server; the Rule Holder uses the rule interface to 
>apply rules to one or more Location Objects about that Target 
>and the Location Recipients receive the Location Objects if 
>permitted by the Rule Holder and with the permissions the Rule 
>Holder applied.
>
>You'll also notice that the boxes and flows refer to a Rule 
>Holder, where the Rule Maker's interaction with the Rule 
>Holder is off-stage.  The Rule Maker is pretty important, 
>though.  To quote from the principles set out 3693's overview:
>
>In some of the discussions in Dublin, the Rule Maker as an 
>entity seems to have collapsed completely into the Target.  As 
>the above makes clear, there are cases where the Rule Maker 
>and Target are distinct. 
>
>services model for providing location about a Target as a 
>general model.  The model *may* be general, obviously, but 
>given the exception language above, it is worth examining 
>GEOPRIV framework without the emergency services exception.  
>Perhaps I am not totally clear on the discussion (since I was 
>not at the Interim meeting where this all started"), but some 
>folks appear to be interpreting others as saying that the 
>systems put in place for emergency services should be 
>To put this another way, this discussion is *really* about who 
>gets to act as a Rule Maker for specific Targets and the level 
>of consent needed to transfer the role of Rule Maker from the 
>Target to some other entity.  In particular, there seems to be 
>one set of folks who believe that the role of Rule Maker 
>defaults to the Target, and another set of folks who believe 
>that the role of Rule Maker defaults to the location generator 
>(or, possibly "location provider") with limited input from the Target.
>
>using the emergency services model as justification for a 
>general model is pretty silly, especially when references are 
>to 3GPP (which clearly uses non-geopriv technology and is also 
>willing to have separate systems for emergency systems in 
>general--witness the ECSCF).  On the other hand, if I am 
>willing to sell the role of Rule Maker to my cellular provider 
>in order to get a lower bill, I believe I should be able to do 
>so; everyone just needs to be very clear that this is what is 
>happening and agree that there be a way for me to choose to be 
>my own Rule Maker instead. 
>to default to the location generator; it should default to the 
>Target, with the recognition that it may move from there 
>reference to a device transition makes no sense.  The Rule 
>Maker/Rule Holder interface is different in one place than 
>another, but the issues remain the same.
>
>These biases may affect my understanding of the situation 
>here, but they are strong enough that I needed to mention them. 
>More generally, though, I believe we will get a lot further in 
>this discussion if go back to talking about the relationships 
>the "obo" phrase seems to be eliding the basic case here, 
>where we are talking *about* the Target when the Target is not 
>By the way, I originally intended to pass this by Jon, but 
>given his happy tidings, I decided to go out on the limb on my 
>own; any slings and arrows should come my way.
>
>					regards,
>						Ted
>
>
>
>
>
>
>
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 18 Aug 2008 11:19:33 +0300

... another issue I would like to talk about.

On the mentioned emergency services architecture chosen by the 3GPP &
co. To me it seems that there is a clear focus on emergency services
only. For location based services they have developed other mechanisms,
in particular within the OMA, and hence I was wondering why some of us
interpret their architecture in a way they themselves might not even
have envisioned yet. 

When an emergency call is initiated then context information provided.
In our case this context comes with the Service URN to indicate that
this specific communication is about an emergency call and that certain
policies with respect to the distribution of location information are
applicable. 

I am specifically focusing on the emergency services use case since I
believe this is indeed something that is going to see deployment with
SIP. With all the workshops we did I am trying to understand the pain
points of folks deploying our protocols and I got the impression that
some of them face problems with respect to incremental deployment and
there are also lots of fears regarding security. To mention one example:

 -- With emergency services deployments that are in preparation today
VoIP providers have to provide a story for  "legacy" devices that do not
implement the latest version of phone BCP (to put it mildly). They need
to figure out ways to still get the emergency call to happen. They come
up with their own solutions as we speak and there is very little we can
do about it (since we are not the deployment police). This happens
largely in the fixed environment with a clear focus on emergency
services. Is there help we can provide to them other than just telling
them "buy our latest X [where X stands for a particular box]"?

Another location based "application" we have been working on was the
SIP-based presence architecture. There, the role of the Rule Maker is
more or less clear (with the minor issue I described in my other mail).
Nobody, I hope, really envisions a deployment model where location-based
presence servers are located in every access network. Unfortunately, we
are facing a problem with the usage of SIP presence since the deployment
of the location based extensions depends on the successful deployment of
SIP presence in the first place ...

I am not so excited about speculating about potential location based
services (beyond the emergency services case), such as the famous pizza
delivery example, that the GEOPRIV architecture with SIP Location
Conveyance is going to be the preferred deployment choice. I have never
attempted to approach that "community" to figure out how they anticipate
things to work -- I doubt many others in the group have. 

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 18 Aug 2008 19:11:42 -0500

I've decided it's just easier to build my own pizza oven :)

I want to thank Ted for capturing the essence of the debate so well.

I believe all possible configurations of RM and target need to be
supported. And the "legacy device scenario" is only one example of the
use case where they are discrete and independent entities. If we exclude
any particular configuration, then we'll have defined a framework that
only addresses a subset of the location service solution space. This
will lead to the unnecessary proliferation of standards to address the
whole solution space - as well as raise the question of where the
mandate lies to define the solution space that GEOPRIV decides is
out-of-bounds.

A single framework can certainly address the whole solution space;
there's no doubt it's possible to define one. It should not obviate the
ability to implement any given configuration nor should it obviate the
ability to exclude a particular configuration. In order to do this, the
appropriate protocol mechanisms are required along with the appropriate
rules/guidance associated with them.

The identity extensions draft aims to satisfy these requirements.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, 18 August 2008 6:20 PM
To: ext Ted Hardie; [email-masked]
Subject: Re: [Geopriv] Some thoughts on rule-makers, targets, and rules

Ciao
Hannes

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 20 Aug 2008 11:02:44 +0300

Hi Ted,

as stated in my previous mail I am agree with your description. 

I was just looking at Section 5.2 of 
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-06#section-5.2
and it essentially summarizes what you said in your mail. 

I think it would be useful to capture your description in Section 5.2 of
that document. 

Would this be useful? 

Ciao
Hannes