Capability URLs are unique web links that provide special access to resources without requiring user login, such as password resets or video chats. While they enable easy sharing, they pose risks as they can be exposed in logs and shared beyond intent; hence, they should be secure, temporary, and revokable. Best practices for using capability URLs include ensuring they are HTTPS, unique, unguessable, and that linked pages do not direct to third-party sites.

1. What is a Capability URL
(and why do I care?)
Dan Appelquist (@torgo)
Open Web Advocate, Telefónica Digital

2. Telefónica Digital
http://blog.digital.telefonica.com - @tefdigital

3. Firefox OS
http://firefoxos.com

4. W3C Technical Architecture Group
“The TAG” http://w3.org/tag - @w3ctag

5. Jeni Tennison
!
Technical Director of the ODI
http://theodi.org
@jenit

6. Capability URLs

7. “Cool URIs Don’t Change”
- Tim Berners-Lee
http://www.w3.org/Provider/Style/URI.html

8. Footnote: What’s the difference
between a URI and a URL?
•
In theory: URLs are a subset of URIs
•
In practice: they are used interchangeably
•
In reality: anyone who uses the term URI probably
spends too much time around Web Standards wonks

9. Cool URLs Don’t Change

10. …but…

11. Not all URLs are cool

12. Some URLs are hot!

13. Sorry.

14. So what’s a hot URL?
•
Something that provides a set of unique capabilities
•
Access control - a key
•
Ephemeral resources

15. Examples, please?
•
Password resets: “Your password has expired. Click here to
reset it.”
•
Video chats: “The video conference is on
https://opentokrtc.com/xyz...”
•
Polls: “Send this link to anyone you wish to invite:
http://doodle.com/xyz....”
•
Github GISTs
•
Google Calendar private URLs
•
iCloud sharing

16. Reasons to Use
•
No login required
•
Easy to pass on

17. Reasons to Be Careful
•
No login required
•
Easy to pass on

18. URLs Aren’t Designed to be Secret
•
It appears in the address bar (usually)
•
It appears in log files - e.g. proxy logs
•
If it’s passed on once it can be passed on again

19. Also, Web Architecture Says “No”
•
Using multiple URLs for the same resource runs contrary to
documented good practice:
•
•
However, the rationale for this is based on sharing:
•
•
Good practice: Avoiding URI aliases : A URI owner should not
associate arbitrarily different URIs with the same resource.
(Source: Architecture of the World Wide Web, Volume One: http://
www.w3.org/TR/webarch/)
It’s better for everyone linking to, or talking about, the same resource
to use the same URL
Capability URLs are oriented around limited sharing. In these
circumstances, having multiple aliases is not an issue.

20. Recommendations for Use
•
Only use:
•
to avoid the need for users to log in to perform an
action
•
to make it easy for those with whom you share URLs
to share them with others
•
to avoid authentication overheads in APIs.

21. •
Capability URLs should be https URLs - lowers
possibility of exposure
•
Pages that inform users of capability URLs should also
be https
•
Capability URLs should expire

22. •
Pages accessed through a capability URL should not
include links to third-party websites, or to third-party
scripts
•
If they do, they should include rel="noreferrer"
•
Capability URLs should be revokable - e.g. by the user
who created them
•
Capability URLs must be unique and should be
unguessable

23. Be aware of when you are using this pattern.
Employ best practices.
Remember: URLs are the fundamental architectural
building block of the web. Use with care.

24. Capability URLs
Many care
Such powerful
Very not break Web
Wow.

25. Thanks!
Keep up with our ongoing work in this space:
http://w3ctag.github.io/capability-urls/
Formal feedback round coming soon, but feel free to
weigh in on GitHub (github.com/w3ctag) or on our
mailing list www-tag@w3.org (also holds true for
anything else the TAG is working on).
Dan Appelquist @torgo
W3C TAG @w3ctag