W3C home > Mailing lists > Public > www-tag@w3.org > May 2014

Re: Seeking Feedback on Capability URLs Draft

From: John Kemp <john@jkemp.net>
Date: Fri, 23 May 2014 10:58:11 -0400
Message-ID: <537F6203.2030807@jkemp.net>
To: Daniel Appelquist <Daniel.Appelquist@telefonica.com>, www-tag <www-tag@w3.org>
On 05/23/2014 09:28 AM, Daniel Appelquist wrote:
> Hi folks - as discussed, I’ve made a blog post
> http://www.w3.org/blog/TAG/2014/05/22/capability-urls-feedback/
> seeking some feedback on the Capability URLs draft. The goal here is
> to get some more eyeballs looking at this and feeding back to us so
> we can finalize this document and get it out the door as a finding by
> the July f2f. If you can help spread the word on this it will help
> get more feedback which will mean a better finding.

I've previously thought about commenting on this document, but stopped 
myself, mostly because I think the document strikes the wrong tone for 
me; why does the foremost architectural body on the Web seem so against 
the use of capability URLS, when (albeit in my opinion) they seem so 
much better aligned with Web architecture than ACL/password approaches?

I highly recommend the web-keys document 
(http://waterken.sourceforge.net/web-key/) for an in-depth discussion of 
why this is so (or at least, it agrees with my opinion ;)

But since you've asked again... here's some feedback.

In general, the examples used in the document are excellent examples of 
when one might use these mechanisms.

I would note a couple of other interesting examples in use:

* OAuth access tokens use the URI fragment of an HTTP Location header to 
hold an OAuth access token, creating a capability URL: 
http://tools.ietf.org/html/rfc6749#section-4.2.2

* The use of capability URLs to protect against XSRF attacks (as 
passwords, cookies and other forms of "ambient authority" do not)

Some comments about the "leaks" described in your blog post discussion, 
which may be relevant to the document discussion:

* People share private things other than links in search boxes, 
including their thoughts and feelings, phone numbers and other such 
information. They probably don't want to tell Google AdWords those 
things either. Protecting people from themselves has not proven 
particularly effective in the past.

Passwords are a good example too - people share them inappropriately all 
the time because they don't have effective fine-grained delegation over 
their web resources. Capability URLs provide the possibility to do that. 
Using capability URLs effectively would allow me to share the ability 
for a collaborator to read something at a URL without needing a 
password, but write access may require either/both a different 
capability URL and an account or other credentials.

* Companies who use capability URLs often do not think of the need to 
provide an explicit means of delegation. That is, providing a means by 
which the user can explicitly restrict use of the capability URL to 
people other than themselves (or provide different capability URLs to 
collaborators than the one they use to access the resource themselves). 
If a company wishes to use capability URLs, they should explicitly think 
about delegation, unless their wish is that sharing is truly 
unconstrained for their users. I would argue that at least one of the 
companies whose users accidentally leaked their private data made a 
conscious decision NOT to provide their users with this functionality 
(at least, not for free). A company might wish to design that delegation 
system such that an individual person shared with gets a unique URL for 
their access; that different URLs are assigned depending on the 
privileges possible via that URI (read/write etc.) An excellent document 
for understanding this particular issue regarding capability systems is

* If the companies had followed TAG guidance from the capability URLs 
document, they might have prevented one of the issues (rel=noreferrer).

In summary, I'd like to suggest that password-based approaches could 
certainly be seen as being less congruent with Web architecture than 
capabilities. I would also note that passwords have some problems which 
may actually be remedied by the use of capabilities. And finally, how 
much more do we want to rely on passwords when many users still use weak 
passwords; when those who store huge password databases are regularly 
compromised, and when account proliferation has accentuated these problems?

My point in railing against passwords, and talking up the use of 
capability systems is that the decision to use one or the other is 
simply a design choice. One is not better, or even simply more secure 
than the other. Thus, I would orient this document more towards 
discussing the design issues in using capability URLs, and not 
attempting to compare with account-based authentication at all. It is 
clear to me, having implemented capability-based systems, that such 
systems need not be any less secure than ACL-based systems. But it all 
depends on the design decisions one makes. I think the point of TAG 
advice should be to improve the architectural advice available. I do not 
think the best advice for capability URLs should (appear to) be "use 
passwords".

Concretely for the document, I would advise more discussion of the issue 
of delegation, and how such delegation might provide a fine-grained 
authorization approach to sharing and editing Web content. I think that 
is the biggest outstanding area for advice. Much of the other actual 
recommendations around the use of capabilities are already very good.

If you want much more detailed feedback than mine, I would recommend 
sending your request for feedback to the cap-talk mailing list 
(http://www.eros-os.org/mailman/listinfo/cap-talk) where many experts on 
capability systems lurk.

Thank you for working on this document - I believe that it has the 
potential to provide excellent advice to those implementing 
capability-based systems.

Regards,

- johnk

>
> Thanks, Dan
>
> This electronic message contains information from Telefonica UK or
> Telefonica Europe which may be privileged or confidential. The
> information is intended to be for the use of the individual(s) or
> entity named above. If you are not the intended recipient be aware
> that any disclosure, copying distribution or use of the contents of
> this information is prohibited. If you have received this electronic
> message in error, please notify us by telephone or email.
> Switchboard: +44 (0)113 272 2000 Email: feedback@o2.com Telefonica UK
> Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in
> England and Wales: 1743099. VAT number: GB 778 6037 85 Telefonica
> Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in
> England and Wales: 05310128. VAT number: GB 778 6037 85 Telefonica
> Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered
> in England and Wales: 7884976. VAT number: GB 778 6037 85
>
Received on Friday, 23 May 2014 14:58:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:25 UTC