Hey Ted,
<snip>
I have a hard time taking the proxy/log case as a huge threat, given that there are multiple widely-deployed privacy mechanisms out there that rely on possession. For example, every HTTP service that uses API keys in query parameters is subject to this risk, but there are huge numbers of such services. Indeed, OAuth carries tokens in URI parameters.
Then I suggest that the policy URI "age out" over time. As it stands, the policy URI is created by the location server and effectively never changes during the validity interval set for that location. Whenever it is used to get or set policy through a proxy (like a friendly interception proxy, let's say), it may be revealing itself. If the validity interval is long, this may be a problem (my employer may get or my ex-employer may retain access to the policy URI for my "home" location).
I am assuming that a location may be fairly long lived-e.g. created by my cable company for my "home" location and re-used with its policy URI for long periods. If the validity intervals are short and the LS does not re-use the policy URI when a new location URI for that same location is created, this is less of a problem (this latter problem may require some thought in the inputs to a hash-based mechanism for the creation of a policy URI, especially if an LS re-used the random entropy in a new run. It can neither use the location URI nor the location description, I'd guess).
<snip>
> It's also not clear whether a location server that allows clients to inspect policy but not update actually meets the goals of this document, since it either then requires some other side-loading mechanism or is incomplete.Being pragmatic about this, we can't really legislate what policies LS provider will apply. We could have a requirement that servers allow changes to policy, but that just risks that portion of the spec being unused. IMO, even being able to inspect policy is an improvement over the current state of the art.
No, but we can say that it is recommended for cases where there is no other way to set policy.
That was the intended semantic. This also relates to a comment from Hannes, which we tried to address with the following explanatory note:
> This statement about DELETE:
>
> If the request is authorized, then the Location Server
> deletes the policy referenced by the URI and disallows any further
> access to the location resource it governs.
>
>
> seems to imply that once a policy URI is DELETEd, it cannot be re-created with a PUT. If this is the intent, then this may need to be more explicit. Otherwise,a client may try to DELETE then PUT, rather than just PUTting over the URI. I don't think this is otherwise forbidden.
"
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval. The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
"
Does that make sense?
Not really, no. I was pointing out that some other systems might allow a DELETE of resource X followed by a PUT to resource X as a valid update method, rather than using a PUT to overwrite. This gives those two operations two different semantics, which I find personally confusing. The document says:
A DELETE request to a policy URI is a request to delete the
referenced policy document and terminate access to the protected
referenced policy document and terminate access to the protected
resource. If the request is authorized, then the Location Server
deletes the policy referenced by the URI and disallows any further
access to the location resource it governs.
deletes the policy referenced by the URI and disallows any further
access to the location resource it governs.
Overloading removing the policy URI with "delete access to the resource" seems like an un-needed optimization to me. As a client writer, I'd update the policy with a validity interval that is gone, set provide-location to false or something similar. That's just my personal take on this obviously, and if other folks feel that this is the optimization to make, I can live with it.
That would make sense to me. I'll try to figure out how to do it in xml2rfc :)
> Given the extensions in section 4.1, should this draft be listed as updating 5985?
regards,
Ted
--Richard
