Subject: [Geopriv] Minutes from Virtual Interim, 15 Sept 2009

From: Alissa Cooper <[email-masked]>
Date: Tue, 15 Sep 2009 17:46:49 -0400

Minutes - GEOPRIV Virtual Interim, 15 Sept 2009

An audio recording is available at https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=40370402&rKey=2d44cf3511d663ea

Summary (prepared by Alissa and Richard, with thanks to Marc for  
taking notes):

Intro
	-- No agenda bashes

GEOPRIV Arch discussion
-- Definition of a LIS
	-- Looked at how it's used colloquially, other SDOs' definitions
	-- Marc: Heartburn over "LCP"
		-- LIS shouldn't have to worry about policy
		-- Don't want LC defined as just giving a Target its own location
		-- Hannes: Trying to make what we're talking about more explicit
	-- James P: Keith noted that we can't rule out DHCP as an LC  
protocol, which means arch has to be consistent
	** Marc: LCP should be "LIS doesn't do any checking"
		-> e.g., identifiers that aren't verified by the underlying  
protocol, no explicit policy-checking mechanism
-- Device vs. Target
	-- James P will more clearly articulate his issue on the list

LOC-FILTERS
-- James P is concerned about conflict with location-conveyance
	-- Hannes will verify that there's no conflict
-- James P and Carl will provide reviews by Hiroshima
-- Hannes trying to work out what to do with error codes
	-- Recommendation to figure out semantics and then check with Adam
	
DHCP-LBYR-URI
-- This rev tries to resolve Hannes' comments
	-- Accepts most of them
	-- Didn't understand a few
-- Hannes: Concerned about authorization models
	-- James P and Hannes agreed that the auth model issue appears to  
have been resolved
-- Richard: Give people time to read most recent list posting
-- Richard: HTTP URIs still missing
	-- James P will get with Ted to figure this out

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Sep 2009 21:11:04 -0400

<individual-hat xmlns="urn:ietf:params:xml:ns:hats">

I'm going to try to frame this debate a little bit.

Let's start from the assumption that identity extensions are necessary 
for third-party/OBO queries.  My impression is that people are OK with 
the case where identifiers are included in queries from specific, 
authenticated, authorized entities (e.g., public safety authorities).

Now, we want to make sure that these extensions are not abused to gain 
unauthorized access to location.  So if we were to put forward a 
document defining identity extensions for third-party queries.  We would 
then have two options:
1. Forbid the use of identifiers in LCP requests, or
2. Assume that LCP usage is inevitable and require verification

Consider case (2) first.  The recommendation that we would want to make 
is for the LS to verify that the identifier actually corresponds to the 
target.  However, the identifiers in question will necessarily not be 
IP-layer identifiers (or else there would be no problem).  That means 
that we can't define an Internet-standard mechanism for this 
verification -- mechanisms will have to be network-specific.  So we're 
left making a vague statement that has to be re-interpreted for each 
network (or type of network).  Not very satisfying, but basically all 
that can be done.

Now, in case (1), we have to come up with some standards language to 
accomplish this prohibition.  Following our general goal, we would want 
something like, "The LS MUST authenticate requestors and apply 
authorization policy to requests containing identity extensions." 
However, what I've been calling the LCP Policy -- "For every location 
object, the Target of that LO is authorized" -- is a valid policy.  (You 
might even be able to express it in common-policy, if you had one entry 
per LO.)  And that puts us back into case (2).

This argument seems to me to imply that if we are to enable support for 
the third party requests that the emergency services community is 
requesting, then we will be stuck with the LCP usage as well, for which 
we can write recommendations that are unsatisfactory, but possibly clear 
enough for implementors to understand.  If one accepts this implication, 
we're left with a choice:
1. Provide support for third party requests and do our best on LCP use
2. Do nothing at all

My impression is that if we follow course (2) and do nothing, then the 
parties that are asking for us to do something (NENA, NICC, etc.) will 
invent something anyway.  Following course (1) would then not create 
anything that wouldn't be created anyway, and it would have the 
potential benefits of increasing interoperability and allowing this 
group to have some say over the privacy constraints.

So, to sum all that up, I think we should aim for some recommendations 
and privacy constraints on LCP usage of identifiers and move on.

--Richard

</individual-hat>

Alissa Cooper wrote:
> An audio recording is available at 
> https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=40370402&rKey=2d44cf3511d663ea 
> 
> 
> Summary (prepared by Alissa and Richard, with thanks to Marc for taking 
> notes):
> 
> Intro
>     -- No agenda bashes
> 
> GEOPRIV Arch discussion
> -- Definition of a LIS
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Sep 2009 20:17:32 -0500

+1

I'm working on text to this effect right now.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Thursday, 17 September 2009 11:11 AM
> To: Alissa Cooper
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Minutes from Virtual Interim, 15 Sept 2009
> 
> taking

------------------------------------------------------------------------------------------------
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: "Winterbottom, James" <[email-masked]>
Date: Wed, 16 Sep 2009 20:19:02 -0500

+1

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Thomson, Martin
> Sent: Thursday, 17 September 2009 11:18 AM
> To: Richard Barnes; Alissa Cooper
> Cc: GEOPRIV
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=40370402&rKe
> > y=2d44cf3511d663ea
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 16 Sep 2009 23:26:10 -0400

This is still geopriv, and not ecrit, right?
Why are we trying to mandate behaviors that are recommended for use of
extensions in an Internet environment, for location ultimately tied to
people, when the protocols we're defining can have other uses?

What if a hospital is using the protocol to allow people to locate
wheelchairs, internal to the hospital. Are we going to mandate that the
implementation must insist that the hospital require authentication for
anyone who wants to know where a particular wheelchair is? That should
be the choice of the hospital.

Please. Provide the mechanisms to make sure that authentication and
authorization can be done. Describe how to do them. Even recommend when
they're appropriate. But don't mandate them. Ultimately, the use of
authentication/authorization should be up to the implementers and/or
anybody who legally has a say in such implementations. IETF is neither
of these.

Do not assume that all use of this is for location related to emergency
services, or even for location related to people, or that the
governments writing the rules insist on privacy protections for such
people. Describe how to do it, and *recommend* when to do it. Don't try
to mandate it.
Barbara

> Sent: Wednesday, September 16, 2009 9:11 PM
> To: Alissa Cooper
> Cc: GEOPRIV