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

Re: Seeking Feedback on Capability URLs Draft

From: Daniel Appelquist <Daniel.Appelquist@telefonica.com>
Date: Fri, 23 May 2014 18:49:51 +0000
To: www-tag <www-tag@w3.org>
CC: John Kemp <john@jkemp.net>
Message-ID: <CFA55672.43690%daniel.appelquist@telefonica.com>
Thanks so much for these comments, John!  BTW I don’t think the point of
the document is to discourage the use of capability URLs - rather to
encourage the adoption of best practice around their use.  Hopefully we
can clarify that in future drafts.


On 23/05/2014 15:58, "John Kemp" <john@jkemp.net> wrote:

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

>* 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
>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
>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.
>- 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 18:50:26 UTC

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