Subject: [Geopriv] [Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-00]

From: Richard Barnes <[email-masked]>
Date: Wed, 07 Oct 2009 18:08:52 +0100

Hey GEOPRIV,

I put together a short draft proposing a simple mechanism for allowing 
end users to control policy for location URIs.  Basically, wherever an 
LCP has a slot for a location URI, we add a link for a "policy URI", and 
define a very basic usage of HTTP for handling policy.

The one major thing that's missing from this draft is an extension of 
this mechanism to non-LbyR policy -- to allow the Target to provision 
policy related to third-party dereferences.  At least in HELD, I think 
this can be done by adding a similar policy URI link to the 
<locationResponse> element (i.e., a reference to the *overall* policy 
for theclinet).  But I didn't feel like mhy XSD mojo was quite up to 
defining this.

Comments welcome!

--Richard

-------- Original Message --------
Subject: New Version Notification for draft-barnes-geopriv-policy-uri-00
Date: Wed,  7 Oct 2009 10:00:55 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-barnes-geopriv-policy-uri-00.txt has been 
successfuly submitted by Richard Barnes and posted to the IETF repository.

Filename:	 draft-barnes-geopriv-policy-uri
Revision:	 00
Title:		 Location Configuration Extensions for Policy Management
Creation_date:	 2009-10-07
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's
location.  However, these protocols lack a mechnism for the htarget
host to inspect or set the privacy rules that are applied to the URIs
they distribute.  This document extends the current location
configuration protocols to provide hosts with a reference to the
rules that are applied to a URI, so that the host can view or set
these rules.

The IETF Secretariat.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Oct 2009 18:24:00 -0700

So, color me jet-lagged and stupid, but this seems like this goes down
a road we rejected once before.  If I am reading this correctly, the
Policy URI has all the rules which apply to the location info.  What
that creates is a sort of split LO, with the location at one spot and
policy at another.

In the long-ago-time, we agreed that doing that basically didn't work
because anything that blocked access to the URI blocked access to the
policy.  One response to that was to make sure that the defaults in an
LO granted no rights and so this block could not result in leakage
(the "only grants"theory).  This seems to substitute that theory with
the *whole* policy being separated from the location.  Is that right,
or did I miss some basic thing here?

I also, frankly, think specifying how the resource gets provisioned is
pretty much a secondary issue.  Sure, PUT and DELETE would work, but
so would a lot of WEBDAV style commands and so would XCAP style POST
etc.  The real problem is actually in determining who has the rights
to change them, and  HTTP's mechaisms for that are, as you know, not
all that useful in cases like these.

You can get around this mentally by saying all LI is really LO with a
default set of permissions (read: none), but that is deeply
impractical for getting the actual work of the group done, because
there is no way of ensuring that others know that is what you meant.
And blocking access to an all-encompassing policy URI seems to get us
back to that square one.

Am I missing something basic here, in my fogged state?

regards,

Ted

On Wed, Oct 7, 2009 at 10:08 AM, Richard Barnes <[email-masked]> wrote:
> Hey GEOPRIV,
>
> I put together a short draft proposing a simple mechanism for allowing end
> users to control policy for location URIs.  Basically, wherever an LCP has a
> slot for a location URI, we add a link for a "policy URI", and define a very
> basic usage of HTTP for handling policy.
>
> The one major thing that's missing from this draft is an extension of this
> mechanism to non-LbyR policy -- to allow the Target to provision policy
> related to third-party dereferences.  At least in HELD, I think this can be
> done by adding a similar policy URI link to the <locationResponse> element
> (i.e., a reference to the *overall* policy for theclinet).  But I didn't
> feel like mhy XSD mojo was quite up to defining this.
>
> Comments welcome!
>
> --Richard
>
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Oct 2009 00:36:42 -0500

Ted,

Given that this proposal is mostly "location-by-reference", you might have missed a little something, because I don't think your concerns apply in that case.

If I understand you correctly, your concerns are levelled at Richard's speculations on attaching policy URIs to non-LbyR cases.  In that aspect you are right.  That's why a LO contains policy.

I had other issues with both the speculation and the proposal.

As I have to point out on occasion - if the end device understands these LCP protocols, we shouldn't be using third-party requests for these protocols.  We don't need to.  Thus, we don't need the function that is speculated about.

Richard's speculations aside, the content of the proposal draft is largely sound, if somewhat ugly.  I have my objections (*cough* ball gown on a pig *cough*), I still don't like the authorization model for gaining access to the policy document, and overall it doesn't really improve on alternative proposals, but there is a useful kernel in this design and there are elements that I think are superior to what we've seen.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ted Hardie
> Sent: Thursday, 8 October 2009 12:24 PM
> To: Richard Barnes
> Cc: GEOPRIV
> Subject: Re: [Geopriv] [Fwd: New Version Notification fordraft-barnes-
> geopriv-policy-uri-00]
> 
> this

------------------------------------------------------------------------------------------------
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: Richard Barnes <[email-masked]>
Date: Wed, 14 Oct 2009 22:44:24 -0400

Hey Ted,

I think you may have gotten a little lost in the fog :)

The critical point to keep in mind here is that this document is focused 
on the role of the LIS as an LS, in the classical RFC 3693 sense of the 
word.  That's why the primary focus of the document is on location URIs: 
When a LIS issues location URIs and responds to dereference queries, it 
is de facto acting as an LS.  In this spirit, a policy URI is just a 
pointer to the rule interface on the LIS that the Target (as a Rule 
Holder) should access in order to manage policy on this LIS/LS, for a 
specific location URI.

In particular, this document is mostly independent of the rules attached 
to an LO, except that the policy you install at the LS could include a 
transformation that sets the ruleset-reference.

> One response to that was to make sure that the defaults in an

Not right.  We're still using the common-policy framework here, so 
policy documents still only contain grants of permission.  The only 
difference is that the the default access control policy for a reference 
might not be "default-deny"; it could be something like "open access 
until Tuesday".

I don't really think it's reasonable to assume that a LIS will use a 
default-deny policy, if for no other reason than that that policy would 
require any host that wants to use a location reference to go to the 
additional step of installing policy.  In the current proposal, the host 
only has to do policy if he cares whether the policy is anything other 
than "open until stated expiration".

> etc. 

This is certainly true, and I'm very open to suggestions.  I had 
initially thought about specifying something like XCAP or WebDAV, but 
was talked out of it, so I tried to just define something really simple.

> The real problem is actually in determining who has the rights

There's a real risk of "turtles all the way down" here -- who controls 
the policy on my policy URI.  Which makes it tempting to say that the 
"possession model" is good enough here.  The LIS knows that it handed 
the policy URI to the Target, who is an authorized Rule Maker, so anyone 
who accesses that URI is either the Target or someone the Target gave 
the URI to.  We can certainly add text advising the Target to handle 
policy URIs carefully, and security considerations encouraging 
confidentiality protection, if you think that would be helpful.

Hope this helps,
--Richard

---

From: Ted Hardie <[email-masked]>
Date: Thu, 15 Oct 2009 13:50:16 -0700

On Wed, Oct 14, 2009 at 7:44 PM, Richard Barnes <[email-masked]> wrote:

> only has to do policy if he cares whether the policy is anything other than
> "open until stated expiration".
>

I'm not sure that this is required; it seems entirely possible to instead
give a pointer to a well-known URI that has the policy "open until
stated expiration".  You don't need to create new URIs which duplicate
that policy, do you?

regards,

Ted

---

From: Richard Barnes <[email-masked]>
Date: Thu, 15 Oct 2009 17:56:56 -0400

Let me phrase it differently: The current HELD and DHCP-LbyR specs do 
not require the LS referenced by a URI to have a default-deny policy. 
The default policy that seems to be implied by both protocols seems to 
be "open until X", where X is a value specified in an expiry attribute. 
(In effect, they do what you propose, but with an expiry timer instead 
of a URI.)  I was assuming those documents as the starting point for the 
policy-uri document.

--Richard