Intent to Prototype: Capability Delegation

[Mustaq Ahmed]

Contact emails

mus...@chromium.org

Explainer

github.com/mustaqahmed/capability-delegation

Specification

None

Summary

Capability delegation means allowing a frame to relinquish its ability to call a restricted API and transfer the ability to another (sub)frame it can trust. If an app wants to delegate its ability to call a restricted JS capability (e.g. popups, fullscreen, etc) to a known+trusted third-party frame, the app would utilize a Capability Delegation API to "transfer" the ability to the target frame in a time-constrained manner (unlike static mechanisms like <iframe allow> attributes).

Blink component

Blink

Motivation

Here are some practical scenarios that would utilize a capability delegation mechanism.

- Many merchant websites host their online store on their own domain but outsource the payment collection and processing infrastructure to a Payment Service Provider (PSP) to comply with security and regulatory complexities around card payments. This workflow is implemented as a “pay” button inside the top (merchant) frame where it can blend better with the rest of the merchant’s website, and payment request code inside a cross-origin iframe from the PSP. The Payment Request API used by the PSP code is gated by transient user activation (to prevent malicious attempts like unattended or repeated payment requests). Because the top (merchant) frame’s user interaction is not visible to the iframe, the PSP code needs some kind of a delegation in response to a click in the top frame to be able to initiate a payment processing. - A web service that does not care about user location except for a "branch locator" functionality provided by a third-party map-provider app can delegate its own location access capability to the map iframe in a temporary manner (right after the "branch locator" button is clicked).

- An authentication provider may wish to show a popup to complete the authentication flow before returning a token to the host site.

Initial public proposal

https://discourse.wicg.io/t/capability-delegation/4821

TAG review

None (haven't started yet).

Risks

Interoperability and Compatibility

No compat risk as this would be a new feature.

For the interop question, we need to consider this two-phase process:

[A] This intent conceptually covers the general mechanism which would remain unexposed to the Web until we hit the next (capability specific) stage.

[B] Then each capability (e.g. payment request, location access etc) would need spec discussion by corresponding capability owners to define their own post-delegation behavior (what happens to a specific capability after delegation happens).

We plan to implement [A] as the first step (this intent). Then as the second step, we would iterate over [A]+[B] in parallel for a specific capability that has immediate use-cases (e.g. Web Payments). There would perhaps be a new intent for that specific [B]. We expect to have other browser vendors fully on board during the [A]+[B] iteration step.

Gecko: No signal
WebKit: No signal
Web developers: Positive (comment on Web Payments)

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No (not yet)

Tracking bug

https://crbug.com/1130558

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5708770829139968

[Daniel Vogelheim]

Hello Mustaq,

We've discussed your intent within security + privacy teams. The discussion raised a number of concerns, but we couldn't find enough detail to either substantiate or allay them. This unfortunately makes it difficult to give you actionable feedback.

Our thoughts: This API effectively packages a permission / user interaction in a token and allows it to be sent somewhere else, creating a permission-capability-thing. This raises a number of questions:

- The idea of gating functionality on user interaction is to make sure that the user understands what they are interacting with. If a user interaction is 'packaged' and sent for consumption elsewhere, does this still hold? Could a malicious user put the 'packaged' interaction to a surprising use?

- Are there limits to where it can be passed to? Could it be passed - via a server round-trip - to another site running in the same browser?

- Is there any info on the API that would consume the token?

- The token is unspecified, but seems to follow the pattern of 'unguessable secret number'. The problem here is with the Spectre attack family, where we've had to change our assumption to assume that any data within a process is potentially readable, even by sandboxed code. Under this assumption, could the token be read by an unintended recipient?

We were also a bit unclear on the use cases, and the relationship to feature policy.

Mustaq, could you maybe update the docs to include this type of information? We'd like to take a second look at it.

Thanks,

Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4GMjCbfO7gWS%3DgsGU2LvYkG%3D15Ggv88RQqivFFdv65Vg%40mail.gmail.com.

[Mustaq Ahmed]

Hi Daniel:

Sorry for the delay, thanks for listing those concerns.

I have added a Privacy and security considerations section in the design doc to address three of the concerns, please take a look and let us know if we missed anything.  I haven't yet replied to the Spectre point, I need to fully understand the attack vector you are thinking of.

The relation to Feature/Permission Policy is still an open question, we will need some time to answer this.

Mustaq

[Mustaq Ahmed]

A few quick updates:

- The WICG/capability-delegation repository is the current home for the explainer and a spec draft.

- Please use a new/existing issue for any comments or suggestions.

- We filed a TAG review request two weeks ago.

[Jun Kokatsu]

This is spec is probably written with the assumption that Permission Delegation is implemented (or should be implemented) in all browsers. However, Permission Delegation is not a Web Standard, and browsers (and other user agent) are free to implement any sort of permission model.

For example, a browser without Permission Delegation would require permission prompt from iframe (which contains origin of iframe in the prompt) in order to use any permission-based API. Permission Policy or allow attribute are just there to allow permission request from iframes, but that doesn't necessary mean that permission is delegated directly to iframe. 

If you try to ship Capability Delegation API in above model, this would be a bypass of permission prompt or delegating permission to cross-origin iframes without user's knowledge.

Thanks,

Jun

[Mustaq Ahmed]

Thanks for your feedback, Jun.  That's an important point that calls for clarification:

This is spec is probably written with the assumption that Permission Delegation is implemented (or should be implemented) in all browsers. However, Permission Delegation is not a Web Standard, and browsers (and other user agent) are free to implement any sort of permission model.

We made no such assumption here about Permissions.  Our intent is to only define a generic API for delegation  here, and to leave any capability-specific details to capability-owners.  Any "capability" here could be Permission-gated (like camera and web-usb) or Permission-agnostic (like fullscreen and popup), and the capability-owners will decide, on a case-by-case basis, which Permission model they would like to incorporate, if at all.

Having said that, a recent comment in our TAG review issue seems to be suggesting a generalized behavior for capabilities which is not what we intended this for.  Let's continue this discussion there for greater visibility.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/784fa5a5-72bd-4e42-8dfb-cdbd8258b8dfn%40chromium.org.