Howdy,
Sorry for the delay in reviewing this document. I do have some comments.
First is on authorization methods:
Knowledge of the policy URI can be considered adequate evidence of authorization. A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT).
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 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.
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.
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.
Given the extensions in section 4.1, should this draft be listed as updating 5985?
I'd suggest changing the header for section 8.3. The meat of the statement appears to me to be:
To allow for the creation of Target-specific authorization policies that are adequately privacy-protected, every location URI and policy URI that is issued to a different Target MUST be different. That is, no two client can receive the same location URI or policy URI.
The current header is simply: Location URI Allocation.
Would it not be better to use something like:
"Providing distinct Location and Policy URIs"?
regards,
Ted Hardie
