Comments on "Good Practices for Capability URLs" FPWD

These are comments on "Good Practices for Capability URLs
W3C First Public Working Draft 18 February 2014" [1].

First of all, I am delighted that the TAG has decided to return to this 
issue. Before giving more detailed comments and notes, I should state my 
own general opinion, which was expressed repeatedly in earlier TAG 
discussions: although there are cases where it is reasonable to gamble on 
having URLs be kept secret, the Web is not in general designed to preserve 
such URL secrecy. That being the case, I think it's a mistake to encourage 
use of capability URLs. I worry that we will go down a slippery slope of 
requiring that user agents, proxies, logging software, etc. be required to 
maintain the confidentiality of URLs in cases where the current normative 
specifications do not require such confidentiality.

I believe this opinion is consistent with the draft Recommendations, but I 
restate it here because it was very controversial when I made this case in 
earlier TAG discussions (see below).

Here are some more detailed comments and notes. I hope these may be useful 
as you edit the draft:

* Perhaps you are already aware, but we had an ACTION-278 [1] opened in 
2009 substantially devoted to this topic. There was a lot of discussion and 
a lot of controversy. There were at least two followup actions:  ACTION-394 
[2] and ACTION-412 [3]. If you look at the tracker entries for these 
actions you will find links to extensive email discussion and also F2F 
minutes. My recollection is that the discussions did not lead to consensus, 
but a number of interesting aspects of the problems were explored.

* I am wondering whether Google Docs might be a use case along with or 
instead of Google Calendars? My recollection is that Google Docs use 
capability URLs in ways that may be more obvious to novice readers than 
what Google Calendar does.

* Perhaps a term like "delegation" (of access rights) might be more 
appropriate than "onward sharing"?

* Section 4 says: "There are disadvantages to using capability URLs arising 
from the fact that the URLs were not originally designed to be used in this 
way. " Indeed.

* Section 5.1 says: "The use of capability URLs should not be the default 
choice in the design of a web application because they are only secure in 
tightly controlled circumstances." I strongly agree. Might it be 
appropriate to highlight this conclusion in the Abstract and perhaps in the 
introductory text? The abstract hints at it but seems mushier.

* In the Recommendations: I encourage you to consider saying something to 
the effect that user agents (browsers), proxies, etc. and indeed the Web as 
a whole should not be relied upon to keep URLs secret, except where 
normative recommendations require such secrecy. (see comments above on 
slippery slopes).

* (maybe) There has been a lot of work on capability-based systems. I 
believe it's true that in almost all such systems that provide strong 
semantics relating to access control, the system controls the minting, 
cloning, and transmission to capabilities. To give a simple and well-known 
example: in Unix, file handles are created by the operating system in 
response to system calls, and only the OS can open or close a file or 
socket. The Web doesn't work this way. URLs are strings, and they are 
stored in clear text in all sorts of places like server logs. It might be 
worth including a section that basically says: "We know how to build 
capability based systems with strong semantics. The Web isn't one; don't 
expect it to be!"

Again, I am overall very pleased with the conclusions in this draft, and I 
think as a FPWD it's very good. I am gratified that the TAG is moving ahead 
in this area again. I would like to see some of the key recommendations 
signaled in the abstract and maybe in the introduction.

Thank you!

Noah

[1] http://www.w3.org/TR/capability-urls/
[1] http://www.w3.org/2001/tag/group/track/actions/278
[2] http://www.w3.org/2001/tag/group/track/actions/394
[3] http://www.w3.org/2001/tag/group/track/actions/412

Received on Saturday, 7 June 2014 04:57:07 UTC