What is a Capability URL (and why do I care?)

Dan Appelquist (@torgo)Open Web Advocate, Telefónica Digital

Telefónica Digitalhttp://blog.digital.telefonica.com - @tefdigital

Firefox OShttp://firefoxos.com

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

Jeni Tennison!

Technical Director of the ODI http://theodi.org

@jenit

Capability URLs

“Cool URIs Don’t Change”

http://www.w3.org/Provider/Style/URI.html- Tim Berners-Lee

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

Cool URLs Don’t Change

…but…

Not all URLs are cool

Some URLs are hot!

Sorry.

So what’s a hot URL?

• Something that provides a set of unique capabilities

• Access control - a key

• Ephemeral resources

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

Reasons to Use

• No login required

• Easy to pass on

Reasons to Be Careful

• No login required

• Easy to pass on

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

Also, Web Architecture Says “No”• Using multiple URLs for the same resource runs contrary to

documented good practice:

• 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/)

• However, the rationale for this is based on sharing:

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

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.

• 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

• 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

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.

Capability URLs

Such powerful

Very not break Web

Many care

Wow.

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