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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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: [e-mail] 
>[mailto:[e-mail]] On Behalf Of ext Ted Hardie
>Sent: 15 August, 2008 21:01
>To: [e-mail]
>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
>   +----------+               +----------+               +----------+
>   |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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv