Re: Comments on "Good Practices for Capability URLs" FPWD

On Sat, June 7, 2014 06:56, Noah Mendelsohn wrote:
> 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.

Based on the current set of recommendations you may be made to think so.
With some added recomendations, most notably the use of fragments as
described in the waterken page I and others linked to earlier, there would
be no such requirement implied.

We should also consider the implications of encouraging the use of
identity, passwords, cookies, ACLs, federated identity management etc,
that each have their security issues. Issues that unlike those with
capability URLs seem to be fundamental and unfixable.


> 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 andat 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"?
>

Excellent point.


> * 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.

Wrong, there "can be" disadvantages to using capability URLs "without
proper precautions"

> * 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.

See my previous comment on this topic a few days back. This draft should
not make any such recommendations given that there are multiple reasons to
make capability URLS the default and most security aware choice. This
draft should be about recommendations on how to safely use capability
URLs. Capability URLs can be fixed. Many alternatives AFAICS can not. In
any case this draft IMHO should just be agnostic on this given that
capabilities are by many seen as part of the solution for graver problems
with other technologies that are implied to be 'the default choice' by
such a statement.


> * 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!"

More accurately, one may say that capability URLs (if implemented
correctly) are an example of what is known as password-capabilities or
sparse-capabilities, and that its important to note that a capability
system based on sparse capabilities is by its nature significantly less
secure than a system that can be classified as an object capability
system.


> 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.

I believe the conclusion in the current draft is based on a combination of
missing recommendations and a grave level of unawareness of the problems
with ACL, passwords, cookies, undue use of identity, use of single
granularity abstractions for access control, the use of authentication
tokens as token course grained access control, etc. If there was to be a
conclusion of this kind (what I believe to be should be outside of the
scope of the document), in this light, be the complete opposite as what it
is now.
I could supply many arguments for this and we may probably discuss it for
months before reching a conclussion. It may however be much more
productive to make any ACL vs capabilities, authentication vs
authorization, sparse cap versus password versus cookie, etc something
that is considered outside of the scope of this document.



> 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 06:55:47 UTC