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
> 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?
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".
> 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.
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
> to change them, and HTTP's mechaisms for that are, as you know, not
> all that useful in cases like these.
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
> 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 <rbarnes@bbn.com> 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
>>
>>
>>
>>
>>
>> -------- 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 <idsubmission@ietf.org>
>> To: rbarnes@bbn.com
>>
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
