Thanks a lot for your review. Some comments inline:
> For baseline HTTP requests, the policy URI will show up in both proxy caches and local logs, so there is some reason to doubt that relying on a proof-of-possession model will make sense. I think the authors' "allow to inspect" but not update is a reflection of the unease that simply knowing the URI is enough to allow you to change the polcy. Since the policy document itself can leak privacy sensitive data, I think the same issue applies to GET, though I agree that the threat is less.
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.
> I don't personally find the text here and in 8.2 to address this complete enough, partly because the parallel to RFC 5808 isn't justified and partly because the issue isn't tackled head on. At minimum, I think the doc should review the reasons for this choice in more detail. I personally think that a stronger authentication regime should be considered as a SHOULD, with a MAY for the less stringent mechanisms when other conditions are met.
I thought the base problem was that you wanted to provide some basic level of protection to a hosts that connect to a network without having a shared key with the LS. Clearly, a server MAY require authentication, but it doesn't seem to me like there's enough likelihood of an appropriate authentication system being present to make it a SHOULD. Am I missing some obvious cases?
> 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.
> 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.
That was the intended semantic. This also relates to a comment from Hannes, which we tried to address with the following explanatory note:
"
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?
> Given the extensions in section 4.1, should this draft be listed as updating 5985?
That would make sense to me. I'll try to figure out how to do it in xml2rfc :)
--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
