Intent to Prototype: Capability Delegation

Skip to first unread message

Mustaq Ahmed

Oct 23, 2020, 11:26:25 AM10/23/20
to blink-dev

Contact emails





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



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

TAG review

None (haven't started yet).


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)?


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

No (not yet)

Tracking bug

Link to entry on the Chrome Platform Status

Daniel Vogelheim

Nov 6, 2020, 12:04:44 PM11/6/20
to Mustaq Ahmed, blink-dev
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.


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
To view this discussion on the web visit

Mustaq Ahmed

Nov 18, 2020, 5:01:46 PM11/18/20
to Daniel Vogelheim, blink-dev
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.


Reply all
Reply to author
0 new messages